Snapshots - Was ist das und wozu sind sie gut?

[PROLOG]

QTS unterstützt schon lange ein Feature namens „Snapshot“, welches mittlerweile auch stark von QNAP umworben wird. Immer wieder wird auch im Forum geraten das Storage so zu erstellen, dass die Verwendung von Snapshots möglich ist, doch viele wissen schlichtweg nichts damit anzufangen. Auch ich gehöre zu denen, die stets dazu raten sich den Weg für die Verwendung von Snapshots freizuhalten, denn seit ich Snapshots verwenden kann, sind diese fester Bestandteil meiner Backupstrategie und auch sonst möchte ich weitere Möglichkeiten durch Snapshots nicht mehr missen wollen.

Was sind Snapshots eigentlich und was kann man damit anstellen? Wie stellt sich die Verwendung von Snapshots in QTS überhaupt dar? Diesen Fragen möchte ich auf den Grund gehen, dabei möchte ich aber keine Anleitung schreiben, sondern das Thema grundlegend anreißen und für ein kleines Bisschen mehr Verständnis sorgen.

[ALLGEMEINES]

Snapshots sind Momentaufnahmen von Volumes und spiegeln den Datenbestand eines Volumes zum Aufnahmezeitpunkt wieder. Dies erfolgt logisch adressiert, sprich in Form von Blöcken, also „Nullen und Einsen direkt vom Datenträger“ ohne dass ein Dateisystem involviert ist. Die Speicherung erfolgt direkt in einem Speicherpool, der obligatorisch für die Verwendung von Snapshots ist, mit statischen Volumes ist dies also nicht möglich. (Infos zu Volumes und Speicherpool findet ihr hier: Storage und Snapshots: Eine Übersicht zu Volume-Typen und Speicherpool)

Auch unterstützen nicht alle Geräte Snapshots, so werden mindestens 1GB RAM benötigt, außerdem hängt die Anzahl möglicher Snapshots von dem installierten RAM sowie der CPU ab. Durch die Verwendung von Snapshots wird die Performance eines Volumes, von dem Snapshots erstellt wurden, negativ beeinflusst. Je nach Größe und Anzahl der Änderungen sowie aufbewahrter Anzahl an Snapshots spricht QNAP hier von 5-30% Leistungseinbußen. Das liegt daran, dass Änderungen an Daten nach der Snapshoterstellung live im Snapshot, genauer gesagt im dafür vorgesehenen Speicherbereich, wiedergespiegelt werden müssen. QTS arbeitet nach dem „redirect on write“ Verfahren, dabei werden Änderungen an (relevanten) Blöcken im Snapshot-Speicherbereich vorgenommen. Das bedeutet, dass neue Daten-Blöcke, welche andere für den Snapshot relevanten Blöcke überschreiben würden, in diesen Bereich geschrieben werden statt auf das Volume selbst; auf dem Volume befinden sich also die „alten“ Daten, im Snapshot-Speicher die „Neuen“. Das führt dazu, dass die Daten stärker fragmentiert werden, denn wird von einer Datei, die aus 14 Blöcken besteht nur ein Block verändert, wird dieser eine Block in den Snapshot-Speicher geschrieben, die restlichen Blöcke verbleiben im Volume, sodass die Datei beim Lesen später aus beiden Speicherbereichen „zusammengesetzt“ werden muss. Die Festplatte muss somit deutlich mehr arbeiten, da die Datei an mehreren, nicht zusammenhängenden Stellen liegt, was zudem auch mehr Rechenpower erfordert, insbesondere wenn Snapshots gelöscht und neue erstellt werden. Je mehr Snapshots und Änderungen bestehen, desto „komplizierter“ wird es somit für das System damit umzugehen.
Ich versuche es mal grafisch darzustellen:

snapshot_blocks.PNG
(Grafik 1: Verteilung der Blöcke nach Snapshoterstellung und Änderung. Bei Löschung eines Snapshots werden die Blöcke aus dem Snapshot Speicherbereich in den Volume Speicherbereich geschrieben.)

Snapshots speichern also nur getätigte Änderungen an relevanten Blöcken und beanspruchen somit nur wenig Kapazität. Wird zum Beispiel eine 1GB Datei gelöscht und überschrieben [1], ist der Snapshot nur (etwa) 1GB groß, weil eben nur diese Änderung im Snapshot wiedergespiegelt werden muss, nicht aber unveränderte Datenstände.

