Restore-Test in Kubernetes: Ablauf und Protokollvorlage

TL;DR - Eine erfolgreiche Backup-Meldung belegt einen funktionierenden Schreibvorgang, keine Wiederherstellbarkeit. Der Test läuft in neun Schritten von der Zeitmessung bis zum unterschriebenen Protokoll. Acht Befunde tauchen dabei fast immer auf, vom leeren Volume bis zur eigenen Admission-Regel, die den Restore blockiert. Die Protokollvorlage am Ende ist zum Kopieren gedacht.

Die meisten Cluster, die wir übernehmen, haben ein funktionierendes Backup. Velero läuft nachts durch, die Aufträge stehen auf Completed, das Dashboard ist grün.

Fragt man dann, wann zuletzt aus einem dieser Backups wiederhergestellt wurde, wird es still.

Das ist keine Nachlässigkeit, sondern eine Frage der Reihenfolge. Ein Backup einzurichten dauert einen Nachmittag. Eine Wiederherstellung durchzuspielen kostet einen Tag, blockiert eine Umgebung und produziert unangenehme Erkenntnisse. Also verschiebt man es, und zwar so lange, bis der Ernstfall die Prüfung übernimmt.

In diesem Artikel steht der Ablauf, den wir dafür verwenden: was vorher stehen muss, welche neun Schritte durchlaufen werden, welche fünf Werte gemessen werden und was am Ende im Protokoll steht. Die Vorlage am Ende ist zum Kopieren gedacht.

Was eine grüne Backup-Meldung tatsächlich belegt

Belegt ist damit ein funktionierender Schreibvorgang: Objekte wurden aus der API gelesen und ohne Fehler in ein Ziel geschrieben.

Offen bleiben dagegen fünf Fragen:

• Sind die Daten in den Persistent Volumes mitgesichert?
• Lässt sich das Gesicherte im Zielcluster überhaupt anlegen?
• Arbeitet die Anwendung danach fachlich, oder meldet sie nur Running?
• Wie lange dauert das Ganze?
• Welchen Datenstand haben Sie hinterher?

Auf alle fünf antwortet nur ein Verfahren: der Restore-Test. Und zwar in Stunden statt in Meinungen.

Erst den Umfang entscheiden

Der häufigste Fehler beim ersten Test ist, gleich den Totalausfall zu proben. Das Ergebnis ist ein abgebrochener Versuch nach vier Stunden und die Erkenntnis, dass es „irgendwie nicht ging“. Nehmen Sie eine der vier Stufen, und nehmen Sie beim ersten Mal Stufe 1 oder 2.

Stufe 1, ein einzelner Workload. Eine Anwendung samt PVC in einen frischen Namespace zurückholen. Zwei Stunden Aufwand, findet erfahrungsgemäß trotzdem bereits die Hälfte der typischen Befunde.

Stufe 2, ein vollständiger Namespace. Inklusive Secrets, ConfigMaps, Ingress und aller Abhängigkeiten. Diese Stufe kommt dem realen Anwendungsausfall am nächsten.

Stufe 3, Cluster-Neuaufbau aus Git. Ein leerer Cluster wird ausschließlich aus dem Repository aufgebaut, anschließend werden die Daten eingespielt. Hier zeigt sich, ob Ihre Plattform wirklich deklarativ beschrieben ist oder ob jemand einmal etwas von Hand nachgezogen hat.

Stufe 4, Ausfall der gesamten Region oder des Kontos. Wiederherstellung an einem anderen Ort, mit anderen Zugangsdaten, ohne Zugriff auf die Quelle. Bei Ransomware zählt genau diese Stufe, und sie ist mit Abstand die teuerste Übung.

Notieren Sie die gewählte Stufe im Protokoll. Ein Restore-Protokoll ohne Umfangsangabe ist wertlos, weil niemand später weiß, was eigentlich bewiesen wurde.

Voraussetzungen, die vor dem ersten Test stehen müssen

Fehlt einer dieser fünf Punkte, testen Sie nicht Ihre Wiederherstellung, sondern nur Ihr Glück.

