Storage. Backup. Virtualisierung.
Online / Offline Backup · Version 1.7 · © Stor IT Back 2026
Bei einem Offline-Backup wird eine Anwendung oder Datenbank vor der Sicherung kontrolliert beendet. Bei einem Online-Backup bleibt sie dagegen verfügbar und verwendet spezielle Backup-Mechanismen, Transaktionslogs oder anwendungsspezifische Schnittstellen, um eine konsistente Wiederherstellung zu ermöglichen. Online-Backups sind deshalb insbesondere für Datenbanken, virtuelle Maschinen und Anwendungen im 24/7-Betrieb wichtig.
Entscheidend ist nicht nur, dass Daten kopiert werden. Ein Backup muss im Ernstfall auch in einen konsistenten und nutzbaren Zustand wiederhergestellt werden können. Je nach Sicherungsverfahren wird dabei zwischen crash-konsistenten, dateisystemkonsistenten und anwendungskonsistenten Sicherungen unterschieden.
Ein Online- oder Offline-Backup kann grundsätzlich mit unterschiedlichen Backup-Technologien kombiniert werden, beispielsweise mit einer Netzwerksicherung, einer LAN-free-Sicherung oder einer Snapshot-basierten Datensicherung.
Der wesentliche Unterschied besteht darin, ob die zu sichernde Anwendung während des Backups weiter betrieben werden kann. Bei einem Online-Backup bleiben Datenbanken, Anwendungen oder virtuelle Maschinen in Betrieb. Die Anwendung beziehungsweise Datenbank muss dabei Mechanismen bereitstellen, mit denen ein später konsistent wiederherstellbarer Datenstand erzeugt werden kann.
Je nach Anwendung kommen beispielsweise Transaktionslogs, Redo-Logs, Write-Ahead-Logs, Checkpoints, Quiescing oder spezielle Backup-Schnittstellen zum Einsatz. Die Daten müssen während der Sicherung also nicht grundsätzlich unverändert bleiben. Vielmehr muss das jeweilige System sicherstellen, dass aus Backup und gegebenenfalls vorhandenen Logs wieder ein konsistenter Zustand hergestellt werden kann.
Bei einer Offline-Sicherung wird die Anwendung oder Datenbank vor dem Backup kontrolliert beendet. Sind alle Schreibvorgänge abgeschlossen, können die Dateien anschließend gesichert werden. Der Vorteil ist ein vergleichsweise einfaches und gut nachvollziehbares Sicherungsverfahren. Der Nachteil besteht in der notwendigen Unterbrechung der Anwendung.
| Kriterium | Online-Backup | Offline-Backup |
|---|---|---|
| Anwendung während des Backups verfügbar | Ja | Nein |
| Eignung für 24/7-Betrieb | Sehr gut geeignet | Nur bei vorhandenen Wartungsfenstern |
| Konsistenz | Über Anwendung, Datenbank, Backup-API, Logs oder andere Konsistenzmechanismen | In der Regel durch kontrolliertes Beenden der Anwendung |
| Komplexität | Höher | Geringer |
| Anwendungsintegration | Meist erforderlich | Häufig nicht erforderlich |
| Point-in-Time-Recovery | Möglich, wenn die notwendigen Transaktions- oder Redo-Logs vorhanden sind | Ebenfalls möglich, wenn ein geeignetes Basisbackup und die erforderlichen Logs vorhanden sind |
| Typische Einsatzbereiche | Datenbanken, virtuelle Maschinen und geschäftskritische Anwendungen | Systeme mit Wartungsfenstern oder weniger hohen Verfügbarkeitsanforderungen |
Nein. Das reine Kopieren der Dateien einer laufenden Datenbank garantiert noch keine konsistente Datensicherung. Ein einfaches Beispiel mit einer Datenbank für Buchhaltungsdaten verdeutlicht das Problem.
In diesem Beispiel beginnt die Datensicherung um 15:00 Uhr und läuft bis 16:00 Uhr. Während dieser Zeit werden weiterhin Buchungen durchgeführt. Eine einzelne Transaktion kann dabei Änderungen an mehreren unterschiedlichen Bereichen der Datenbank vornehmen.
Hat das Backup einen Datenbereich bereits kopiert, während ein anderer Bereich derselben Transaktion erst später gesichert wird, können ohne zusätzliche Konsistenzmechanismen unterschiedliche Zeitstände innerhalb der Sicherung entstehen. Das Backup enthält dann möglicherweise keinen logisch zusammengehörenden Datenbestand.
Moderne Datenbanken verhindern beziehungsweise korrigieren dieses Problem über ihre eigenen Recovery-Mechanismen. Dazu gehören beispielsweise Transaktionslogs, Redo-Logs, Checkpoints oder spezielle Backup-Funktionen. Deshalb sollte eine produktive Datenbank nicht einfach durch das Kopieren geöffneter Datenbankdateien gesichert werden.
Die einfachste Möglichkeit zur Erzeugung eines konsistenten Datenbestands besteht darin, die Anwendung, Datenbank oder virtuelle Maschine kontrolliert herunterzufahren. Sobald alle Schreibvorgänge abgeschlossen sind, können die zugehörigen Dateien gesichert werden.
Dieses Verfahren wird als Offline-Backup bezeichnet. Der Vorteil liegt in der vergleichsweise einfachen Handhabung. Nach dem kontrollierten Beenden können die Dateien abhängig von der Anwendung beispielsweise mit einer Backup-Software oder einfachen Dateiwerkzeugen kopiert werden.
Der wesentliche Nachteil ist die notwendige Ausfallzeit. Dauert das Backup beispielsweise eine Stunde, steht die Anwendung während dieser Zeit nicht zur Verfügung. Für Systeme mit kleinen Wartungsfenstern oder einem echten 24/7-Betrieb ist dieses Verfahren daher häufig ungeeignet.
Bei einem Online-Backup bleibt die Datenbank oder Anwendung während der Sicherung in Betrieb. Benutzer können grundsätzlich weiterarbeiten und Anwendungen bleiben verfügbar.
Damit trotzdem eine konsistente Wiederherstellung möglich ist, muss die Backup-Software mit den Konsistenzmechanismen der Anwendung zusammenarbeiten. Datenbanken verwenden hierfür je nach Produkt beispielsweise Transaktionslogs, Redo-Logs, Write-Ahead-Logs, Checkpoints oder spezielle Backup-APIs.
Änderungen während der Sicherung müssen dabei nicht grundsätzlich verhindert werden. Entscheidend ist vielmehr, dass alle notwendigen Informationen vorhanden sind, um das Backup bei einer Wiederherstellung wieder in einen logisch konsistenten Zustand zu bringen.
Online-Backups sind deshalb besonders für geschäftskritische Datenbanken, virtuelle Maschinen und Anwendungen geeignet, die rund um die Uhr verfügbar sein müssen.
Viele Datenbanksysteme ermöglichen eine Point-in-Time-Recovery (PITR). Dabei wird die Datenbank nicht nur auf den Zeitpunkt eines vollständigen Backups zurückgesetzt, sondern anschließend mithilfe von Transaktions- oder Redo-Logs bis zu einem gewünschten Zeitpunkt weitergeführt.
Eine Point-in-Time-Recovery ist deshalb nicht grundsätzlich an ein Online-Backup gebunden. Entscheidend ist, dass ein geeignetes Basisbackup sowie alle für den gewünschten Wiederherstellungszeitpunkt notwendigen Logs verfügbar sind.
Ein typischer Anwendungsfall ist eine fehlerhafte Eingabe, eine versehentliche Löschung oder ein Anwendungsfehler. Die Datenbank kann dann beispielsweise auf einen Zeitpunkt unmittelbar vor dem Fehler zurückgesetzt werden.
Besonders bei der Sicherung virtueller Maschinen ist die Unterscheidung zwischen Crash Consistency und Application Consistency wichtig.
Ein Crash-Consistent Backup enthält ungefähr den Datenzustand, der auch nach einem plötzlichen Stromausfall oder Systemabsturz vorhanden sein könnte. Moderne Dateisysteme können diesen Zustand durch Journaling häufig automatisch wiederherstellen. Auch Datenbanken verfügen in der Regel über eigene Recovery-Mechanismen.
Crash-konsistent bedeutet daher nicht automatisch, dass das Backup unbrauchbar ist. Es bedeutet jedoch, dass die Konsistenz innerhalb einer Anwendung oder Datenbank nicht ausdrücklich durch das Backup-Verfahren sichergestellt wurde.
Bei einem Application-Consistent Backup wird die betreffende Anwendung dagegen aktiv in den Sicherungsvorgang einbezogen. Schreibvorgänge werden koordiniert, Daten auf einen definierten Zustand gebracht und gegebenenfalls Transaktionslogs berücksichtigt. Für geschäftskritische Datenbanken und Anwendungen ist dieses Verfahren deshalb grundsätzlich vorzuziehen.
Bei virtuellen Maschinen wird häufig mit Snapshots gearbeitet. Ein Snapshot stellt innerhalb kurzer Zeit einen definierten Zustand der virtuellen Festplatten bereit, der anschließend durch die Backup-Software gesichert werden kann.
Ein Snapshot allein garantiert jedoch noch keine Anwendungskonsistenz. Befindet sich beispielsweise innerhalb der virtuellen Maschine eine laufende Datenbank, muss auch diese in den Sicherungsprozess einbezogen werden.
Moderne Backup-Lösungen nutzen hierfür beispielsweise Guest-Agenten, Hypervisor-Schnittstellen, anwendungsspezifische Plug-ins oder unter Windows den Volume Shadow Copy Service (VSS). Dadurch können Anwendungen vor dem Snapshot in einen für die Datensicherung geeigneten Zustand versetzt werden.
Erfolgt keine solche Integration, ist der Snapshot häufig lediglich crash-konsistent. Für Dateiserver oder weniger kritische Systeme kann dies je nach Anwendung ausreichend sein. Bei Datenbanken und transaktionsintensiven Anwendungen sollte dagegen nach Möglichkeit ein anwendungskonsistentes Backup erzeugt werden.
Oracle stellt mit dem Recovery Manager (RMAN) ein eigenes Werkzeug für Backup und Recovery zur Verfügung. Eine geöffnete Oracle-Datenbank kann online gesichert werden, wenn sie sich im ARCHIVELOG-Modus befindet.
Der aktuelle Modus kann beispielsweise mit folgender SQL-Abfrage überprüft werden:
SELECT name, log_mode FROM v$database; NAME LOG_MODE -------- ------------ PROD ARCHIVELOG
Anschließend kann RMAN beispielsweise lokal gestartet werden:
rman target /
Eine vollständige Sicherung der Datenbank einschließlich der vorhandenen Archive-Logs kann beispielsweise mit folgendem RMAN-Befehl durchgeführt werden:
BACKUP DATABASE PLUS ARCHIVELOG;
RMAN ist für Oracle-Datenbanken gegenüber dem manuellen Kopieren geöffneter Datenbankdateien vorzuziehen. RMAN kennt die interne Struktur der Oracle-Datenbank und unterstützt sowohl Backup als auch Restore und Recovery.
Das ältere Verfahren eines sogenannten
User-Managed Backup mit
BEGIN BACKUP und
END BACKUP ist weiterhin bekannt,
sollte für neue Backup-Konzepte jedoch nicht als bevorzugte
Standardmethode dargestellt werden.
Zusätzlich zum eigentlichen Datenbank-Backup müssen auch die für eine Wiederherstellung notwendigen Archive-Logs sowie relevante Konfigurationsinformationen berücksichtigt werden. Für eine Point-in-Time-Recovery sind insbesondere die entsprechenden Redo- beziehungsweise Archive-Logs notwendig.
Welche Sicherungsmethode geeignet ist, hängt von den Anforderungen an Verfügbarkeit, Recovery Time Objective (RTO), Recovery Point Objective (RPO), Datenmenge und Anwendung ab.
Kann eine Datenbank innerhalb eines definierten Wartungsfensters kontrolliert heruntergefahren werden, kann eine Offline-Sicherung eine einfache und zuverlässige Lösung sein. Für Anwendungen, die rund um die Uhr verfügbar sein müssen, ist dagegen meist eine Online-Sicherung erforderlich.
Eine Point-in-Time-Recovery hängt dabei nicht allein von der Art des Basisbackups ab. Wichtig ist vielmehr, dass auch die benötigten Transaktions- oder Redo-Logs zuverlässig gesichert und für eine Wiederherstellung verfügbar sind.
Stor IT Back unterstützt Unternehmen bei der Planung von Backup- und Recovery-Konzepten für Datenbanken, virtuelle Maschinen und Anwendungen. Wir betrachten dabei nicht nur die Sicherung, sondern auch die tatsächliche Wiederherstellung. Dazu können dokumentierte Recovery-Abläufe und regelmäßige Wiederherstellungstests gehören.
Der Vorteil für Sie: Ein Backup-Konzept mit geplanter und getesteter Recovery.
Bei einer Offline-Sicherung wird die Anwendung, Datenbank oder virtuelle Maschine vor dem Backup kontrolliert beendet. Anschließend werden die zugehörigen Daten gesichert. Während der Sicherung steht die betreffende Anwendung normalerweise nicht zur Verfügung.
Bei einer Online-Sicherung bleibt die Anwendung oder Datenbank während des Backups verfügbar. Damit trotzdem eine konsistente Wiederherstellung möglich ist, werden anwendungsspezifische Mechanismen wie Transaktionslogs, Redo-Logs, Checkpoints oder Backup-Schnittstellen genutzt.
Nein. Das reine Kopieren der Dateien einer laufenden Datenbank garantiert keine Anwendungskonsistenz. Die Datenbank beziehungsweise die Backup-Software muss geeignete Mechanismen einsetzen, damit der gesicherte Datenstand konsistent wiederhergestellt werden kann.
Ein Crash-Consistent Backup enthält ungefähr den Zustand, der nach einem unerwarteten Systemausfall vorhanden sein könnte. Dateisysteme und Datenbanken können diesen Zustand häufig über eigene Recovery-Mechanismen wiederherstellen. Eine Anwendungskonsistenz ist jedoch nicht garantiert.
Bei einem Application-Consistent Backup wird die Anwendung aktiv in den Sicherungsvorgang einbezogen. Schreibvorgänge, Transaktionslogs und interne Datenstrukturen werden so koordiniert, dass eine konsistente Wiederherstellung der Anwendung möglich ist.
Nein. Ein Snapshot stellt zunächst nur einen definierten Zustand der betreffenden Speicherbereiche bereit. Für eine anwendungskonsistente Sicherung müssen laufende Datenbanken und Anwendungen zusätzlich über geeignete Schnittstellen oder Agenten in den Snapshot-Prozess eingebunden werden.
Nein. Eine Point-in-Time-Recovery kann auch auf einem geeigneten Offline-Backup basieren. Entscheidend ist, dass zusätzlich alle benötigten Transaktions- oder Redo-Logs für den gewünschten Wiederherstellungszeitpunkt vorhanden sind.
Ein Online-Backup ist besonders sinnvoll, wenn Datenbanken, virtuelle Maschinen oder Anwendungen während der Sicherung verfügbar bleiben müssen. Dies betrifft insbesondere geschäftskritische Systeme und Anwendungen im 24/7-Betrieb.