[1] Ein einfaches Löschen lässt den Snapshot noch nicht anwachsen, da ein Löschen nur den Eintrag im Dateisystem entfernt, nicht aber die eigentlichen logischen Daten (Blöcke). Erst wenn die verbliebenen logischen Daten durch neue Daten überschrieben werden sollen, muss der Snapshot „aktiv“ werden und diese Änderungen wiederspiegeln, wodurch nun entsprechende Kapazität verwendet wird.

Durch die logische Adressierung und weil eben nur Änderungen vermerkt werden, sind Snapshots sehr schnell innerhalb weniger Sekunden erstellt und können (fast) ebenso schnell wiederhergestellt werden.

Bei den Snapshots unterscheidet man zwischen lokalen Snapshots, die im Speicherpool des Systems selbst gelagert werden, sowie Remote-Snapshots (Snapshot Replica), welche auf einem anderen System in einem Speicherpool gelagert werden. Bei Letzteren nimmt der erste Snapshot allerdings die gesamte Volume-Kapazität ein, da dieser die Basis für weitere Snapshots bildet, bei denen dann auch wieder nur die Änderungen ins Gewicht fallen.

Da Snapshots logisch adressiert sind und nicht auf Dateiebene liegen, haben „normale“ Anwendungen keinen Zugriff darauf, weshalb Snapshots nachgesagt wird, dass Malware nicht darauf zugreifen kann und Snapshots daher vor Malware schützen. Mehr dazu später.

[ERSTELLUNG VON LOKALEN SNAPSHOTS]
Snapshots werden in Storage und Snapshots > Storage/Snapshots verwaltet. Über den Button „Snapshot“ oben rechts kann man einen Snapshot vom gewählten Volume erstellen oder den Snapshot Manager aufrufen, in dem man die Aufnahme von Snapshots nach Zeitplan sowie die Aufbewahrungsrichtlinie festlegt. An dieser Stelle kann man auch Snapshots wiederherstellen. Außerdem wird man hier auf den für Snapshots reservierten Speicherplatz hingewiesen. Mit dieser Einstellung legt man fest, wie viel Kapazität eines Pools für Snapshots reserviert sind. Damit wird sichergestellt, dass keine Snapshots gelöscht werden, wenn die Kapazität von Volumes benötigt wird. Wird keine Kapazität reserviert, werden Snapshots dennoch abgelegt, aber gelöscht sobald die Kapazität anderweitig benötigt wird (z.B. durch Erstellen eines neuen Volumes oder durch die automatische Zuweisung bei Thin Volumes).

Sind Snapshots aufgenommen wurden, so wird dies mit einem Kamerasymbol in Storage/Snapshots angezeigt. Ein Klick darauf bringt einen direkt in den Snapshot Manager.

01_StorageSnapshots.PNG
(Bild 1: Storage- und Snapshots)

Der Snapshot-Manager ist eine Art Dateibrowser, mit dem man sich den Datenbestand zum Aufnahmezeitpunkt anzeigen kann. Dabei werden natürlich alle Daten angezeigt und nicht nur solche, die verändert wurden und „Bestandteil“ des Snapshots sind (Da hier ja nur einzelne Blöcke gespeichert werden und nicht (immer) ganze Dateien, ist dies auch gar nicht anders möglich).

02_Snapshotmanager.PNG

(Bild 2: Snapshotmanager)

Hier hat man nun auch die Möglichkeit die Daten aus dem Snapshot auf verschiedene Weisen abzurufen, bzw. wiederherzustellen.
Die Auswahl des entsprechenden Snapshots erfolgt in der linken Zeitleiste, wem das zu unübersichtlich ist, der hat die Möglichkeit auch eine Listenansicht (allerdings ohne Dateibrowser) zu wählen.

[SNAPSHOT WIEDERHERSTELLEN]
Über den Button „Restore“ hat man die Möglichkeit einzelne Dateien und Verzeichnisse wiederherzustellen, dabei kann man wählen, ob die Datei dort wiederhergestellt werden soll, wo sie ursprünglich war, oder in einem anderen Verzeichnis.

Mit dem Button „Clone“ wird aus dem Snapshot ein neues Volume erzeugt, also parallel zu dem bereits bestehenden Volume, was selbstredend auch die volle Volume-Kapazität erfordert (bzw. bei Thin Volumes nur die belegte Kapazität).