1. Das Backup-Ziel ist getrennt: anderes Konto, andere Region, eigene Zugangsdaten. Ein Ziel, das mit denselben Rechten löschbar ist wie die Produktion, ist bei einem Angriff kein Backup, sondern ein weiteres Opfer.
2. Unveränderliche Aufbewahrung ist aktiv, also Object Lock oder das Äquivalent Ihres Anbieters, mit einer Aufbewahrungsdauer, die länger ist als Ihre Entdeckungszeit für einen Vorfall.
3. etcd wird getrennt gesichert. Das Anwendungs-Backup ersetzt die Cluster-Sicherung nicht.
4. RTO und RPO sind je Anwendung festgelegt und stehen als Label am Workload. Das RTO ist die Zeit, die eine Anwendung ausfallen darf, das RPO der Datenverlust, den der Fachbereich hinnimmt. Für ein Kassensystem sind das vielleicht eine Stunde und fünfzehn Minuten, für ein internes Wiki drei Tage und ein Tag. Festgelegt werden beide Werte vom Fachbereich, nicht von der Plattform.
5. Eine Zielumgebung existiert, also ein Sandbox-Cluster oder mindestens ein separater Namespace mit eigener StorageClass. In die Produktion zurückzuspielen ist kein Test, sondern ein zweiter Vorfall.

# Unveränderliche Aufbewahrung am S3-kompatiblen Ziel prüfen
aws s3api get-object-lock-configuration --bucket cheveo-backups

metadata:
  labels:
    cheveo.de/rto: "4h"
    cheveo.de/rpo: "1h"
    cheveo.de/criticality: "high"

Warum am Objekt und nicht in einer Tabelle im Wiki: Der Unterschied ist praktisch, nicht dogmatisch.

Beim Test steht die Zielvorgabe in derselben Ausgabe wie das, was Sie gerade wiederhergestellt haben. Sie vergleichen gemessene Dauer und Ziel, ohne nebenher eine Datei zu suchen, deren Stand niemand kennt.

Widersprüche werden maschinell auffindbar. Ein Workload mit rpo: 1h, der nur im nächtlichen Backup-Auftrag steckt, kann sein Ziel nicht erreichen. Das ist eine Abfrage über Labels und Sicherungszeitpläne, und sie findet den Fehler, bevor der Restore-Test ihn findet.

Die Vorgabe wandert mit dem Manifest durch Git. Wer sie wann geändert hat, steht in der Historie. Auf die Prüferfrage, wo die Zielwerte herkommen und wer sie festgelegt hat, gibt es damit eine Antwort statt einer Datei ohne Verfasser.

Ein Label erzwingt allerdings nichts. Es wirkt erst, wenn etwas es liest: der Bericht, der Zielwerte und gemessene Werte gegenüberstellt, oder die Prüfung, die Sicherungsrhythmus und RPO vergleicht. Wer die Labels setzt und sonst nichts ändert, hat die Tabelle nur an einen anderen Ort verschoben.

Der Ablauf in neun Schritten

Weil Velero der verbreitetste Weg ist, beziehen sich die Befehle darauf. Mit einem anderen Werkzeug ändern sich die Kommandos, nicht die Schritte.

1. Ausgangslage festhalten und die Uhr starten.

Notieren Sie Datum, Uhrzeit, Beteiligte und das verwendete Backup, denn ab hier läuft die Zeitmessung. Gemessen wird die tatsächliche Wiederherstellungsdauer, deshalb zählt jede Minute Suchen im Wiki mit.

velero backup get
velero backup describe nightly-20260825 --details

2. Prüfen, was das Backup überhaupt enthält.

An dieser Stelle erzeugen die meisten Tests bereits ihren ersten Befund.

velero backup describe nightly-20260825 --details | grep -A20 "Resource List"
velero backup logs nightly-20260825 | grep -i "warning\|error\|skipped"

Achten Sie auf übersprungene Ressourcen. Was hier fehlt, fehlt später auch.

3. In eine getrennte Zielumgebung zurückspielen.

velero restore create restore-test-20260826 \
  --from-backup nightly-20260825 \
  --namespace-mappings produktion:restore-test \
  --wait

4. Den Verlauf beobachten, nicht das Endergebnis abwarten.

velero restore describe restore-test-20260826 --details
velero restore logs restore-test-20260826 | grep -i "error\|could not"
kubectl get pods -n restore-test -w

5. Die Daten prüfen, nicht die Pods.

Running heißt, dass ein Prozess gestartet ist. Über den Inhalt der Volumes sagt der Status nichts.

kubectl get pvc -n restore-test
kubectl exec -n restore-test deploy/app -- ls -la /var/lib/data

Bei Datenbanken gehört hierher eine echte Abfrage: Zeilenzahl der wichtigsten Tabelle, jüngster Zeitstempel, ein bekannter Datensatz.

6. Fachlich prüfen.

Ein realer Aufruf, kein Health-Check. Ein Login, eine Bestellung, ein Report. Der Health-Check ist genau der Teil, der auch dann grün leuchtet, wenn die Datenbank leer wiederhergestellt wurde.

7. Die Uhr stoppen und den Datenstand bestimmen.

