Backup, Snapshot, Replikation: Was ist der Unterschied?

Warum die drei Begriffe so oft verwechselt werden

Backup, Snapshot und Replikation haben eine Gemeinsamkeit: Sie erzeugen neben dem Produktivbestand eine zweite Repräsentation der Daten. Daraus folgt der verbreitete Schluss, sie seien austauschbar. Tatsächlich unterscheiden sie sich in den Fragen, die für den Ernstfall entscheidend sind: Wie unabhängig ist die Kopie vom Original? Hält sie frühere Stände vor? Wer kann sie verändern oder löschen? Wie lange wird sie aufbewahrt? Und aus welchem Ereignis lässt sich damit wiederherstellen?

Produktbezeichnungen tragen zur Verwirrung bei, weil sie Begriffe uneinheitlich verwenden. Ein Menüpunkt „Sicherung“ in einer Verwaltungsoberfläche kann lediglich einen Snapshot anlegen, und eine „Spiegelung“ im Speichersystem ist eine Replikation. Entscheidend ist deshalb nicht die Bezeichnung, sondern die Funktionsweise.

Backup: eigenständige Kopie mit früheren Ständen

Ein Backup ist eine gesonderte Kopie von Daten oder Systemzuständen, die für eine spätere Wiederherstellung vorgesehen ist. Vier Merkmale kennzeichnen es: die Trennung vom Original, die Vorhaltung mehrerer Stände über einen Aufbewahrungszeitraum, ein eigenes Regelwerk für Aufbewahrung und Löschung sowie der ausdrückliche Zweck der Wiederherstellung.

Technisch werden unterschiedliche Verfahren unterschieden. Eine Vollsicherung erfasst den gesamten Bestand, eine inkrementelle Sicherung nur die Änderungen seit der letzten Sicherung, eine differenzielle Sicherung die Änderungen seit der letzten Vollsicherung. Image-basierte Verfahren sichern ganze Systemzustände, dateibasierte einzelne Dateien und Ordner. Für Datenbanken und Anwendungen ist zudem die anwendungskonsistente Sicherung wichtig, bei der die Anwendung während der Sicherung in einen definierten Zustand gebracht wird, damit die Kopie später gestartet werden kann.

Ein Backup sichert die Wiederherstellbarkeit nicht von sich aus zu, und es verhindert keinen Ausfall. Es verkürzt weder automatisch die Ausfalldauer, noch ersetzt es ein Notfallkonzept. Seine Stärke liegt darin, dass es auch dann noch existiert, wenn das Original nicht mehr zur Verfügung steht oder verändert wurde.

Konsistenz: Warum eine Kopie nicht automatisch brauchbar ist

Für die Wiederherstellung zählt nicht nur, dass Daten kopiert wurden, sondern in welchem Zustand. Man unterscheidet dabei grob die absturzkonsistente Kopie, die dem Zustand nach einem plötzlichen Stromausfall entspricht, von der anwendungskonsistenten Kopie, bei der laufende Transaktionen vorher abgeschlossen oder in einen definierten Zustand überführt wurden. Eine Datenbank, deren Dateien einfach zu irgendeinem Zeitpunkt kopiert werden, lässt sich unter Umständen nicht mehr sauber starten.

Dieser Aspekt gilt für alle drei Verfahren. Ein Snapshot ohne Abstimmung mit der Anwendung bildet im ungünstigen Fall einen inkonsistenten Zustand ab, und ein Replikat kann einen Zustand enthalten, der nur dem Absturzfall entspricht. Wer Datenbanken oder Fachanwendungen schützt, sollte deshalb prüfen, ob die verwendete Technik anwendungskonsistente Sicherungen unterstützt, und die Wiederherstellung der Anwendung testen und nicht nur die Verfügbarkeit der Dateien.

Snapshot: Momentaufnahme mit Abhängigkeit

Ein Snapshot hält den Zustand eines Systems, Datenträgers oder Dateisystems zu einem Zeitpunkt fest. Er wird von Speichersystemen, Dateisystemen und Virtualisierungsplattformen angeboten, unter Windows beispielsweise über den Volume Shadow Copy Service.

Der Mechanismus erklärt die Eigenschaften. Beim Anlegen eines Snapshots werden die Daten in der Regel nicht kopiert. Stattdessen merkt sich das System Verweise auf den aktuellen Blockbestand. Ändert sich ein Block danach, wird je nach Verfahren der alte Inhalt an anderer Stelle bewahrt (Copy-on-Write) oder der neue Inhalt an anderer Stelle geschrieben (Redirect-on-Write). Der Snapshot besteht also aus Verweisen auf Blöcke, die im selben Speichersystem liegen wie das Original.

Daraus folgt: Anlegen und Zurückrollen sind sehr schnell, und der Speicherbedarf ist anfangs gering. Zugleich ist der Snapshot vom Original abhängig. Fällt der Speicher aus, wird er beschädigt oder von einem Angreifer mit ausreichenden Rechten gelöscht, ist der Snapshot mitbetroffen. Bei virtuellen Maschinen kommt hinzu, dass lange Ketten von Snapshots die Leistung beeinträchtigen und Verwaltungsaufwand erzeugen können.