Mit „Revert Volume Snapshot“ wird das Volume in den Zustand zum Aufnahmezeitpunkt zurückversetzt, sodass alle in der Zwischenzeit getätigten Änderungen verworfen werden. QTS empfiehlt dabei vorher einen neuen Snapshot zu erstellen, damit Änderungen bei Bedarf doch noch beibehalten werden können. Sollten auf dem Volume Apps installiert sein, werden auch diese in den Zustand zum Aufnahmezeitpunkt versetzt.

[SNAPSHOTS AUSLAGERN - REPLICA UND VAULT]

Über den Menüpunkt „Snapshot Replica“ kann man lokale Snapshots auf ein anderes QNAP NAS auslagern. Die Übertragung erfolgt dabei mittels SSH über das Netzwerk. Da es erforderlich ist, dass auf dem Zielsystem ein initialer Snapshot mit voller Kapazität als Basis liegt, hat man die Möglichkeit den ersten Snapshot auf einen externen Datenträger als Image-Datei zu übertragen und ihn darüber in das Remote System zu verbringen. (Nein, ich weiß nicht, ob diese Imagedatei in anderen Systemen anderweitig verwendet werden kann )

Auch hier wird festgelegt, wie oft Snapshots übertragen werden sollen und wie viele Snapshots aufbewahrt werden. Dabei kann man auch entscheiden, ob nur bereits vorhandene lokale Snapshots übertragen werden, oder ob ein neuer Snapshot aufgenommen und übertragen werden soll. Einmal angelegt, erhält man hier Informationen über die remote gespeicherten Snapshots, sofern das Zielsystem online ist.

Das Gesicht auf dem Schutzschild wird übrigens erst glücklich, wenn von allen Thin- oder Thick Volumes des Pools mindestens ein Snapshot mit Replica vorhanden ist. Das spornt zwar etwas an, aber ich werde ihm den Wunsch dennoch nicht erfüllen

03_replica.PNG

(Bild 3: Snapshot Replica)

Während auf dem Quellsystem von „Snapshot Replica“ gesprochen wird, finden wir diese Snapshots auf dem Zielsystem im „Snapshot Vault“ wieder. Zudem werden die Volumes der Snapshots auch direkt eingebunden und sind somit über die Filestation abrufbar, natürlich in allen vorhandenen Versionen. Die Volumes werden auch entsprechend unter „Storage/Snapshots“ angezeigt, beim Volume-Typ enthalten sie den Hinweis, dass es sich um ein Snapshot-Volume aus dem Vault handelt.

04_2_vault_volumes.PNG

(Bild 4-2: Vault Volumes)

Im Snapshot Vault haben wir recht identische Möglichkeiten mit den Snapshots wie auf dem Quellsystem: Man kann die Snapshot-Versionen durchsehen und einzelne Dateien in gewünschten Ordnern wiederherstellen oder ein (richtiges) Volume aus einem Snapshot erstellen (Clone). Ein Clone ist allerdings nur auf dem Ziel-/ Vaultsystem möglich, man kann also kein neues Volume auf ein anderes Gerät schreiben. Möchte man Daten auf ein anderes Gerät, z.B. das Quellsystem wiederherstellen, muss dies über einen in der Filestation erstellen Remote-Mount auf Dateiebene erfolgen. Möchte man auf Blockebene bleiben kann man ansonsten einen Snapshot auf einen externen Datenträger exportieren um ihn dann im entsprechenden System zu verwenden; hierbei gilt zu beachten, dass auf dem Datenträger die gesamte Kapazität des zu exportierenden Volumes verfügbar sein muss, die Übertragung erfolgt auch hier als Image-Datei. Alternativ überträgt man die Daten auf Dateiebene mittels HBS3 oder einfach mittels anderen Datenübertragungsprotokollen, denn die Snapshot-Volumes sind ja bereits wie ein Volume eingebunden und können verwendet werden, Änderungen an Daten sind jedoch nicht möglich, die Vault Volumes sind also read-only.

Zu beachten ist, dass alle Snapshots im Vault gelöscht werden müssen, nachdem die Volumegröße auf dem Quellsystem verändert wurde.

04_vault.PNG

(Bild 4: Snapshot Vault) - Hinweis: Auf dem Screenshot werden nicht alle erstellten Replica abgebildet, die Fehlenden befinden sich in einem anderen Pool.

[WARUM EIGENTLICH SNAPSHOTS?]
Zugegeben, Snapshots klingen kompliziert, die Verwaltung durch das System ist es auch und daher mit entsprechenden Leistungseinbußen verbunden. Aber wenn ich doch so ein Verfechter von Snapshots bin, wozu setze ich sie dann ein?