Die gemessene Dauer ist Ihr tatsächliches RTO. Der Abstand zwischen dem jüngsten wiederhergestellten Datensatz und dem simulierten Ausfallzeitpunkt ist Ihr tatsächliches RPO. Beide Werte gehören neben die Zielwerte aus den Labels.

8. Abweichungen aufschreiben, während sie noch weh tun.

Jeder manuelle Eingriff, jedes fehlende Secret, jeder Handgriff, der nicht im Runbook stand. In dieser Liste steckt der eigentliche Ertrag des Tests. Wer sie erst am nächsten Tag aus dem Gedächtnis schreibt, verliert die Hälfte.

9. Aufräumen und das Protokoll abschließen.

kubectl delete namespace restore-test
velero restore delete restore-test-20260826

Acht Befunde, die fast immer auftauchen

Aus unseren Tests, grob nach Häufigkeit sortiert.

1. Das Backup enthält die Objekte, aber nicht die Volumes. Die Snapshot-Konfiguration fehlt oder der CSI-Treiber unterstützt sie nicht. Alles wird angelegt, alles ist leer.
2. Secrets fehlen. Sie liegen im External Secrets Operator und werden aus Vault oder KMS nachgeladen. Im Zielcluster fehlt die Anbindung, der Pod bleibt in CreateContainerConfigError. Ein sauberes Muster also, das im Ernstfall trotzdem blockiert, solange der Wiederherstellungsweg für das Secret-Backend nicht mitgedacht ist.
3. Die StorageClass existiert im Ziel nicht. PVCs bleiben Pending, der Rest wartet. Das passiert immer dann, wenn die Zielumgebung bei einem anderen Anbieter liegt.
4. CRDs oder Operatoren fehlen. Die wiederhergestellten Objekte sind da, aber niemand verarbeitet sie. Die Reihenfolge entscheidet: erst die Definitionen, dann die Instanzen.
5. Die eigenen Admission-Regeln blockieren den Restore. Die Policy verlangt Ownership-Labels oder signierte Images, die wiederhergestellten Objekte bringen beides nicht mit. Für Ihre Absicherung spricht das, für Ihr RTO nicht. In die Policy gehört dann eine dokumentierte Ausnahme für den Wiederherstellungsfall, nicht das Abschalten der Regel.
6. Die Anwendung läuft und ist trotzdem nicht erreichbar. LoadBalancer-Adressen, DNS-Einträge und Zertifikate sind kein Teil des Cluster-Backups. Wer die Wiederherstellung beim Pod-Status beendet, merkt das erst im Ernstfall.
7. Die Datenbank ist inkonsistent. Der Volume-Snapshot lief ohne Quiesce, mitten in einer Transaktion. Restore-Hooks, die vor dem Snapshot einen Dump ziehen oder die Schreiblast anhalten, lösen das.
8. Das benötigte Backup ist längst gelöscht. Die Aufbewahrungsdauer war kürzer als die Zeit bis zur Entdeckung des Problems. Bei einer stillen Datenverfälschung sind sieben Tage Aufbewahrung regelmäßig zu wenig.

Die fünf Werte, die ins Protokoll gehören

Wert	Wie er entsteht	Warum er zählt
Gemessenes RTO	Stoppuhr von Schritt 1 bis Schritt 6	Der Zielwert im Label ist eine Absicht, dieser Wert ist die Realität
Gemessenes RPO	Jüngster wiederhergestellter Datensatz gegen simulierten Ausfallzeitpunkt	Zeigt den tatsächlichen Datenverlust
Vollständigkeitsquote	Wiederhergestellte gegen erwartete Objekte aus restore describe	Deckt stillschweigend übersprungene Ressourcen auf
Manuelle Eingriffe	Gezählt, während sie passieren	Jeder Eingriff ist ein Schritt, der im Ernstfall unter Druck erneut nötig wird
Offene Abweichungen	Liste aus Schritt 8, mit Verantwortlichem und Frist	Ohne Frist wiederholt sich derselbe Befund im nächsten Jahr

Protokollvorlage

Kopieren, ausfüllen, unterschreiben lassen. Der letzte Punkt ist der, den Prüfer sehen wollen, und der, den intern niemand freiwillig übernimmt.

# Restore-Protokoll

Datum:                  2026-08-26
Durchgeführt von:       [Name, Rolle]
Anwesend:               [Namen]
Umfang (Stufe 1-4):     2, Namespace "produktion"
Verwendetes Backup:     nightly-20260825, erstellt 2026-08-25 02:14 UTC
Zielumgebung:           Sandbox-Cluster eu-central, Namespace "restore-test"
Simulierter Ausfall:    2026-08-26 09:00 Uhr

