In den meisten Umgebungen gibt es eine Liste, die aussieht wie ein Sicherungskonzept: stündliche Snapshots, tägliche, ein paar wöchentliche, dazu ein monatlicher Stand. Sie ist automatisiert, und sie funktioniert — jedenfalls für die Frage, wie man eine gelöschte Datei oder ein misslungenes Update zurückholt.

Sie beantwortet aber nur eine von zwei Fragen. Die zweite lautet: Was passiert, wenn das Speichersystem selbst nicht mehr da ist. Darauf hat eine reine Snapshot-Kette keine Antwort, und zwar aus einem strukturellen Grund — nicht wegen einer Fehlkonfiguration, die sich nachträglich beheben ließe.

Wie ein Snapshot technisch entsteht

Ein Snapshot kopiert im Moment seiner Erstellung nichts. Er friert einen Zustand ein, indem er festlegt, welche Datenblöcke ab jetzt nicht mehr überschrieben werden dürfen. Erst der nächste Schreibzugriff erzeugt Aufwand — und wie dieser aussieht, unterscheidet die beiden gängigen Verfahren.

Copy-on-Write (CoW) kopiert beim Schreiben zuerst den alten Block in einen Reservebereich und ändert danach den Originalblock an seinem Platz. Jeder Schreibvorgang auf einen geschützten Block kostet damit einen zusätzlichen Lese- und einen zusätzlichen Schreibvorgang. Redirect-on-Write (RoW) lässt den Originalblock unangetastet, schreibt die Änderung in einen neuen Speicherbereich und aktualisiert anschließend die Metadaten. Das kostet beim Schreiben nichts Zusätzliches, führt aber dazu, dass zusammenhängende Daten über die Zeit auseinanderdriften.

Daraus folgt eine Faustregel, die häufiger gebraucht wird als die Theorie dahinter: Auf CoW-Systemen kostet ein offener Snapshot dauerhaft Schreibleistung, auf RoW-Systemen kostet er Ordnung. Das erste merkt man sofort, das zweite erst nach Monaten.

Der Sonderfall Hypervisor-Snapshot

Verwirrend wird der Begriff dadurch, dass Virtualisierungsplattformen etwas anderes tun als Speichersysteme. Ein Snapshot auf Hypervisor-Ebene stellt die Schreibzugriffe auf die Originalplatte ein, legt eine Delta-Datei an und schreibt ab dann nur noch dorthin; jeder weitere Snapshot erzeugt eine weitere Delta-Datei in einer Kette. Lesezugriffe durchlaufen diese Kette von hinten nach vorn, bis der Block gefunden ist.

Das Leibniz-Rechenzentrum beschreibt die Folge unmissverständlich: Ohne die Original-Festplatte sind sämtliche Delta-Dateien nutzlos. Ein Hypervisor-Snapshot ist damit nicht einmal eine eigenständige Datenkopie, sondern ein Änderungsprotokoll, das nur zusammen mit dem Original einen Sinn ergibt. Gesichert wird zudem der komplette Container samt Hardware-Version und Netzwerkzuordnung; ein Rücksprung setzt all das mit zurück.

Speicherverbrauch und sein Wachstum

Der belegte Platz eines Snapshots entspricht nicht der Datenmenge, sondern der Änderungsmenge seit seiner Erstellung. Das klingt nach wenig und wird deshalb unterschätzt. Ein Rechenbeispiel für 2 TB Nutzdaten bei zwei Prozent Änderung pro Tag, also rund 40 GB täglich:

Die letzte Zeile enthält den eigentlichen Punkt. Die obere Schranke läuft nicht ins Unendliche, sondern gegen die Größe des Datenbestands selbst: Sobald jeder Block einmal überschrieben wurde, hält der älteste Snapshot faktisch eine vollständige alte Version vor. Eine Jahreskette auf einem aktiven Bestand kann damit so viel Platz kosten wie eine zweite Kopie der Daten — ohne eine zu sein, weil sie auf demselben System liegt.

