Ein Snapshot friert den Zustand einer virtuellen Maschine ein: Alle folgenden Änderungen werden separat festgehalten, sodass jederzeit auf den gesicherten Stand zurückgesprungen werden kann. Vor einem Update oder einer riskanten Konfigurationsänderung ist das eine ausgezeichnete Absicherung – für ein paar Stunden. Über Wochen hinweg wird aus derselben Funktion ein Risiko für Leistung, Speicherplatz und Verfügbarkeit.
Wie ein Snapshot technisch funktioniert
Beim Anlegen eines Snapshots wird die bisherige virtuelle Festplatte eingefroren und nur noch gelesen. Alle neuen Schreibvorgänge landen in einer separaten Differenzdatei. Liest die Maschine einen Datenblock, prüft der Hypervisor zuerst die Differenzdatei und greift erst dann auf die Originalplatte zurück. Jeder weitere Snapshot erzeugt eine weitere Differenzdatei – es entsteht eine Kette. Wird zusätzlich der Arbeitsspeicher festgehalten, kehrt die Maschine beim Zurücksetzen in den laufenden Zustand zurück; der Snapshot belegt dann entsprechend mehr Platz.
Wird der Snapshot aufgelöst, müssen die gesammelten Änderungen in die Originalplatte zurückgeschrieben werden. Dieses Zusammenführen ist der eigentliche Aufwand: Es kostet Zeit und Schreibleistung, und zwar umso mehr, je länger der Snapshot bestand. Wird dagegen auf den Snapshot zurückgesetzt, verwirft der Hypervisor die Differenzdatei, und alle Änderungen seit dem Anlegen sind verloren.
Was die Hersteller empfehlen
VMware rät in seinen Empfehlungen zum Umgang mit Snapshots, einen einzelnen Snapshot nicht länger als 24 bis 72 Stunden zu verwenden, und warnt ausdrücklich davor, Snapshots zur Versionsverwaltung einzusetzen. Besondere Sorgfalt verlangen nach denselben Hinweisen Systeme mit vielen Schreibvorgängen wie Mail- und Datenbankserver, deren Differenzdateien sehr schnell wachsen und den Datenspeicher füllen können.
Microsoft unterscheidet bei Hyper-V zwischen Standard- und Produktionsprüfpunkten. Standardprüfpunkte halten auch den Arbeitsspeicherzustand fest und sind laut Microsoft für Entwicklung und Test gedacht. Produktionsprüfpunkte nutzen innerhalb der virtuellen Maschine den Volumeschattenkopie-Dienst beziehungsweise unter Linux das Einfrieren des Dateisystems, sodass die Daten konsistent auf dem Datenträger liegen; sie sind für produktive Systeme vorgesehen und bei neuen Maschinen voreingestellt. Vor Eingriffen an Servern mit Datenbanken ist das die richtige Wahl.
Warum alte Snapshots schaden
- Speicherplatz: Die Differenzdatei wächst mit jeder Änderung. Läuft der Datenspeicher voll, hält der Hypervisor die betroffenen Maschinen an – häufig mehrere zugleich, weil sie sich denselben Speicher teilen.
- Leistung: Lesezugriffe müssen die Kette durchlaufen, Schreibzugriffe landen in wachsenden Dateien. Lange Ketten bremsen spürbar.
- Auflösung: Das Zusammenführen großer Differenzdateien dauert lange und belastet das Speichersystem; zum Abschluss kann die Maschine kurz einfrieren.
- Scheinbare Sicherheit: Snapshots liegen auf demselben Speichersystem wie das Original. Fällt dieses aus oder wird die Originalplatte beschädigt, sind beide verloren. Ein Snapshot ist kein Backup.
- Verwaiste Snapshots: Sicherungsprogramme legen für die Dauer ihres Laufs selbst Snapshots an. Bricht ein Lauf ab, bleiben diese mitunter unbemerkt bestehen.
Eine typische Situation im Mittelstand: Vor dem Update der Warenwirtschaft wird am Freitagabend ein Snapshot angelegt. Das Update gelingt, am Montag beginnt die Arbeit, der Snapshot bleibt stehen. Wochen später meldet das Monitoring einen fast vollen Datenspeicher, und die Auflösung der inzwischen sehr großen Differenzdatei muss in ein eigenes Wartungsfenster gelegt werden. Fachlich war nichts falsch – es war nur niemand für das Ende zuständig.
Vorsicht beim Zurückspringen
Das Zurücksetzen auf einen Snapshot wirkt wie eine Zeitreise – allerdings nur für die eine Maschine. Alles, was sie seitdem mit der Außenwelt ausgetauscht hat, bleibt bestehen: versendete Mails, an Partner übertragene Bestellungen, angestoßene Zahlungen. Eine Warenwirtschaft, die auf den Stand von gestern Mittag zurückgesetzt wird, kennt die Aufträge des Nachmittags nicht mehr, der Kunde aber schon.
Heikel sind außerdem Systeme, die ihren Zustand mit anderen abgleichen: Domänencontroller, replizierte Datenbanken, Cluster. Neuere Windows-Server-Versionen erkennen das Zurücksetzen eines virtualisierten Domänencontrollers und schützen die Replikation. Verlassen sollte man sich darauf nicht, sondern bei solchen Systemen vorab klären, ob ein Snapshot überhaupt der passende Rückweg ist oder ob die Wiederherstellung aus der Sicherung sauberer wäre.
Zur Abgrenzung: Speichersysteme, die Snapshots auf Ebene des Dateisystems oder des Speichergeräts anlegen, arbeiten technisch anders und sind teils für längere Aufbewahrung ausgelegt. Auch diese Snapshots liegen jedoch auf demselben Gerät wie die Originaldaten und ersetzen keine Sicherung an einem getrennten Ort.
Betriebsregeln, die sich bewähren
- Jeden Snapshot mit Zweck, Datum und verantwortlicher Person benennen, damit klar ist, warum er existiert.
- Schon beim Anlegen festlegen, wann er aufgelöst wird – spätestens nach 24 bis 72 Stunden – oder ihn bewusst durch eine Sicherung ersetzen.
- Vorher den freien Platz auf dem Datenspeicher prüfen, bei schreibintensiven Systemen mit großzügiger Reserve.
- Vor größeren Eingriffen zusätzlich prüfen, ob die letzte reguläre Sicherung erfolgreich war – der Snapshot ergänzt sie, er ersetzt sie nicht.
- Bei Arbeiten durch Dienstleister im Auftrag festhalten, dass angelegte Snapshots nach Abschluss aufgelöst werden und die Auflösung bestätigt wird.
- Für dauerhafte Test- oder Versionsstände Klone oder Sicherungen verwenden, keine Snapshots.
- Das Monitoring meldet Snapshots, die älter als die vereinbarte Frist sind; in gewachsenen Umgebungen finden sich fast immer vergessene.
Unsere Einordnung: Ein Snapshot ist ein Werkzeug für den Eingriff, nicht für die Aufbewahrung. Wer ihn mit Ablaufdatum anlegt und die Einhaltung automatisch prüfen lässt, nutzt den Vorteil, ohne sich das Risiko einzuhandeln.
Verwandte Themen: Wer hier weiterdenkt, liest bei Virtualisierung, VMware Alternativen und Speicherplanung weiter.
Quellen
- SYS.1.5 Virtualisierung · BSIamtlich
- Best practices for using VMware snapshots in the vSphere environment · VMware (Broadcom)
