Backup-Wiederherstellung testen¶
Veröffentlicht am 20. September 2026 · Geschätzte Lesezeit: 9 Minuten
Ein Backup ist erst belastbar, wenn du ausgewählte Daten daraus wiederherstellen, öffnen und prüfen kannst. In dieser Anleitung testest du zuerst eine Datei, danach einen Ordner und schließlich den sicheren Ablauf für ein vollständiges Gerät, ohne produktive Daten zu überschreiben. Plane 10 bis 20 Minuten für den Datei-Test, 20 bis 45 Minuten für den Ordner-Test und 60 bis 180 Minuten für einen Geräte-Test auf Ersatzhardware oder in einer isolierten Testumgebung ein.
Voraussetzungen
- Ein vorhandenes, aktuell lesbares Backup mit dokumentiertem Zugang
- Genügend freier Speicher für ein neues, leeres Testverzeichnis
- Eine unkritische Referenzdatei und ein kleiner Referenzordner aus dem Backup
- Für die Befehlsbeispiele ein eingerichtetes restic-Repository und eine installierte restic-Version
- Für einen vollständigen Geräte-Test ausschließlich geeignete Ersatzhardware oder eine vom Hersteller unterstützte isolierte Testumgebung
1. Testumfang und Abbruchregeln festlegen¶
Beginne nicht mit dem Restore, sondern mit einem kurzen Prüfplan. CISA empfiehlt, Verfügbarkeit und Integrität von Backups regelmäßig in einem Wiederherstellungsszenario zu testen und dafür auch passende Ersatzhardware vorzuhalten.[3]
Testdatum: <YYYY-MM-DD>
Backup-System: <BACKUP-SYSTEM>
Sicherungsstand: <SNAPSHOT-ID-ODER-DATUM>
Testobjekt: <DATEI-ORDNER-ODER-GERAET>
Testziel: <LEERES-TESTZIEL>
Erwartetes Ergebnis: <DATEIEN-UND-FUNKTIONEN>
Maximale Dauer: <MINUTEN>
Abbruch bei: falschem Ziel, Schreibzugriff auf Produktivdaten, fehlendem Speicher oder Fehlermeldung
Ersetze <YYYY-MM-DD> durch das Testdatum, <BACKUP-SYSTEM> durch den Namen deiner Sicherungslösung, <SNAPSHOT-ID-ODER-DATUM> durch den eindeutig gewählten Stand, <DATEI-ORDNER-ODER-GERAET> durch den Testumfang, <LEERES-TESTZIEL> durch den getrennten Zielort, <DATEIEN-UND-FUNKTIONEN> durch deine Prüfkriterien und <MINUTEN> durch die akzeptierte Wiederherstellungszeit.
Produktivziel nicht als Testziel verwenden
Ein Restore in das ursprüngliche Verzeichnis kann vorhandene Dateien überschreiben. restic überschreibt im Ziel standardmäßig bereits vorhandene Dateien; ein unterbrochener In-place-Restore kann außerdem einen teilweise wiederhergestellten Zustand hinterlassen.[1] Verwende für diesen Test deshalb immer ein neues, leeres Ziel.
2. Sicherungsstand eindeutig auswählen¶
Lege das Repository für die aktuelle Shell fest. Ersetze <REPOSITORY> durch den lokalen Pfad oder die von restic unterstützte Repository-Adresse. Das Repository-Passwort gehört nicht in den Befehl, in die Shell-Historie oder in diese Anleitung.
Zeige anschließend die vorhandenen Snapshots:
Kontrolliere ID, Datum, Host und gesicherte Pfade. Die restic-Dokumentation zeigt diese Angaben in der Snapshot-Liste und erlaubt zusätzlich Filter nach Pfad oder Host.[2] Wähle für den Test bewusst eine konkrete ID und übernimm sie in eine Shell-Variable:
<SNAPSHOT-ID> ist die ID aus der zuvor geprüften Liste. Verwende nicht ungeprüft latest: Wenn ein Repository verschiedene Rechner oder Pfade enthält, kann der neueste Snapshot zu einer anderen Sicherungsreihe gehören.[1]
Liste den Inhalt des ausgewählten Stands auf:
Notiere daraus den vollständigen Pfad der Testdatei und des Testordners. restic ls zeigt die Pfade innerhalb eines Snapshots; mit --long kannst du zusätzlich unter anderem Größe und Änderungszeit kontrollieren.[2]
3. Leeres Testziel und Referenzwerte vorbereiten¶
Lege ein eindeutig benanntes Testziel außerhalb der Produktivdaten fest:
Ersetze <YYYY-MM-DD> durch das Testdatum. Brich ab, falls dieser Pfad bereits existiert. Erstelle ihn erst nach dieser Kontrolle:
Der Befehl erzeugt das Verzeichnis nur, wenn unter diesem Namen noch keine Datei und kein Ordner vorhanden ist. Bleibt das Verzeichnis aus, wähle einen anderen Namen und lösche nichts vorschnell.
Dokumentiere vor dem Restore bekannte Referenzwerte:
Datei im Snapshot: <DATEIPFAD>
Erwartete Größe: <BYTES-ODER-UNBEKANNT>
Erwartete SHA-256-Prüfsumme: <SHA256-ODER-UNBEKANNT>
Erwarteter Inhalt: <KURZE-BESCHREIBUNG>
Ersetze <DATEIPFAD> durch den exakten Pfad aus restic ls, <BYTES-ODER-UNBEKANNT> durch die bekannte Dateigröße in Bytes oder durch unbekannt, <SHA256-ODER-UNBEKANNT> durch einen früher vertrauenswürdig dokumentierten Hash oder durch unbekannt und <KURZE-BESCHREIBUNG> durch den erwarteten Dateiinhalt. Erzeuge nicht erst nach einem vermuteten Datenverlust einen „Sollwert“ aus einer möglicherweise beschädigten Originaldatei.
4. Einzelne Datei zuerst als Vorschau prüfen¶
Übernimm den vollständigen Snapshot-Pfad in eine Variable:
Ersetze <DATEIPFAD-IM-SNAPSHOT> durch den exakten Pfad aus Schritt 2. Starte zuerst nur die Vorschau:
restic restore "$SNAPSHOT_ID" \
--target "$TESTZIEL" \
--include "$DATEIPFAD" \
--dry-run \
--verbose=2
--include beschränkt die Wiederherstellung auf den angegebenen Pfad. --dry-run schreibt keine wiederhergestellten Dateien, und --verbose=2 zeigt, was restic wiederherstellen würde.[1] Prüfe, dass nur die gewünschte Datei und die zugehörige Verzeichnisstruktur genannt werden.
Kein --delete für diesen Test
--delete entfernt im Ziel Dateien, die nicht im Snapshot vorhanden sind. Die restic-Dokumentation verlangt dafür eine besonders sorgfältige Vorschau.[1] In einem neu angelegten Testziel ist die Option unnötig und bleibt deshalb weg.
5. Datei wiederherstellen und Inhalt kontrollieren¶
Führe denselben Restore ohne --dry-run aus:
restic bildet bei einer Wiederherstellung des vollständigen Snapshots den Pfad unterhalb des Testziels nach.[1] Suche die tatsächlich erzeugte Datei:
Kontrolliere Größe und SHA-256-Prüfsumme. Ersetze <RELATIVER-WIEDERHERSTELLUNGSPFAD> durch den unter $TESTZIEL gefundenen relativen Pfad:
Vergleiche die Ausgabe mit den vor dem Test dokumentierten Werten. Öffne die Datei zusätzlich mit der passenden Anwendung und prüfe den Inhalt. Eine übereinstimmende Prüfsumme bestätigt identische Bytes, aber nicht, dass du den richtigen Sicherungsstand ausgewählt hast.
Die Praxisdokumentation der University of Manchester beschreibt denselben Grundgedanken für Snapshots: einen Stand unmittelbar vor dem Verlust auswählen, die gesuchte Datei oder den Ordner darin kontrollieren und anschließend gezielt zurückkopieren.[4]
6. Vollständigen Ordner getrennt wiederherstellen¶
Lege für den Ordnertest ein zweites, noch nicht vorhandenes Ziel an:
Ersetze <YYYY-MM-DD> wieder durch das Testdatum und erstelle das Ziel nur, wenn es noch nicht existiert:
Setze den Quellordner so, wie ihn restic ls anzeigt:
Ersetze <QUELLUNTERORDNER-IM-SNAPSHOT> durch den vollständigen Ordnerpfad aus restic ls. Prüfe danach zuerst die Vorschau. Die Kombination aus Snapshot-ID, Doppelpunkt und Quellunterordner stellt gezielt einen Unterbaum wieder her; Pfade für weitere Ein- oder Ausschlüsse wären dann relativ zu diesem Unterordner.[1]
restic restore "$SNAPSHOT_ID:$QUELLUNTERORDNER" \
--target "$ORDNER_TESTZIEL" \
--dry-run \
--verbose=2
Wenn Ziel, Dateiliste und Datenmenge plausibel sind, führe den echten Ordnertest aus:
Prüfe danach Dateianzahl und belegten Platz:
Vergleiche beides mit deiner Erwartung, öffne mehrere unterschiedliche Dateitypen und prüfe besonders Konfigurationen, Archive und Datenbankexporte. Die öffentlich erreichbaren Videos „Backup Management: Veeam File Restore Test“ und „Restic Guide Part 4: Restoring Backup“ zeigen ergänzend getrennte Datei-, Ordner- und Snapshot-Wiederherstellungen; für Befehlsdetails bleibt die aktuelle restic-Dokumentation maßgeblich.[5][6][1]
7. Geräte- oder System-Restore gefahrlos testen¶
Ein Geräte- oder Systemabbild darfst du nicht probeweise über das funktionierende Original schreiben. Wähle stattdessen eine dieser Stufen:
- Ablaufprüfung ohne Schreibzugriff: Starte das offizielle Rettungsmedium, prüfe, ob Netzwerk, Backup-Ziel, Schlüssel und der gewünschte Sicherungsstand erkannt werden, und brich vor der ersten Bestätigung ab, die den Zieldatenträger verändert.
- Volltest auf Ersatzhardware: Verwende einen leeren Datenträger in einem geeigneten Ersatzgerät. Prüfe vorher Größe, Startmodus, Treiberbedarf und Lizenzbedingungen.
- Isolierter virtueller Test: Importiere oder stelle das Abbild nur dann in einer virtuellen Maschine wieder her, wenn das Backup-Produkt diesen Weg unterstützt. Verbinde die Testmaschine zunächst nicht mit dem Produktivnetz.
Gerätetest: <ABLAUFPRUEFUNG-ERSATZGERAET-ODER-VM>
Rettungsmedium startet: <JA-ODER-NEIN>
Backup-Ziel erreichbar: <JA-ODER-NEIN>
Sicherungsstand sichtbar: <JA-ODER-NEIN>
Zieldatenträger eindeutig: <JA-ODER-NEIN>
Schreibvorgang gestartet: <NEIN-BEI-ABLAUFPRUEFUNG>
Start nach Volltest: <ERFOLGREICH-FEHLER-ODER-NICHT-GETESTET>
Ersetze <ABLAUFPRUEFUNG-ERSATZGERAET-ODER-VM> durch die gewählte Testart und jedes <JA-ODER-NEIN> durch das beobachtete Ergebnis. Ersetze <NEIN-BEI-ABLAUFPRUEFUNG> bei einer reinen Ablaufprüfung zwingend durch NEIN. Ersetze <ERFOLGREICH-FEHLER-ODER-NICHT-GETESTET> durch das echte Startergebnis oder durch nicht getestet. Für einen echten Wiederanlauf empfiehlt CISA die Wiederherstellung priorisierter Systeme in einem sauberen Netzwerk; vorhandene Systemabbilder und passende Hardware können den Neuaufbau erleichtern.[3]
Doppeltes System nicht unkontrolliert vernetzen
Ein wiederhergestelltes Gerät kann alte Kennwörter, Freigaben, Synchronisationsaufträge, Hostnamen und feste Netzwerkadressen enthalten. Halte es zunächst isoliert, prüfe Datum und Zustand des Images und verbinde es erst nach einer bewussten Freigabe mit dem Produktivnetz.
8. Prüfprotokoll ausfüllen und Wiederherstellungszeit bewerten¶
Dokumentiere jeden Test direkt danach:
Pruefdatum: <YYYY-MM-DD>
Backup-System: <BACKUP-SYSTEM>
Snapshot: <SNAPSHOT-ID>
Testart: <DATEI-ORDNER-ODER-GERAET>
Beginn: <HH:MM>
Ende: <HH:MM>
Ergebnis: <ERFOLGREICH-ODER-FEHLER>
Dateien erwartet: <ANZAHL>
Dateien gefunden: <ANZAHL>
Pruefsumme: <PASSEND-ABWEICHEND-ODER-NICHT-VORHANDEN>
Oeffnungstest: <ERFOLGREICH-ODER-FEHLER>
Abweichungen: <BESCHREIBUNG-ODER-KEINE>
Naechster Test: <YYYY-MM-DD>
Ersetze <YYYY-MM-DD> durch Prüfdatum beziehungsweise nächsten Testtermin, <BACKUP-SYSTEM> durch die Sicherungslösung, <SNAPSHOT-ID> durch die getestete ID und <DATEI-ORDNER-ODER-GERAET> durch die Testart. Für <HH:MM> trägst du die jeweilige lokale Uhrzeit ein. Ersetze <ERFOLGREICH-ODER-FEHLER> durch das beobachtete Ergebnis, jedes <ANZAHL> durch die gezählte Dateimenge, <PASSEND-ABWEICHEND-ODER-NICHT-VORHANDEN> durch den Prüfsummenstatus und <BESCHREIBUNG-ODER-KEINE> durch festgestellte Abweichungen oder keine.
Trage keinen Erfolg ein, wenn eine Datei nur sichtbar war, sich aber nicht öffnen ließ. Vergleiche die gemessene Dauer mit deinem Ziel aus Schritt 1. War der Restore zu langsam, dokumentiere den Engpass, etwa fehlende Bandbreite, ein nicht auffindbares Rettungsmedium oder eine unklare Snapshot-Auswahl.
Bewahre das Protokoll getrennt vom einzigen Backup auf. Es darf Speicherorte und Zuständigkeiten enthalten, aber keine Kennwörter, Wiederherstellungsschlüssel oder ungeschützten Zugangsdaten.
9. Rückweg, Aufräumen und typische Fehler¶
Behalte Originaldaten und Backup unverändert, bis alle Prüfungen abgeschlossen sind. Ein erfolgreicher Test-Ordner ist nur eine kontrollierte Kopie und ersetzt keine weitere Sicherung. Räume ihn erst auf, wenn das Protokoll vollständig ist und du keine Dateien daraus übernehmen musst.
Der Befehl zeigt die beiden Zielpfade noch einmal an, ohne etwas zu löschen. Vergleiche sie mit deinem Protokoll. Entferne Testdaten anschließend bewusst mit dem Dateimanager oder einem einzeln geprüften Löschbefehl; übernimm niemals ungeprüft eine rekursive Löschzeile aus einer Anleitung.
Typische Fehler und der sichere Rückweg:
- Falscher Snapshot: Stoppe den Test, lösche keine Sicherungsstände und wähle anhand von Datum, Host und Pfad eine konkrete ID.
- Testziel war nicht leer: Breche ab und erstelle ein neues Ziel. Ein vorhandenes Ziel erschwert die Unterscheidung zwischen alten und wiederhergestellten Dateien.
- Datei fehlt trotz erfolgreichem Lauf: Prüfe mit
restic ls "$SNAPSHOT_ID"den exakten Snapshot-Pfad und wiederhole zuerst den Dry-Run. - Prüfsumme weicht ab: Verwende die Datei nicht als bestätigte Wiederherstellung. Prüfe Referenzwert, Snapshot und Repository;
restic checkkontrolliert die Repository-Struktur, mit--read-datazusätzlich die gespeicherten Daten, benötigt dafür aber mehr Zeit und gegebenenfalls Bandbreite.[2] - Geräte-Restore zeigt den falschen Datenträger: Brich vor jedem Schreibvorgang ab. Beschrifte Ersatzdatenträger eindeutig und trenne nicht benötigte Laufwerke.
- Wiederhergestelltes System startet nicht: Bewahre Fehlertext und Protokoll auf, prüfe Startmodus, Treiber und Herstellerhinweise und verändere nicht gleichzeitig das einzige Backup.
- Restore dauert zu lange: Miss erneut mit einer repräsentativen Datenmenge und passe entweder Wiederherstellungsziel, Verbindung oder Notfallplan an.
Fertig¶
Der Test ist bestanden, wenn du einen eindeutig gewählten Snapshot verwendet, Datei und Ordner in getrennte leere Ziele wiederhergestellt, die erwarteten Inhalte geöffnet, vorhandene Referenzprüfsummen verglichen und Dauer sowie Ergebnis dokumentiert hast. Beim Geräte-Test muss zusätzlich entweder die sichere Abbruchstelle vor dem ersten Schreibzugriff dokumentiert oder ein vollständiger Wiederanlauf auf geeigneter Ersatzhardware beziehungsweise in einer unterstützten isolierten Testumgebung gelungen sein. Plane den nächsten Testtermin und wiederhole ihn nach Änderungen an Backup-Software, Hardware, Verschlüsselung oder Zugangsdaten.
Sources¶
[1] https://restic.readthedocs.io/en/stable/050_restore.html — Restoring from backup — restic documentation [2] https://restic.readthedocs.io/en/stable/045_working_with_repos.html — Working with repositories — restic documentation [3] https://www.cisa.gov/stopransomware/ransomware-guide — #StopRansomware Guide — CISA [4] https://ri.itservices.manchester.ac.uk/csf3/filesystems/backup — Backup and Restore — University of Manchester [5] https://www.youtube.com/watch?v=hY7usQvVZHo — Backup Management: Veeam File Restore Test [6] https://www.youtube.com/watch?v=1xhfQI3mniU — Restic Guide Part 4: Restoring Backup