Die 24 bis 72 Stunden gelten ausdrücklich nur für Hypervisor-Snapshots; auf Array- und Dateisystemebene sind Ketten über Monate unproblematisch. Beides zu vermischen, ist der häufigste Auslegungsfehler.

Aufbewahrungsketten, die im Betrieb tragen

Eine brauchbare Kette folgt dem Muster, dass die Auflösung mit dem Alter abnimmt: frische Stände häufig und genau, alte Stände selten und grob. Ein bewährter Aufbau umfasst 24 stündliche, 14 tägliche, 8 wöchentliche und 12 monatliche Stände — zusammen 58 Wiederherstellungspunkte von einer Stunde bis zu einem Jahr zurück. Die Abstände ergeben sich aus dem maximal hinnehmbaren Datenverlust, die Frage nach dem Wiederherstellungsweg aus der maximal hinnehmbaren Ausfallzeit.

Was in dieser Rechnung regelmäßig fehlt, ist die Erkennungsdauer. Ein stiller Datenfehler — eine fehlerhafte Schnittstelle, ein Import mit falscher Zuordnung, eine schleichende Verschlüsselung — fällt oft erst nach Tagen auf. Reicht die Kette nur 14 Tage zurück, sind bei der Entdeckung alle Stände bereits vom Fehler durchsetzt. Die monatlichen Stände sind deshalb kein Luxus, sondern der einzige Teil der Kette, der eine späte Entdeckung überlebt.

Konsistenz bei laufenden Datenbanken

Ein Snapshot hält fest, was zu diesem Zeitpunkt auf dem Speicher steht. Was im Arbeitsspeicher der Anwendung liegt oder als Schreibvorgang noch unterwegs ist, hält er nicht fest. Daraus ergeben sich drei Konsistenzstufen mit sehr unterschiedlichen Folgen.

Crash-consistent entspricht dem Zustand nach einem harten Stromausfall: schreibreihenfolgetreu, aber ohne die noch offenen Transaktionen. Datenbanken kommen damit meist zurecht, weil sie beim Start ihr Transaktionsprotokoll abspielen — garantiert ist das nicht, und die Wiederherstellung dauert entsprechend. File-system-consistent hält zusätzlich das Dateisystem an, sodass keine halb geschriebenen Metadaten im Bild sind; die Anwendung weiß davon nichts.

Application-consistent bezieht die Anwendung ein. Unter Windows weist ein VSS-Writer die Datenbank an, offene Transaktionen abzuschließen und Puffer auf den Speicher zu schreiben, bevor der Snapshot ausgelöst wird; unter Linux übernehmen das vor- und nachgelagerte Skripte, die von Hand hinterlegt werden müssen. Microsoft beschreibt diese Abstufung in der Dokumentation zu Azure Backup und weist darauf hin, dass die anwendungskonsistente Variante einen Agenten in der Maschine erfordert, die crash-konsistente nicht.

Ein häufiger Irrtum: Ein misslungener anwendungskonsistenter Snapshot fällt nicht aus, sondern fällt zurück. Die Plattform erzeugt einen crash-konsistenten Stand, meldet Erfolg und hinterlässt einen Wiederherstellungspunkt, der weniger wert ist als angenommen. Diese Rückfälle stehen nur im Protokoll.

Snapshots gegen Ransomware — und wo die Grenze verläuft

Gegen Verschlüsselungsangriffe sind Snapshots das schnellste verfügbare Mittel: Ein Rücksprung dauert Minuten statt Stunden und benötigt keine Übertragung großer Datenmengen. Genau deshalb sind sie zu einem eigenen Angriffsziel geworden. Angreifer mit administrativen Rechten löschen vor der Verschlüsselung, was ihnen die Wirkung nehmen könnte: Schattenkopien, Snapshots auf dem Speichersystem, Aufbewahrungsregeln in der Sicherungssoftware.