Mein erstes Pro für Snapshots geht an die Versionsverwaltung von Windows. Aktiviert man diese Option in den Einstellungen einer Freigabe, kann man bequem aus Windows heraus ältere Dateiversionen abrufen, sofern es entsprechende (lokale) Snapshots des entsprechenden Volumes gibt. Daheim ist das für mich nur ein nettes Feature, auf der Arbeit allerdings von unschätzbarem Wert, vor allem wenn mehrere Personen mit einer Datei arbeiten und jemand mal Mist baut. Außerdem hat jeder nicht-Admin die Möglichkeit eine ältere Dateiversion bei Bedarf abzurufen. Die Versionierung stellt sich in Windows wie folgt dar. Hätte ich mehrere Änderungen zwischen den 12 Snapshots getätigt, würde ich für die Datei natürlich auch mehrere Versionen angezeigt bekommen.

05_windows_versionierung.PNG
(Bild 5: Dateiversionen in Windows 10)

Eine weitere Verwendung von Snapshots mag in meinem Fall eher speziell sein, prinzipiell könnte dies aber auch für Andere von Interesse sein:

Ich habe in der Vergangenheit sehr oft LAN Parties veranstaltet und dazu eine Freigabe bereitgestellt, auf der grundlegend benötigte Daten wie Modifikationen, Updates, etc. abgelegt waren. Natürlich wurde diese Freigabe auch für den weiteren Datenaustausch am Abend verwendet. Nicht selten kam es dabei vor, dass jemand versehentlich Daten verschoben/ ausgeschnitten hat und sie anschließend verschwunden waren. Ganz klar ist auch, dass ich nicht überblicken kann, was dort unter Umständen für Daten abgelegt/ ausgetauscht werden: von virenbefallenen bis illegalen Daten kann hier alles dabei sein! Nach so einer LAN Party brauchte ich also nicht die gesamte Freigabe durchwühlen, sondern habe das Volume (!!! das ausschließlich für diese Freigabe verwendet wird !!!) schlichtweg auf den letzten Snapshot zurückgesetzt, sodass alle ursprünglichen Daten wieder da sind und alles Mistzeugs verschwunden ist.

Thema „Malware“ hatte ich eingangs kurz angesprochen, hier steckt natürlich Wahres dran und auch davon profitiere ich dank Snapshots: Da Malware, welche man sich auf einem Client einfängt auf Dateiebene arbeitet, kann diese zwar unter Umständen Dateien in Volumes und Freigaben verschlüsseln, kommt aber nicht an die Snapshots heran. Sollte im blödesten Fall also jedes dateibasierte Backup durch Malware verschlüsselt worden sein, so bleiben immer noch die Snapshots. Unter Umständen jedenfalls…

Denn würden alle Daten verschlüsselt (verändert) werden, so würde der aktuelle Snapshot auch auf eine unheimliche Größe anwachsen, wofür ausreichend Kapazität erforderlich wäre. Werden also 1TB an Daten verschlüsselt/ geändert, so muss für den Snapshot auch 1TB Kapazität im Pool frei sein, damit die Änderungen entsprechend wiedergespiegelt werden können und eine Wiederherstellung möglich ist. Ist nicht ausreichend Kapazität vorhanden, versetzt QTS den Datenträger allerdings in den Read/ Delete Modus und gibt entsprechende Warnungen aus, fraglich bleibt hierbei, wie sich dies auf die Ransomware auswirkt, jedenfalls kann diese ab diesem Moment nicht weiterarbeiten. In einem Test (Überschreiben von Daten) ist dies bereits eingetreten, als noch 30% Kapazität frei waren, allerdings „wusste“ QTS in diesem Fall welche Datenmenge auf das System zukommt. Es bleibt auch anzumerken, dass Ransomware meist nur kleinere Dateien und auch nicht die komplette Datei verschlüsselt, also bei einer 1GB Datei nicht auch 1GB geändert werden, sodass Snapshots durchaus vor auf Clients ausgeführter Ransomware schützen können; das zuvor genannte Szenario stellt demnach eine krasse Ausnahme dar. Snapshots schützen allerdings nicht vor Malware, die QNAP NAS direkt befällt, denn aktuelle QNAP-Malware ist in der Lage die Snapshots einfach vom System zu entfernen, so als würde man auf „Snapshot löschen“ klicken.

