Snapshot - Shadow Copy / Zustandskopie auf Festplatten mit geringem Speicherplatz

Einführung in Snapshot

Ein Snapshot friert den Zustand von Daten zu einem bestimmten Zeitpunkt ein. Ab diesem Moment werden die Daten im SnapShot nicht mehr verändert, die produktiven Daten können aber weiterhin verändert werden.
Wofür benötigt man diese Funktion? Einmal für die Datensicherung, der SnapShot wird sehr schnell erstellt und danach ist die Quelle wieder für Änderungen nutzbar. Und zum anderen für eine schnelle Kopie, zum Biespiel vor Pataches oder größeren Änderungen. Gehen die Änderungen schief, kann sehr schnell (ohne Backup / Recovery) zurückgesetzt werden.

Aber sind die Daten deswegen immer konsistent im SnapShot? Die Erstellung geht doch sehr sehr schnell? Nein, ein Snapshot ist nicht deswegen konsistent, weil er schnell erstellt wird. Sondern die Daten müssen konsistent gemacht werden, also zum Beispiel über die Datenbank oder eine Anwendung. Ohne diesen Vorgang sind die Daten dann evetuell nicht brauchbar.

Die ersten Snapshot Technologien sind für schnelle Datensicherung und Rücksicherungen mit geringer Downtime entwickelt worden. Müssen Datenmengen von mehreren Terabyte gesichert werden, so dauert dies relativ lange. Ein einfaches Beispiel: Sie möchten 20 TB mit einem LTO-6 Laufwerk sichern. Dieses Laufwerk schafft eine Transferrate von 160 MB/s (unkomprimiert). Sie benötigen also ca. 36 Stunden für die Sicherung. Jetzt brauchen wir natürlich eine konsistente Sicherung, aber können Applikationen und Datenbanken meist nur für eine sehr kurz Zeit heruntergefahren. Also kurzer Stopp für die Erstellung des Snapshots (Zustandskopie nicht Datenkopie) und dann kann von der Kopie (dem Snapshot) gesichert werden, während die Applikation oder Datenbank schon wieder läuft. Die Vollsicherung dauert immer noch 36 Stunden, aber die Applikation oder Datenbank kann nach wenigen Sekunden wieder gestartet werden.

Anmerkung: Wenn die Datenbank oder Anwendung einen Backup-Modus besitzt, muss die Applikation noch nicht einmal kurz gestoppt werden.

Shadow Copy in der Theorie

Um die Datenmenge von zum Beispiel 200 GB zu kopieren benötigen selbst Festplatten noch eine gewisse Zeit. Also machen wir uns das Gegenteil zu Nutze und trennen einen vorhandenen Datenspiegel auf. Dafür benötigen wir nur wenige (Milli-) Sekunden und das nahezu unabhängig vom Datenvolumen. Ist der Spiegel abgetrennt, so können die Daten in aller Ruhe von der nicht benutzten Spiegelseite gesichert werden, diese werden ja nicht durch die User oder Applikationen verändert. Danach wird der Backup-Spiegel wieder zum Produktions-Spiegel hinzugefügt und es werden die Änderungen nach gefahren. Dies braucht natürlich seine Zeit, stört aber nicht weiter. Nachteil: Sie benötigen mindestens doppelt so viel Speicherplatz und eben nicht nur einen geringen Speicherplatz.

Weiterentwicklung des Zustandsabbildes

Ein großes Problem bei diesem Snapshot im Grunddesign der Gesamtkopie ist der enorme Festplattenverbrauch und die damit verbundenen Kosten. Zum Teil wird nur ein sehr geringer Teil der Daten verändert. Also müssen nicht alle Daten kopiert werden. Zum Zeitpunkt des Snapshots wird das Filesystem "eingefroren", die Datenbank in den Backup-Modus versetzt oder die Anwendung kurz heruntergefahren. Danach werden alle Änderungen nicht in den Originalblöcken durchgeführt, sondern in Kopien dieser Blöcke. Jetzt wird nur noch der wirklich veränderte Teil der Daten "doppelt" vorgehalten. Die Anwendung kann in kurzer Zeit wieder gestartet oder die Datenbank in den Normalmodus zurückversetzt werden.
Dieses Verfahren ist einfacher auf Filesystemen und damit bestimmte Betriebssystemen anzuwenden. Daher ist es auch bei NAS (Network Attached Storage) sehr verbreitet.

