Restore testen: So prüfst du, ob dein Backup wirklich funktioniert

Über Backups wird viel geschrieben. Über Restores fast nichts. Das ist bemerkenswert, denn niemand braucht ein Backup – gebraucht wird immer nur die Wiederherstellung.

Der Satz, auf den es ankommt: Ein Backup, das nie zurückgespielt wurde, ist kein Backup, sondern eine Annahme. Er steht als „0“ in der Erweiterung der 3-2-1-Regel und ist der am häufigsten übersprungene Teil jeder Datensicherungsstrategie.

Dieser Artikel beschreibt ein Verfahren, das sich wiederholen lässt und am Ende einen Nachweis liefert – nicht ein gutes Gefühl.

Warum ein grüner Backup-Job nichts beweist

Ein erfolgreicher Backup-Lauf sagt aus: Daten wurden gelesen und weggeschrieben. Er sagt nichts darüber, ob

• die richtigen Daten erfasst wurden – eine Exclude-Regel, die zu viel ausschließt, fällt im Log nicht auf;
• die Daten konsistent sind – eine Datenbank mitten in einer Transaktion wird fehlerfrei gesichert und ist trotzdem unbrauchbar;
• das Zielsystem lesbar ist – Beschädigungen fallen erst beim Zugriff auf;
• der Schlüssel verfügbar ist – siehe Backup-Verschlüsselung;
• irgendjemand das Verfahren kennt – im Ernstfall bist du eventuell nicht verfügbar.

Die Verifikationsfunktionen der Backup-Werkzeuge decken davon genau einen Punkt ab: die Lesbarkeit der gespeicherten Daten. Das ist wertvoll und sollte automatisch laufen. Es ersetzt aber keinen Restore.

Die vier Teststufen

Nicht jeder Test muss alles abdecken. Sinnvoll ist eine Staffelung – von schnell und häufig bis aufwendig und selten.

Stufe	Was wird getestet	Aufwand	Rhythmus
1 – Datei	einzelne Datei zurückholen	Minuten	monatlich
2 – Anwendung	Dienst läuft mit zurückgespielten Daten	~1 Stunde	quartalsweise
3 – System	vollständige VM startet und funktioniert	halber Tag	halbjährlich
4 – Standort	Wiederaufbau allein aus der Offsite-Kopie	Tag	jährlich

Die Stufen bauen aufeinander auf, prüfen aber unterschiedliche Fehlerklassen. Stufe 1 findet Probleme im Sicherungsumfang, Stufe 4 findet Probleme in der Organisation – etwa dass die Zugangsdaten zum Offsite-Ziel nur in einem Passwortmanager stehen, der auf dem ausgefallenen Server läuft.

Wenn du nur eine Stufe schaffst, nimm Stufe 3. Sie deckt die meisten realen Fehlerursachen ab.

Stufe 1: Einzelne Datei

Der schnellste Test, der trotzdem etwas beweist.

Vorgehen:

1. Eine Datei auswählen, die sich regelmäßig ändert – nicht /etc/hostname, sondern etwas aus den Nutzdaten.
2. Aus einem Sicherungsstand von vor mindestens einer Woche zurückholen, nicht aus dem von heute Nacht.
3. In ein temporäres Verzeichnis wiederherstellen, niemals über das Original.
4. Prüfsumme oder Inhalt gegen die Erwartung vergleichen.

# restic: in ein separates Verzeichnis zurückholen
restic restore <snapshot-id> --target /tmp/restoretest --include /pfad/zur/datei
sha256sum /tmp/restoretest/pfad/zur/datei

Bei PBS führt der Weg über File Restore in der Oberfläche – ein Sicherungsstand wird durchsucht, ohne die VM zurückzuspielen.

Was dabei typischerweise auffällt: Verzeichnisse, die niemand ins Backup aufgenommen hat. Der Test beantwortet nämlich nebenbei die Frage „ist das überhaupt drin?“.

Stufe 2: Anwendung

Hier wird es interessant, weil Konsistenzprobleme sichtbar werden.

Vorgehen:

1. Daten eines Dienstes – Datenbank, Dokumentenablage, Groupware – in eine Testumgebung zurückspielen.
2. Den Dienst dort starten.
3. Fachlich prüfen: Lassen sich Daten lesen? Sind die letzten Änderungen vorhanden? Melden die Logs Konsistenzfehler?

Der klassische Fund auf dieser Stufe: Eine Datenbank wurde als Teil eines VM-Snapshots gesichert, ohne dass ein Dump existiert. Sie startet nach dem Restore und meldet beschädigte Tabellen. Wenn das im Test auffällt statt im Ernstfall, hat sich der Aufwand bereits gelohnt.

Stufe 3: Vollständiges System

Der Test mit dem besten Verhältnis von Aufwand zu Erkenntnis.

Vorgehen bei Proxmox:

1. In PVE einen Sicherungsstand auswählen, Restore, als Ziel eine neue VM-ID.
2. Die wiederhergestellte VM in ein isoliertes Netz hängen – oder ohne Netzwerk starten. Eine zweite Maschine mit derselben IP-Adresse im Produktivnetz erzeugt Probleme, die schlimmer sind als das, was du testen wolltest.
3. Starten, anmelden, Dienste prüfen.
4. Zeit messen.
5. VM danach löschen.