Ich erwähnte eingangs auch, dass Snapshots Teil meiner Backupstrategie sind. Die Betonung liegt hierbei auf „Teil“, denn zumindest ein lokaler Snapshot kann nicht als vollwertiges Backup betrachtet werden. Tatsächlich verwende ich lokale Snapshots allerdings in erster Instanz, wenn Daten überschrieben wurden oder eine ältere Dateiversion benötigt wird, denn bevor ich ein Backupsystem hochgefahren habe um eine Datei wiederherzustellen, habe ich das Dank Snapshots in kürzester Zeit längst erledigt. Snapshots sind für mich im Sinne des Backups also in erster Linie hilfreich um eine Wiederherstellung schnellstmöglich realisieren zu können, vor Systemausfall schützt das natürlich nicht. Die Snapshot Replica, also die ausgelagerten Snapshots auf ein System, welches ausschließlich dazu dient Snapshots zu empfangen, sind für mich eine weitere Versionierung des Datenbestands zu meinen anderen Backups (die zu anderen Uhrzeiten erstellt werden), könnten ein versioniertes Backup mit HBS3 aus meiner Sicht aber durchaus ersetzen.

HBS3 ist auch nochmal ein gutes Argument, zumindest für die Verwendung eines Speicherpools, der Snapshots überhaupt erst ermöglicht. HBS3 bietet dann die Möglichkeit, vor dem Backup einen temporären Snapshot zu erstellen (der ist für den User nicht sichtbar) um die Daten „daraus“ an das Ziel zu übertragen. Damit umgeht man etwaigen Problemen, wenn Daten während des Backups mit HBS3 anderweitig in Verwendung sind.

Auch die Tatsache, dass Apps durch Snapshots in den Zustand zum Aufnahmezeitpunkt versetzt werden können, finde ich sehr interessant und geil das in der Hinterhand zu haben, gebraucht habe ich das allerdings noch nicht, zumal die meisten meiner Apps auf einer SSD mit statischem Volume liegen (die SSD sind leider zu klein um einen Speicherpool zu erstellen).

[ANMERKUNGEN]

In den Snapshots ist einer der Gründe dafür zu finden, weshalb ich vornehmlich Thin-Volumes einsetze: Aufgrund der dynamischen Kapazitätszuweisung (siehe Storage und Snapshots: Eine Übersicht zu Volume-Typen und Speicherpool) kann die nicht zugewiesene Kapazität unabhängig vom für Snapshots reservierten Speicher ebenfalls für Snapshots genutzt werden, zumindest temporär im Ernstfall. Werden Snapshots per Replica ausgelagert, wird auch am Zielsystem nur jene Kapazität eingenommen, die dem Volume auch wirklich zugewiesen ist.

Auch ist in den Snapshots einer der Gründe zu finden, weshalb ich stets mehrere kleine Volumes verwende, statt ein Großes: Ich kann Snapshots schlichtweg besser skalieren, denn für manche Volumes auf denen sich viel Irrelevantes ändert (z.B. mein Volume für temporäre Sat-Aufnahmen) will ich überhaupt keine Snapshots haben, da sie ständig ins Unermessliche wachsen würden. Von anderen Volumes hingegen möchte ich mehr, von anderen weniger Snapshots/ Versionen haben. Auch meine oben genannte Anwendung mit der Wiederherstellung der „Datenaustausch-Freigabe“ erfordert ein eigenes Volume, schließlich will ich ja nur den „statischen“ Datenbestand zurücksetzen, nicht aber Daten, mit denen ich normalerweise arbeite.

[EPILOG]
Snapshots bieten ein paar schöne Möglichkeiten, ob und wie sehr interessant diese sind muss natürlich jeder für sich selbst wissen, vor allem der Kompromiss mit den Leistungseinbußen dürfte viele davon abhalten Snapshots zu verwenden. Ich für meinen Teil merke praktisch nichts von diesen Einbußen und bin mir sehr sicher, dass es viele andere auch nicht tun würden, es ist also eher abschreckenden Charakters. Zu beachten bleibt dennoch eine Menge bei der Verwendung von Snapshots, über das man sich bereits beim Erstellen von Volumes Gedanken machen muss. Ich hoffe ich konnte einen Großteil davon aufzeigen und euch die Funktion sowie die Vorzüge von Snapshots etwas näher bringen.

Snapshots haben finde ich irgendwie etwas von „Und täglich grüßt das Murmeltier“… tatsächlich ist auch schon wieder Freitag… also wie üblich: cheers!