Snapshots sind deshalb ein nützliches Werkzeug, aber nicht automatisch ein unabhängiges Backup. Die Bewertung hängt von Speicherort, technischer Abhängigkeit, Isolation, Aufbewahrung und Löschschutz ab. Sinnvoll eingesetzt dienen sie als schneller Rücksprung vor einer riskanten Änderung wie einem Update oder als konsistenter Ausgangspunkt, von dem ein Backup die Daten liest, während das System weiterläuft.

Replikation: aktuelle Kopie an anderem Ort

Replikation überträgt Daten oder Systemzustände auf ein weiteres System oder an einen weiteren Standort und hält diese Kopie aktuell. Bei der synchronen Replikation wird ein Schreibvorgang erst bestätigt, wenn er auf beiden Seiten angekommen ist. Das erlaubt einen Datenverlust von nahezu null, setzt aber geringe Latenz zwischen den Standorten voraus. Bei der asynchronen Replikation wird zeitversetzt übertragen. Die Kopie hinkt dem Original dann um einen Zeitraum hinterher, der als Verlustfenster zu bewerten ist.

Der Zweck der Replikation ist Verfügbarkeit: Fällt das Hauptsystem oder der Hauptstandort aus, steht ein aktuelles Zweitsystem bereit. Gerade darin liegt ihre Grenze für die Sicherung. Die Replikation gibt den aktuellen Zustand weiter, auch wenn dieser fehlerhaft ist. Eine versehentlich gelöschte Datei, eine durch einen Programmfehler beschädigte Datenbank oder von Ransomware verschlüsselte Dateien werden, je nach Konfiguration binnen kurzer Zeit, auf die Kopie übertragen. Ohne zusätzlichen Mechanismus, etwa ein Änderungsjournal oder Snapshots auf der Zielseite, hält die Replikation keine früheren Stände vor.

Auch die Georedundanz eines Speicherdienstes ist eine Replikation. Sie verringert das Risiko durch den Ausfall eines Standorts, schützt aber nicht automatisch vor Löschung oder Fehlern.

Der Vergleich im Überblick

Die drei Verfahren lassen sich anhand weniger Kriterien gegenüberstellen:

• Unabhängigkeit vom Original: Backup hoch, wenn Speicher und Zugriffswege getrennt sind; Snapshot gering, da vom selben Speicher abhängig; Replikation mittel, räumlich getrennt, aber über Verwaltung und Datenfluss gekoppelt
• Frühere Stände: Backup ja, nach Aufbewahrungsregel; Snapshot ja, aber meist begrenzt; Replikation grundsätzlich nein
• Aktualität: Backup entspricht dem Sicherungsintervall; Snapshot dem Zeitpunkt der Aufnahme; Replikation sehr aktuell, bei synchronem Betrieb nahezu ohne Verzug
• Wiederherstellungsgeschwindigkeit: Backup abhängig von Datenmenge und Ziel; Snapshot sehr schnell; Replikation schnell durch Umschaltung
• Primärer Zweck: Backup Wiederherstellung nach Verlust; Snapshot schneller Rücksprung und konsistente Momentaufnahme; Replikation Verfügbarkeit

Welche Technik hilft bei welchem Ereignis?

Eine nützliche Bewertung geht vom Ereignis aus statt von der Technik. Die folgende Einordnung ist eine Faustregel. Im Einzelfall entscheidet die Konfiguration.

• Versehentlich gelöschte oder überschriebene Datei: Backup mit passender Aufbewahrung und Snapshots helfen, Replikation überträgt die Löschung.
• Defekt eines Datenträgers oder Servers: Ein Backup hilft ebenso wie Replikation und Snapshots auf einem anderen System, Snapshots auf dem defekten System nicht.
• Standortausfall durch Brand oder Wasser: Ein Backup am anderen Ort und die Replikation helfen, lokale Snapshots nicht.
• Ransomware: Entscheidend ist, ob die Kopie vom Angreifer erreichbar ist. Ein vom Produktivnetz getrenntes, gesperrtes Backup hilft. Replikation und lokale Snapshots können ebenfalls verschlüsselt oder gelöscht werden.
• Logische Beschädigung, die erst später auffällt: Nur Verfahren mit ausreichend langer Aufbewahrung früherer Stände helfen, in der Regel also ein Backup.
• Geplante Wartung mit Risiko: Ein Snapshot vor dem Eingriff erlaubt den schnellen Rücksprung.

Ein konstruiertes Beispiel: Update einer virtuellen Maschine

Das Beispiel ist konstruiert. Ein Unternehmen betreibt seine Warenwirtschaft auf einer virtuellen Maschine und spielt ein Update ein. Vor dem Update legt die Administration einen Snapshot an. Läuft das Update fehlerhaft, ist der Rücksprung auf den Zustand davor innerhalb kurzer Zeit möglich. Der Snapshot erfüllt hier genau seinen Zweck.