Ein Snapshot, der mit denselben Zugangsdaten gelöscht werden kann, mit denen das System verwaltet wird, ist gegen einen Angreifer mit genau diesen Zugangsdaten wirkungslos. Daher der Zusatz „unveränderlich”: eine Aufbewahrungsfrist, die bis zu ihrem Ablauf niemand verkürzen kann — auch nicht der Administrator. Drei Eigenschaften machen den Unterschied:

1. Zeitgebundene Sperre Die Frist wird beim Anlegen gesetzt und lässt sich danach nur verlängern, nie verkürzen.
2. Getrennte Rechtebasis Die Verwaltung der Sperre hängt nicht an den Konten des laufenden Betriebs; im Idealfall braucht eine Änderung zwei Personen.
3. Manipulationssichere Zeit Die Frist bezieht sich auf eine Uhr, die sich nicht durch Zurückstellen der Systemzeit aushebeln lässt.

Fehlt eine davon, ist die Unveränderlichkeit eine Betriebsvereinbarung und keine technische Zusicherung. „Retention Lock” bezeichnet je nach Produkt unterschiedlich harte Garantien — hier lohnt der Blick in die Herstellerdokumentation.

Der Kern: derselbe Speicher, zwei verschiedene Risiken

Auch ein unveränderlicher Snapshot bleibt dort, wo die Daten liegen. Er überlebt einen Bedienfehler, einen Verschlüsselungsangriff und ein misslungenes Update. Er überlebt nicht den Ausfall des Speichersystems, einen Metadatenfehler im Dateisystem, ein Feuer im Serverraum oder die Löschung des gesamten Volumes samt aller darauf liegenden Stände.

Diese beiden Risikoklassen — Fehler im Datenbestand und Verlust des Datenträgers — decken unterschiedliche Verfahren ab. Der Snapshot deckt die erste schnell und feingranular ab, das ausgelagerte Backup die zweite, dafür langsamer und gröber. Keines deckt beide ab, und keine Konfiguration ändert daran etwas, weil der Unterschied im Speicherort liegt und nicht in der Software.

Das BSI formuliert die Konsequenz im Baustein CON.3 als Muss-Anforderung: Datensicherungen müssen immer auf separaten Speichermedien gespeichert werden. Snapshots erscheinen dort an anderer Stelle — als Prüfauftrag, ob ein System ergänzend durch Snapshot-Mechanismen gesichert werden kann, um schnell wiederherstellbare Zwischenversionen zwischen den vollständigen Datensicherungen zu erhalten. Die Reihenfolge in diesem Satz ist die eigentliche Aussage.

Einordnung in die 3-2-1-Regel

Die 3-2-1-Regel verlangt drei aktuelle Versionen wichtiger Dateien auf zwei verschiedenen Medien und an mindestens einem weiteren Ort; der BSI-Standard 200-4 nennt sie in den Vorschlägen zu BC-Strategien ausdrücklich als empfehlenswerte Grundlage. Setzt man eine Snapshot-Kette dagegen, ergibt sich ein klares Bild:

Eine Snapshot-Kette erfüllt also genau eine der drei Ziffern — und zwar die, die am wenigsten kostet. Die beiden teuren Anforderungen, zweites Medium und zweiter Ort, bleiben offen. Das erklärt, warum eine gepflegte Snapshot-Strategie in der Selbstauskunft beruhigend aussieht und in der Prüfung durchfällt.

Praktisch ergibt das eine Arbeitsteilung: Die Snapshot-Kette liefert Auflösung und Geschwindigkeit, das ausgelagerte Backup liefert Unabhängigkeit. Wer mit der Kette Stunden und Tage abdeckt, entlastet das Backup — es muss dann nur noch die Distanz liefern, nicht die feine Auflösung. Das ist auch der günstigere Zuschnitt, weil ausgelagerte Kapazität und Übertragungswege der teure Teil sind.

