Warum Snapshots nur temporär verwendet werden sollten

Snapshots sind eine tolle Sache: einen Snapshot erstellen, etwas ausprobieren und entweder wird das Ergebnis für die Ewigkeit konserviert (indem der Snapshot dauerhaft in die virtuelle Maschine übernommen wird) oder es geht zurück auf den Stand des Snapshots, weil man die Änderung nicht behalten möchte.

Da Snapshots sowohl Speicherplatz benötigen als auch Leistung kosten sollte darauf geachtet werden, sie lediglich temporär einzusetzen.

Hier ein an manchen Stellen vereinfachter Erklärungsversuch, die verwendeten Farben bedeuten folgendes:

Ausgangsszenario

Eine virtuelle Maschine speichert ihre Festplatte in einer Datei “Festplatte” (dazu kommt noch die ein oder andere Verwaltungsdatei, diese sind aber für die Betrachtung unerheblich). Diese Festplatte ist in viele Blöcke einer festen Größe unterteilt, in der die Daten liegen.

Diese Datei hat eine maximale Größe, welche der für die Festplatte festgelegten Kapazität entspricht. Sämliche Lese- und Schreibzugriffe finden innerhalb der Datei “Festplatte” statt.

Snapshot “Snapshot 1”

Nun wird ein Snapshot “Snapshot 1” angelegt. Ab diesem Moment wird auf die Datei “Festplatte” nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend (neue Dateien, geänderte Dateien etc …) werden in der Datei “Snapshot 1” gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei “Festplatte” (Blöcke 2, 4 und 5) oder aus der Datei “Snapshot 1” (Blöcke 1, 3, 6, 7 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in “Snapshot 1” noch nicht geänderten Block betrifft, wächst die Datei “Snapshot 1”. Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei “Snapshot 1” so groß wie die ursprüngliche Datei “Festplatte”. Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 13 Blöcke angewachsen.

Snapshot “Snapshot 2”

Nun wird ein weiterer Snapshot “Snapshot 2” angelegt. In diesem Moment wird auf die Dateien “Festplatte” und “Snapshot 1” nur noch lesend zugegriffen, alle Änderungen die Blöcke der Festplatte betreffend werden in der Datei “Snapshot 2” gespeichert.

Nach einiger Zeit der Nutzung ergibt sich folgendes Bild:

Für jeden Lesezugriff muß die virtuelle Maschine nun schauen, ob sie einen angefragten Block aus der Datei “Festplatte” (Block 2), der Datei “Snapshot 1” (Block 7) oder der Datei “Snapshot 2” (Blöcke 1, 3, 4, 5, 6 und 8) nehmen muß.

Mit jedem Schreibzugang, der einen in “Snapshot 2” noch nicht geänderten Block betrifft, wächst die Datei “Snapshot 2”. Im Extremfall, wenn jeder Block der Festplattte geändert wurde, wird die Datei “Snapshot 2” so groß wie die ursprüngliche Datei “Festplatte”. Im Beispiel ist der benötigte Platz von ursprünglich 8 Blöcken auf 19 Blöcke angewachsen, d.h. es wird bereits mehr als der doppelte Platz der Maximalgröße von “Festplatte” verwendet.

Problematik

Wenn sich ein Block oft ändert, wird für diesen nun auch dreifach Speicherplatz belegt: in der Datei “Festplatte”, in der Datei “Snapshot 1” und in der Datei “Snapshot 2”.

Bei Lesevorgängen muß immer geschaut werden, in welcher der drei Dateien die aktuelle Version des Blocks zum Zurückliefern vorhanden ist.

Löschen von “Snapshot 1”

Wenn man nun sicher ist, daß alles, was zu dem Zeitpunkt, als “Snapshot 2” erstellt wurde funktioniert, kehrt man i.d.R. nie wieder zu “Snapshot 1” zurück.

Als Konsequenz daraus löscht man in der Verwaltungsoberfläche der Virtualisierungssoftware “Snapshot 1”. Die Virtualisierungssoftware überträgt alle Blöcke aus “Snapshot 1” zurück an die entsprechenden Stellen von “Festplatte” (Blöcke 1, 3, 6, 7 und 8) und löscht anschließend die Datei “Snapshot 1”.

Als Ergebnis ergibt sich folgendes Bild:

Die Leistung wird besser, weil bei Lesezugriffen nur noch geschaut werden muss, ob ein Block aus “Festplatte” (Blöcke 2 und 7) oder “Snapshot 2” (Blöcke 1, 3, 4, 5, 6 und 8) gelesen werden muß und der Speicherplatz, den die Datei “Snapshot 1” bisher benötigt hat, ist wieder verfügbar. Im Beispiel ist der benötigte Platz von 19 Blöcken auf 14 Blöcke geschrumpft.