[Support]  [Forum]  [Newsletter]       [Suche]  [Kontakt]  [Impressum]  [Datenschutz]

Stor IT Back - Ihr Speicherspezialist

  [Angebote]   [Produkte]   [Schulungen]   [Firmenprofil]   [Partner]   [Kunden]   [Information]   [Download]   [News]

LOGO Stor IT Back

SnapShot V1.4 (c) Stor IT Back 2019


SnapShot - Shadow Copy / Zustandskopie auf Festplatten mit geringem Speicherplatz


Einführung in SnapShot

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 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 nachgefahren. 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.

SnapShot Theorie

Weiterentwicklung des SnapShots

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)
Nachteil SnapShot langsamere Schreiboperationen Vorteil SnapShot Schreiboperation nahezu unabhängig
Vorteil SnapShot schnelle Auflösung Nachteil SnapShot lange Laufzeit beim Auflösen
Nachteil SnapShot mehr IOs bei Schreiboperationen Nachteil SnapShot mehr IOs beim Auflösen
Vorteil SnapShot geringe Fragmentierung Nachteil SnapShot große Fragmentierung
Nachteil SnapShot nur wenige SnapShots möglich Vorteil SnapShot große Anzahl von SnapShots möglich

Software- / Hardware-SnapShot

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


Hardware Zustandsabbild

Vorteil Nachteil
Vorteil geringe Belastung Nachteil komplexe Steuerung
Vorteil eine Lösung für alle Server Nachteil meist teurer
Vorteil Transparent für das Betriebssystem Nachteil 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

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.


Snapshots und konsistente Daten

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. 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.


Angebote der Stor IT Back zum Thema

Angebot Windows Storage Server 2016
Microsoft Windows Storage Server 2016
NAS (Network Attached Storage) WSS

19" 3 oder 2 HE / Gigabit Ethernet / redundante Netzteile
SAS-Hardware-RAID / Intel 6 Core Prozessor / 16 GB RAM
ab 4.588,00 Euro
zzgl. MwSt.
Angebot Dell EMC Unity 300
Dell EMC Unity 300 Unified Storage für den Mittelstand
FC / iSCSI und NAS - to - SAS-/SSD RAID-System

SSD / Flash-Drive für FAST Cache oder FAST VP
inkl. Installation, Abnahme und Einweisung in DE
ab 12.682,00 Euro
zzgl. MwSt.
Angebot Netapp FAS2700
NetApp FAS2700 mit Dual Controller Unified Storage
4 x UTA2 Ports und 2 x 10 Gbit/s LAN pro Controller

FAS2750 mit 24 x 2,5", FAS2720 mit 12 x 3,5"
Fibre Channel, CIFS, iSCSI und NFS, inkl. Installation vor Ort
Preis
auf Anfrage
 
 
Zurück zur Übersicht
SnapShot
Übersicht der Angebote
Kontakt zur Stor IT Back
Suche auf der Webseite