Was Snapshots nicht leisten

Langfristige Aufbewahrung. Ein Snapshot ist an Format und oft an die Baureihe des Speichersystems gebunden. Nach einem Systemwechsel in drei Jahren ist er nicht mehr lesbar, während ein Backup in einem dokumentierten Format weiter auswertbar bleibt. Für gesetzliche Aufbewahrungsfristen ist er deshalb kein Träger.

Suche über lange Zeiträume. Ein Snapshot liefert einen kompletten Stand. In welchem der 58 Stände eine bestimmte Datei zuletzt korrekt war, beantwortet er nicht — dafür braucht es einen Katalog, den Sicherungslösungen mitbringen und Snapshot-Mechanismen nicht.

Nachweis der Wiederherstellbarkeit. Dass ein Snapshot existiert, sagt nichts darüber, ob daraus ein lauffähiger Zustand entsteht. CON.3.A15 verlangt regelmäßige Tests, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können. Bei Snapshots wird dieser Test besonders oft ausgelassen, weil der Rücksprung so einfach aussieht.

Dazu ein Detail, das im Vorfall regelmäßig untergeht: Ein Rücksprung verwirft alle Änderungen seit der Erstellung — und mit ihnen die forensische Auswertung. Ein Snapshot des kompromittierten Zustands davor kostet Minuten und ist die einzige Gelegenheit dafür.

Häufige Fragen

Ist ein Snapshot ein Backup?

Nein. Ein Snapshot liegt auf demselben Speichersystem wie die Daten und schützt gegen Fehler im Datenbestand, nicht gegen den Verlust des Speichers. Bei Hypervisor-Snapshots sind die Delta-Dateien ohne die Original-Festplatte zudem gar nicht auswertbar. Das BSI verlangt in CON.3 separate Speichermedien und ordnet Snapshots als ergänzendes Mittel ein.

Was ist der Unterschied zwischen Copy-on-Write und Redirect-on-Write?

Copy-on-Write kopiert den alten Datenblock vor einer Änderung in einen Reservebereich und ändert danach den Originalblock. Redirect-on-Write schreibt die Änderung in einen neuen Bereich, lässt den Originalblock unangetastet und aktualisiert die Metadaten. Copy-on-Write belastet die Schreibleistung stärker, erzeugt dafür weniger Fragmentierung.

Wie lange darf ein Snapshot aufbewahrt werden?

Das hängt von der Ebene ab. Für Hypervisor-Snapshots empfehlen die VMware-Best-Practices etwa 24 bis 72 Stunden, weil die Delta-Dateien mit dem Alter wachsen und die Lese-Latenz über die Kette steigt. Auf Speichersystem- oder Dateisystemebene sind Wochen und Monate möglich; die Grenze setzt dort der Platzbedarf.

Was bedeutet anwendungskonsistent bei Datenbanken?

Er bezieht die Anwendung ein: Unter Windows weist ein VSS-Writer die Datenbank an, offene Transaktionen abzuschließen und Puffer auf den Datenträger zu schreiben, bevor der Snapshot ausgelöst wird; unter Linux übernehmen das vor- und nachgelagerte Skripte. Ein crash-konsistenter Snapshot erfasst nur, was auf dem Datenträger stand — wie nach einem Stromausfall.

Schützen Snapshots vor Ransomware?

Nur, wenn sie nicht löschbar sind. Angreifer mit administrativen Rechten entfernen Schattenkopien, Snapshots und Aufbewahrungsregeln, bevor sie verschlüsseln. Ein unveränderlicher Snapshot mit nicht verkürzbarer Frist hält dem stand. Das BSI nennt darüber hinaus das Offline-Backup als wichtigste präventive Maßnahme, weil ein getrennter Datenträger im Netz nicht erreichbar ist.