Diese Snapshot-Technologien nutzen also das gleiche Prinzip, benötigen aber nur die wirklich veränderten Daten. Ergebnis ist ein Snapshot mit geringem Speicherplatz, der aber mit laufender Zeit immer größer wird. Je nach Verfahren (siehe unten) gibt es Vor- und Nachteile.

Copy-on-Write (COW) und Redirect-on-Write (ROW)

Es gibt zwei grundsätzlich verschiedene Verfahren einen Snapshot zu verwalten. Das erste ist das Copy-on-Write (COW), dabei werden bei jeder Schreiboperation die Daten vorher auf den Snapshot-Bereich kopiert. Die geänderten produktiven Daten gehen an die ursprünglichen Bereiche auf der Festplatte. Bei diesem Verfahren wird die Fragmentierung der Daten reduziert, allerdings benötigen Schreiboperationen mehr Zeit, da die Ursprungsdaten vorher und Just-in-Time wegkopiert werden müssen. Ein weiteren Vorteil hat das Copy-on-Write: Wird der Snapshot verworfen oder aufgelöst, so kann der Snapshot-Bereich einfach gelöscht werden. Dort sind ja nur alte Daten.
Beim Redirect-on-Write (ROW) werden Änderungen in den produktiven Daten auf den Snapshot-Bereich geschrieben. Die alten Daten bleiben am Original-Ort erhalten. Dies verursacht dann eine starke Fragmentierung im Datenbereich, da Teile im Ursprungsbereich liegen und andere im Snapshot. Die Schreiboperationen sind im Vergleich zu COW genauso schnell wie ohne den aktiven Snapshot. Aber was passiert wenn der Snapshot aufgelöst werden soll? Die Daten im Snapshot werden noch gebraucht, es sind ja die produktiven Daten. In diesem Fall müssen die Daten vom Snapshot in den produktiven Bereich kopiert und verlagert werden. Dies dauert eine gewisse Zeit und verursacht beim Auflösen eine große Belastung auf den Platten.
Das Copy-on-Write Verfahren wird zum Beispiel von Microsoft VSS, IBM beim FlashCopy und beim Linux Logical Volume Manager eingesetzt. Das Redirect-on-Write nutzt NetApp bei ihren Filern.

Copy-on-Write (COW)	Redirect-on-Write (ROW)
langsamere Schreiboperationen	Schreiboperation nahezu unabhängig
schnelle Auflösung	lange Laufzeit beim Auflösen
mehr IOs bei Schreiboperationen	mehr IOs beim Auflösen
geringe Fragmentierung	große Fragmentierung
nur wenige Snapshots möglich	große Anzahl von Snapshots möglich

Software- / Hardware

Sowohl die Trennung von Master-Daten und Spiegel, wie auch COW oder ROW Snapshots, wie auch die nachfolgende Synchronisierung der Daten bzw. Auflösung der Snapshots können vom angeschlossenen Server, wie auch der Storage-Hardware ausgeführt werden. Beide Verfahren haben Vor- und Nachteile. Beim Block-Snapshot mit Redirect-on-Write kommt noch eine verstärkte Fragmentierung der Festplatte hinzu.

Software Zustandsabbild

Vorteil	Nachteil
einfache Steuerung des Ablaufes	größer 2 % Prozessorbelastung im Normalbetrieb
läuft im Betriebssystem	größer 10 % Prozessorbelastung bei der Synchronisation
meist kostengünstiger	für jeden Server eine eigene Lösung

Hardware Zustandsabbild

Vorteil	Nachteil
geringe Belastung	komplexe Steuerung
eine Lösung für alle Server	meist teurer
Transparent für das Betriebssystem	komplexe Nutzung der Snapshots

Einsatz-Beispiel Shadow Copy bei Windows Servern

Eine beispielhafte Implementierung dieser Technologie ist im Microsoft Windows Server zu finden. Dieses Betriebssystem ermöglicht Snapshots auf Blockebene, wie auch auf File-Ebene. Dies wird bei Microsoft als "Volume Shadow Copy Service" (VSS) oder kurz Shadow Copy bezeichnet.
Diese Snapshots können in bestimmten Zeitintervallen durchgeführt werden. Sollten Dateien gelöscht oder irrtümlich verändert worden sein, so kann der Administrator oder der Endanwender über ein Zusatzfeld im Explorer alte Versionen wiederherstellen bzw. gelöschte Dateien recovern.

Das VSS (Volume Shadow Copy Service) wird auch bei der Sicherung von Systemdatenbanken (z.B. der Registry) oder Microsoft SQL Server verwendet.

