Ein Snapshot hält den Zustand einer virtuellen Maschine fest, indem Änderungen ab diesem Moment in eine Differenzdatei laufen. Das ist nützlich unmittelbar vor einem Update, einem Softwarestand oder einer riskanten Einstellung, solange der ursprüngliche Datastore gesund ist. Es ist kein Backup, weil nichts den Raum verlassen hat. Fällt das RAID aus, sind Grundplatte und Snapshot gemeinsam weg. Bleibt der Snapshot wochenlang liegen, wächst die Differenzdatei, die Maschine wird langsamer, und die spätere Zusammenführung dauert genau dann lange, wenn man keine Zeit hat.

Warum lange Snapshot-Ketten den Host bremsen

Backup-Programme stolpern über verwaiste Snapshot-Ketten oder brauchen deutlich länger, weil sie Differenzdateien mitlesen müssen. Manche Jobs schlagen fehl, sobald ein Snapshot offen ist, andere sichern einen Stand, den niemand so wollte. Auf einem fast vollen Datastore kann schon das Anlegen oder Löschen eines Snapshots die Maschinen anhalten, weil für die Zusammenführung kurz Platz gebraucht wird. Der freie Bereich ist deshalb Teil der Snapshot-Regel, nicht ein kosmetischer Wert in der Oberfläche.

Besonders heikel sind Domaincontroller und Datenbanken. Einen Controller auf einen Snapshot zurückzusetzen, während andere Controller weitergearbeitet haben, kann das Verzeichnis beschädigen, auch wenn moderne Windows-Versionen einen Restore erkennen. Eine Datenbank in einem Snapshot ist nur dann ein brauchbarer Rückweg, wenn die Anwendung diesen Zeitpunkt verträgt und niemand danach weitergebucht hat. Für beides ist ein ordnungsgemäßes Backup der bessere Rückweg; der Snapshot bleibt die kurze Absicherung des Wartungsfensters.

Stunden, nicht Wochen, und danach zusammenführen

  1. Zweck. Ein Snapshot hat einen Anlass, eine Maschine und ein Ende am selben oder nächsten Werktag. Ohne Anlass wird keiner angelegt.
  2. Platz. Vor dem Anlegen ist Freibereich auf dem Datastore da, der die Differenz und die spätere Zusammenführung trägt. Ist der Speicher knapp, gibt es kein Snapshot-Update.
  3. Ausnahme. Domaincontroller und Datenbanken bekommen nur dann einen Snapshot, wenn der Rückweg ausdrücklich nicht das Zurücksetzen in die Produktion ist. Sonst sichert der Backup-Job.
  4. Auflösen. Nach der fachlichen Prüfung wird zusammengeführt, und die Liste ist danach leer. Ein erfolgreiches Update ohne Löschung gilt als offen.
  5. Backup. Der eigentliche Rückweg bleibt eine Kopie auf anderem Speicher. Der Snapshot wird im Backup-Protokoll nicht als Job akzeptiert.

Wir erlauben Snapshots im Betrieb nur mit Ablaufzeit. Wer vor einem Update einen setzt, trägt Datum und Grund ein und löscht ihn nach der fachlichen Prüfung, nicht „irgendwann im Monat“. Automatische Snapshots einer Laborfunktion, die niemand löscht, behandeln wir wie eine Störung, sobald sie älter als das Wartungsfenster sind. Die echte Kopie bleibt der Backup-Job auf anderem Speicher.

Woran Projekte in der Praxis scheitern

  • Snapshots wochenlang liegen lassen, weil das Update „vielleicht noch zurückgedreht wird“.
  • Einen Domaincontroller aus einem alten Snapshot starten, während ein zweiter Controller weiterläuft.
  • Den Datastore so voll planen, dass die Zusammenführung keinen Platz mehr hat.
  • Einen Snapshot auf dieselbe Platte als Erfüllung der Backup-Absprache werten.

Beispiel aus dem Betriebsalltag

Bei einem Ingenieurbüro lag auf der VM der Projektablage seit einem Update im Frühjahr ein Snapshot, den der damalige Eingriff nicht entfernt hatte. Die Differenzdatei war auf einen großen Teil des Datastores angewachsen, die nächtliche Sicherung dauerte immer länger, und niemand verknüpfte das mit dem alten Snapshot. Wir haben die Zusammenführung an einem Vormittag mit freiem Platz und ohne zweite Last durchgeführt, danach einen Backup-Restore einer einzelnen Datei geprüft und eine Regel gesetzt: Snapshots nur mit Ticket und Löschung am selben oder nächsten Werktag. Ein zweiter, noch älterer Snapshot auf dem Domaincontroller wurde nicht zurückgespielt, sondern nach Prüfung entfernt, ohne den Controller auf den alten Stand zu stellen.

Kurze Entscheidungshilfe

  • Ist die Snapshot-Liste der Produktivmaschinen heute leer oder nur mit einem datierten Wartungsgrund gefüllt?
  • Gibt es Freibereich für eine Zusammenführung?
  • Wird kein Snapshot als Backup-Job an die Geschäftsführung gemeldet?
  • Ist klar, dass Controller nicht aus Snapshots in den Verbund zurückgesetzt werden?

Wenn Snapshots am Hypervisor bei Ihnen ansteht, klären wir den Umfang unverbindlich: Virtualisierung. VM-Backup und Anwendungsbackup Alternativ direkt Kontakt aufnehmen oder die häufigen Fragen lesen.