Punkt 2 ist der, der beim ersten Mal schiefgeht. Plane das Testnetz, bevor du auf Restore klickst.

Punkt 4 ist der eigentliche Ertrag: Du bekommst dein reales RTO. Nicht das geschätzte – das gemessene. Erst damit lässt sich beurteilen, ob die Zusagen realistisch sind, die du dir oder einem Kunden gegeben hast.

Stufe 4: Der Standort ist weg

Der unbequemste Test, weil er die Organisation prüft und nicht die Technik.

Die Annahme: Der Standort existiert nicht mehr. Kein Server, kein NAS, kein PBS. Du hast nur, was außerhalb liegt.

Die Fragen, die dann zählen:

• Wie erreichst du das Offsite-Ziel? Wo stehen die Zugangsdaten – und liegen sie vielleicht auf dem Server, den es nicht mehr gibt?
• Wo ist der Verschlüsselungsschlüssel?
• Auf welcher Hardware spielst du zurück? Wie lange dauert deren Beschaffung?
• Weißt du noch, wie die Systeme konfiguriert waren? Ist die Dokumentation im Backup – und kommst du an sie heran, ohne vorher alles wiederherzustellen?
• Wenn du selbst nicht verfügbar bist: Kann es jemand anderes?

Der Test lässt sich abgekürzt durchführen: Miete für einen Tag einen kleinen Server bei einem Anbieter, spiele ausschließlich aus der Offsite-Kopie ein System zurück und dokumentiere jeden Schritt. Die Kosten sind gering, der Erkenntnisgewinn ist der höchste aller vier Stufen.

Am häufigsten scheitert dieser Test nicht an den Daten, sondern an einem Passwortmanager, der auf dem ausgefallenen System lief.

Was dokumentiert werden muss

Ein Test ohne Protokoll ist ein Zeitvertreib. Aufzuschreiben sind:

Datum:                2026-__-__
Getestete Stufe:      1 / 2 / 3 / 4
Quelle:               lokal / offsite
Sicherungsstand vom:  ____
Wiederhergestelltes Objekt: ____
Dauer bis nutzbar:    ____
Ergebnis:             erfolgreich / mit Einschraenkungen / fehlgeschlagen
Aufgefallene Probleme: ____
Abgeleitete Massnahmen: ____
Durchgefuehrt von:    ____

Für Betriebe ist dieses Protokoll zusätzlich der Nachweis gegenüber Versicherungen und Prüfern. Für Privatpersonen ist es die Erinnerung daran, was beim letzten Mal schiefging – denn genau das vergisst man.

Was regelmäßig auffällt

Aus der Erfahrung mit solchen Tests wiederholen sich einige Funde:

Der Sicherungsumfang stimmt nicht. Ein Verzeichnis wurde nie erfasst, weil es nach dem Einrichten des Jobs dazukam. Besonders häufig bei Docker-Volumes und Anwendungsdaten außerhalb der Standardpfade.

Die Reihenfolge ist unklar. Zehn VMs sind wiederherstellbar – aber welche zuerst? Ohne Domänencontroller oder Datenbankserver starten die anderen ins Leere. Diese Reihenfolge gehört dokumentiert, bevor man sie braucht.

Der Restore ist langsamer als gedacht. Deutlich langsamer. Die Sicherung ist auf Durchsatz optimiert, die Wiederherstellung selten.

Der Schlüssel ist ein Problem. Entweder unauffindbar oder ausschließlich auf dem System vorhanden, das ausgefallen ist.

Niemand außer einer Person kann es. Ein reales Risiko, das keine Technik löst.

Wie oft testen?

Stufe	Rhythmus	Auslöser für Zusatztest
1 – Datei	monatlich	nach Änderung der Sicherungsregeln
2 – Anwendung	quartalsweise	nach Versionswechsel einer Anwendung
3 – System	halbjährlich	nach Änderungen an Hypervisor oder Backup-System
4 – Standort	jährlich	nach Anbieterwechsel beim Offsite-Ziel

Zusätzlich gilt: Nach jeder Änderung am Backup-Setup mindestens Stufe 1. Der häufigste Grund für ein kaputtes Backup ist eine gut gemeinte Änderung, die niemand nachgeprüft hat.

Checkliste

• Termine für die Tests stehen im Kalender – nicht im Kopf
• Ein isoliertes Testnetz existiert
• Restore erfolgt immer in ein neues Ziel, nie über das Original
• Getestet wird aus einem älteren Stand, nicht aus dem letzten
• Die Dauer wird gemessen und mit dem RTO verglichen
• Mindestens ein Test pro Jahr läuft ausschließlich aus der Offsite-Kopie
• Das Protokoll wird geführt und aufbewahrt
• Die Reihenfolge der Wiederherstellung ist dokumentiert
• Eine zweite Person hat den Ablauf mindestens einmal selbst durchgeführt
• Zugangsdaten und Schlüssel liegen außerhalb der gesicherten Systeme

Weiter im Cluster

• 3-2-1-Backup-Strategie – warum die „0“ dazugehört
• Proxmox Backup Server einrichten – Restore-Funktionen in PBS
• Offsite-Backup – Grundlage für Stufe 4
• Backup-Verschlüsselung – der häufigste Restore-Blocker
• Backup-Monitoring – damit Fehlschläge auffallen
• Typische Backup-Fehler