Einsatz-Beispiel Snapshot bei KVM Virtualisierung / Proxmox

In der KVM Virtualisierung von Servern wird der Snapshot für die konsistente Sicherung eingesetzt. Der Hypervisor benachrichtigt die virtuelle Maschine über einen bevorstehenden Snapshot. Diese führt zum Beispiel als Windows VM dann einen VSS Snapshot durch. Ist dies erfolgreiche, dann kann der Hypervisor den Snapshot einrichten und erstellen. Danach kann die virtuelle Maschine normal weiterarbeiten. Die Änderungen aus der virtuellen Maschine gehen nicht mehr in die Originaldatei der Virtualisierung, sondern in den Snapshot (dies ist aber auch eine Datei).

Na ja, so einfach ist es nicht. Der Befehl virsh snapshot-create-as <name der VM> erstellt nur den Snapshot, sichert aber NICHT die Konsistenz der virtuellen Maschine ab. Das muss vor dem virsh-Befehl durchgeführt werden. Im einfachsten Fall über ein Skript auf der jeweiligen VM, das remote gestartet wird. Die Lösung ist nicht sonderlich kompliziert, kann aber schnell sehr komplex werden.

Damit haben wir den Snapshot, in dem ab jetzt die Änderungen der virtuellen Maschine geschrieben werden. Die eigentliche Datei kann also gesichert werden, wieder recht einfach mit copy, oder mit rsync auf einen externen Backup-Server. Was dabei wichtig ist: Der reine Snapshot hat nichts mit einer Vollsicherung oder einer inkrementellen Sicherung zu tun. Die Datei enthält die gesamte VM, der weitere Schritt bestimmt, ob dies eine inkrementelle Sicherung wird. Wenn die Datei mit cp kopiert wird, dann ist es eine Vollsicherung, die gesamte Datei wird kopiert. Nehmen wir zum Beispiel rsync, dann werden nur die Teile übertragen, die noch nicht auf dem Ziel sind, also eine inkrementelle Sicherung. Nur die Änderungen werden übertragen. Auf dem Ziel (dem Backup-Server) kann vorab die Datei wieder auf ein anderes Ziel kopiert werden, dann erhalten wir unterschiedliche Versionen auf dem Backup-Server. Aber nicht als klassische inkrementelle Sicherungen, sondern als fertige Sicherungen zu bestimmten Zeitpunkten. Insgesamt noch schneller im Restore, da nur eine Datei kopiert und nicht die inkrementellen Teile zusammengefügt werden müssen.

Proxmox bietet mit dem eigenen Backup-Server deutlich mehr Features und Möglichkeiten. Dies schließt sowohl Vollsicherungen, wie auch ein "Incremental Forever Backup" mit ein, sowie eine konfortable Verwaltung und Überwachung.

Zusammenfassung: Konsistente Daten beim Zustandsabbild

Wird ein Snapshot von einer Datenbank oder einer Anwendung erstellt, so ist dieser nicht unbedingt konsistent. Na ja, der Snapshot an sich ist konsistent, aber nicht die Daten. Warum denn das? Wird ein Snapshot zum Beispiel durch Abtrennung erzeugt, dann ist der Zeitpunkt des SnapShopts für alle Daten (von Anfang bis Ende) gleich. Wenn jetzt aber genau vor dem Zeitpunkt der Trennung die Applikation eine Schreib-Operation begonnen hat, aber erst nach der Trennung abschließt, dann sind die Daten nicht konsistent auf dem Abbild. Also ist der Snapshot nicht zu gebrauchen, die Datenbank auf dem Snapshot würde einfach nicht starten (Fehlermeldung bei Oracle: ORA-01113: file x needs media recovery).
Also muss vor dem Erstellen des Snapshots die Anwendung oder Datenbank in den konsistenten Zustand gebracht werden. Eine genauere Erklärung finden Sie bei den Online- / Offline Datensicherungen.
Aber was ist denn jetzt der Vorteil eines Snapshots gegenüber der Sicherung der direkten Daten? Ein Snapshot wird sehr schnell erzeugt und ist in wenigen Sekunden einsatzbereit. Die Anwendung oder Datenbank muss also nur sehr kurz im Backup-Zustand gehalten werden. Dies hat Vorteile für die aktive Nutzung der Datenbank. Ist der Snapshot erst einmal erstellt, kann dieser dann ohne Gefahr von Veränderungen oder übergelaufener Log-Files gesichert werden.