Ein Snapshot ist noch kein Restore-Plan

Snapshots erfassen Speicherzustand, nicht Recovery-Sicherheit

Kubernetes VolumeSnapshots bieten eine Möglichkeit, über CSI einen Snapshot eines Persistent Volumes anzufordern. Das ist hilfreich, bedeutet aber nicht automatisch, dass eine Anwendung wiederhergestellt werden kann. Ein Snapshot hält einen speicherseitigen Zeitpunkt fest; ein Restore-Plan muss zusätzlich Anwendungskonsistenz, Kubernetes-Objekte, Secrets, Berechtigungen, Reihenfolge und Zielumgebung berücksichtigen.

Bei zustandsbehafteten Systemen lautet die praktische Frage nicht „Haben wir einen Snapshot?“, sondern „Können wir den Dienst auf einen bekannten Stand zurückbringen, die Nutzbarkeit der Daten belegen und erklären, was verloren ging?“

Recovery-Bausteine trennen

Ein brauchbarer Restore-Plan unterscheidet mindestens vier Bausteine:

1. Persistente Daten, zum Beispiel PVC-Snapshots oder Dateisystem-Backups.
2. Kubernetes-API-Objekte wie Deployments, StatefulSets, Services, ConfigMaps und RBAC.
3. Anwendungsspezifische Konsistenzschritte, etwa Buffer flushen oder Schreibzugriffe pausieren.
4. Externe Abhängigkeiten wie DNS, Object Storage, Identitäten und Zugangsdaten.

Die Velero-Dokumentation beschreibt Backups als Kubernetes Custom Resources und erklärt, dass Backups kopierte Kubernetes-Objekte sowie Persistent-Volume-Snapshots enthalten können. Sie weist auch darauf hin, dass Backups nicht strikt atomar sind, wenn Objekte während des Backups geändert werden. Genau deshalb sind Restore-Tests wichtig.

Einen Restore-Drill definieren

Ein Restore-Drill sollte klein genug sein, um ihn zu wiederholen, und realistisch genug, um falsche Annahmen zu finden. Ein praktischer Drill kann so aussehen:

1. Ein Backup für einen unkritischen Namespace erzeugen oder auswählen.
2. In einen isolierten Namespace oder Testcluster wiederherstellen.
3. Prüfen, ob Kubernetes-Objekte mit erwarteten Namen, Labels und Rechten angelegt wurden.
4. Wiederhergestellte Volumes mounten und Anwendungstests ausführen.
5. Den Dienst über einen Client-Pfad prüfen, nicht nur über Pod-Status.
6. Restore-Zeit, fehlende Objekte, manuelle Schritte und Datenverlustfenster dokumentieren.

Das Ergebnis sollte ein verbessertes Runbook sein, nicht nur ein grüner Haken. Wenn der Drill undokumentierte Rechte, manuelles Kopieren von Secrets oder eine Storage-Class-Anpassung brauchte, war der Recovery-Plan unvollständig.

Zielcluster-Kompatibilität beachten

Ein Restore in einen anderen Cluster ist strenger als ein Restore in denselben Cluster. API-Versionen, Storage Classes, CSI-Treiber, Namespace-Policies und Zugangsdaten müssen im Ziel existieren. Velero dokumentiert, dass wiederhergestellte API-Ressourcen kompatible API-Group-Versionen im Zielcluster benötigen. Kubernetes VolumeSnapshots hängen außerdem von Snapshot-Unterstützung durch den CSI-Treiber und passenden Snapshot Classes ab.

Bei wichtigen Diensten sollte die Restore-Checkliste nahe an der Anwendung liegen. Die Person im Recovery-Fall sollte nicht während eines Ausfalls rekonstruieren müssen, welches PVC zu welchem Workload gehört.

Quellen

• Kubernetes Volume Snapshots zum CSI-Snapshot-Modell und den Snapshot-Ressourcen.
• Velero: How Velero Works zu Kubernetes-Objekt-Backups, Persistent-Volume-Snapshots, Restore-Workflow und nicht-atomaren Backups.

Technische Quellen am 22. September 2026 geprüft. Dieser Beitrag ist allgemeine Recovery-Praxis, kein arbeitgeberspezifisches Disaster-Recovery-Verfahren.