## Zeitmessung
Start:                  09:00
Anwendung fachlich ok:  12:47
Gemessenes RTO:         3 h 47 min   (Ziel laut Label: 4 h)   erfüllt
Gemessenes RPO:         6 h 46 min   (Ziel laut Label: 1 h)   NICHT erfüllt

## Vollständigkeit
Erwartete Objekte:      412
Wiederhergestellt:      408
Übersprungen:           4 (siehe Abweichung 2)
Manuelle Eingriffe:     3

## Fachliche Prüfung
Durchgeführter Test:    Login, Bestellung anlegen, Report des Vortags
Ergebnis:               erfolgreich, Report zeigt Stand 02:14 Uhr

## Abweichungen
1. RPO verfehlt: nächtlicher Rhythmus deckt 1 h Zielvorgabe nicht ab.
   Maßnahme: stündliche Sicherung für Namespace "produktion".
   Verantwortlich: [Name]   Frist: 2026-09-15
2. 4 ConfigMaps übersprungen (Label-Selektor im Backup-Auftrag zu eng).
   Maßnahme: Selektor korrigieren, nächsten Lauf gegenprüfen.
   Verantwortlich: [Name]   Frist: 2026-09-01
3. Zertifikat im Ziel manuell ausgestellt, da cert-manager fehlte.
   Maßnahme: cert-manager in Wiederherstellungsreihenfolge aufnehmen.
   Verantwortlich: [Name]   Frist: 2026-09-15

## Bewertung
Wiederherstellbarkeit für den geprüften Umfang: nachgewiesen, mit
Einschränkung beim Datenstand (siehe Abweichung 1).

Nächster Test geplant:  2027-02, Stufe 3
Unterschrift:           _______________________

Zwei Hinweise zur Vorlage. Ein verfehltes Ziel gehört hinein und nicht heraus, denn ein Protokoll, in dem alles erfüllt ist, wirkt bei jedem erfahrenen Prüfer verdächtig. Und die Frist an der Abweichung macht aus dem Dokument einen Vorgang statt einer Ablage.

Wie oft, und mit welcher Tiefe

Einmal jährlich Stufe 3 oder 4, halbjährlich Stufe 2 für die wichtigsten Anwendungen, und nach jeder größeren Änderung an Speicher, Backup-Ziel oder Cluster-Version ein kurzer Durchlauf auf Stufe 1. Wer die Wiederherstellung eines einzelnen Namespace automatisiert nachts mitlaufen lässt, ersetzt damit die manuellen Tests nicht, gewinnt aber ein Frühwarnsignal.

Der regulatorische Rahmen, kurz

Seit dem 6. Dezember 2025 gilt §30 BSIG. Absatz 2 Nummer 3 verlangt Maßnahmen zur Aufrechterhaltung des Betriebs, ausdrücklich einschließlich Backup-Management und Wiederherstellung. Nach Absatz 1 müssen diese Maßnahmen geeignet, verhältnismäßig und wirksam sein, und bei der Wirksamkeit reicht eine Backup-Erfolgsquote als Beleg nicht aus.

Dafür ist ein unterschriebenes Restore-Protokoll mit gemessener Dauer und benannten Abweichungen das naheliegende Artefakt. Es fällt bei einem sauber durchgeführten Test als Nebenprodukt an und beantwortet die Prüferfrage in einem Dokument statt in vier Terminen.

Nicht abgedeckt sind damit die Notfallorganisation, der Krisenstab, die Business-Impact-Analyse und die Meldepflichten nach §32. Das sind organisatorische Themen, die neben der Plattform liegen und dort auch hingehören. Dieser Artikel ist eine technische Anleitung und keine Rechtsberatung; welche Pflichten für Ihr Unternehmen konkret gelten, klären Sie mit Ihrem Informationssicherheitsbeauftragten oder einem Fachanwalt.

Der Punkt, auf den es hinausläuft

Unangenehm ist die Frage aus dem ersten Absatz deshalb, weil sie binär ist. Entweder es gibt ein Protokoll mit Datum, Dauer und Unterschrift, oder es gibt keines. Zwischenstufen existieren nicht, und genau deshalb eignet sich der Restore-Test als Abnahmekriterium: für einen internen Vorsatz, für ein Projekt und für die Arbeit eines Dienstleisters.

Wir setzen die technischen Maßnahmen nach §30 BSIG in Kubernetes-Umgebungen um und machen die Nachweise zum Nebenprodukt. Wenn Sie wissen wollen, wo Ihre Plattform dabei steht: Nachweislage prüfen lassen.