Einige Wochen später fällt auf, dass seit dem Update einzelne Datensätze fehlerhaft berechnet wurden. Der Snapshot existiert nicht mehr, denn er wurde nach erfolgreichem Test wieder gelöscht. Ein Replikat im zweiten Rechenzentrum enthält den fehlerhaften Stand ebenfalls. Nur das Backup mit mehreren Generationen erlaubt jetzt, einen Datenstand vor dem Update zu rekonstruieren. Das Beispiel zeigt, dass jedes Verfahren seine Aufgabe hat und dass die Aufbewahrung früherer Stände nur eines davon leistet.

Wie die drei Verfahren zusammenspielen

Die Frage lautet selten „Backup oder Snapshot oder Replikation?“, sondern wie sich die Verfahren sinnvoll ergänzen. Ein Snapshot liefert einen konsistenten Zustand, von dem ein Backup liest, während das System weiterläuft. Replikation hält ein Zweitsystem bereit und verkürzt damit den Ausfall. Das Backup bleibt die letzte, unabhängige Instanz, auf die zurückgegriffen wird, wenn Original und Replikat betroffen sind. Die Abgrenzung zur Hochverfügbarkeit und zu Disaster Recovery vertieft der Beitrag Hochverfügbarkeit vs. Disaster Recovery.

Typische Fehlannahmen

In der Praxis begegnen immer wieder dieselben Annahmen, die zu Lücken im Schutz führen:

• „Wir haben ein gespiegeltes System, also brauchen wir kein Backup.“ Eine Spiegelung überträgt auch Löschungen und Verschlüsselungen.
• „Die Snapshots der Virtualisierung sind unsere Sicherung.“ Sie liegen im selben Speicher und sind in der Regel nicht für lange Aufbewahrung gedacht.
• „Die Cloud sichert unsere Daten ohnehin.“ Ob und wie lange ein Dienst frühere Stände vorhält, richtet sich nach dem jeweiligen Dienst. Georedundanz ersetzt kein Backup, bei Cloud-Diensten wie Microsoft 365 siehe Braucht Microsoft 365 ein Backup?.
• „Das Backup liegt auf einem Netzlaufwerk, also ist es getrennt.“ Ist das Laufwerk mit denselben Rechten beschreibbar, kann ein Angreifer es erreichen.
• „Mehr Kopien bedeuten mehr Sicherheit.“ Es kommt darauf an, ob die Kopien unabhängig sind und ob frühere Stände vorliegen.

Fragen zur Bewertung Ihrer Umgebung

Um eine vorhandene Lösung einzuordnen, helfen die folgenden Fragen. Sie lassen sich auf jedes der drei Verfahren anwenden:

• Wo liegt die Kopie, und von welchem System, Speicher oder Netz hängt sie ab?
• Welche früheren Stände existieren, und wie lange werden sie aufbewahrt?
• Welche Konten und Rollen können die Kopie verändern oder löschen?
• Ist die Kopie verschlüsselt, und wer verwaltet die Schlüssel?
• Wurde eine Wiederherstellung aus dieser Kopie getestet?
• Welcher Datenverlust ist im ungünstigsten Fall möglich?

Umsetzung mit der Plattform

Die Plattform arbeitet als Backup: Sicherungen werden unabhängig vom Quellsystem abgelegt, und die Aufbewahrungsfristen legen Sie im Backup-Plan selbst fest. Die Sicherungen lassen sich im Cloud-Speicher in Frankfurt am Main ablegen, optional mit Georedundanz (in der Regel Berlin, gegen Aufpreis). Diese ist, wie oben beschrieben, eine Replikation. Auf unterstützten Zielen können Sicherungen für einen Zeitraum gesperrt werden. Zwischen zwei Backups lassen sich Änderungen ausgewählter Dateien und Anwendungen auf unterstützten Windows-Systemen laufend erfassen.

Für den Ausfallfall können virtuelle Maschinen direkt aus dem Backup starten, und mit dem Cloud-Failover lassen sich Systeme aus dem Backup in der Cloud betreiben. Diese Funktionen bauen auf Backups auf und ersetzen keine Hochverfügbarkeitsarchitektur. Einen Überblick über die gesicherten Umgebungen gibt die Seite Backup aller Workloads.

Grenzen und offene Punkte

Auch ein gut konzipiertes Backup bleibt von Bedingungen abhängig. Es schützt nur, was gesichert wurde, und nur bis zum letzten erfolgreichen Lauf. Eine erfolgreiche Sicherungsmeldung beweist nicht, dass ein ganzes System funktionsfähig wiederhergestellt werden kann. Planen Sie daher Restore-Tests ein und klären Sie, wer Sicherungen überwacht, wer im Ernstfall wiederherstellt und wer die Daten fachlich prüft. Wenn Sie Ihre Umgebung einordnen möchten, sprechen Sie uns an: Kontakt.