Warum Restore-Tests wichtiger sind als Backups
Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am
Ein Backup, das nie wiederhergestellt wurde, ist eine Behauptung, keine Tatsache. Der einzige Weg, wirklich zu wissen, dass ein Backup funktioniert, ist es zurückzulesen und zu prüfen. Ein grüner „Backup abgeschlossen"-Status beweist, dass der Schreibvorgang geklappt hat, nichts darüber, ob die Daten später korrekt zurückkommen, was der einzige Grund ist, warum das Backup überhaupt existiert.
Sichern
Mail, Kalender, Kontakte und OneDrive, inkrementell und verschlüsselt, auf Ihrem Speicher.
Stichprobe ziehen
Jede Woche, je Postfach und OneDrive: rund 20 Mails, 20 Dateien, Kalender und Kontakte.
Zurücklesen
Aus dem neuesten Backup, über denselben Weg wie ein echter Restore.
Vergleichen
Byte für Byte gegen die gespeicherten Prüfsummen. Nur ein Treffer zählt.
Angezeigt je Postfach als Wiederherstellbarkeit
- BereitLetzte Prüfung bestanden
- AchtungWarnungen in der Prüfung
- Nicht wiederherstellbarPrüfung fehlgeschlagen
- Nicht nachgewiesenNoch nicht zurückgelesen
Was still schiefzugehen pflegt
Verschlüsselungsschlüssel driften aus der Synchronisation mit dem, was zum Schreiben eines Chunks genutzt wurde. Speicher beschädigt still einen Block, der monatelang nicht erneut gelesen wird. Eine Formatänderung bricht leise die Kompatibilität mit älteren Archiven. Nichts davon zeigt sich im eigenen Erfolgsstatus eines Backup-Jobs. Es zeigt sich nur, wenn jemand tatsächlich einen Restore versucht, was genau der Moment ist, in dem niemand zum ersten Mal ein Problem entdecken möchte.
Was ein grünes „Backup erfolgreich“ nicht verrät
Der Job-Status belegt das Schreiben. Nur das Zurücklesen belegt den Restore.
| Stiller Fehler | Zeigt es der Backup-Job? | Zeigt es ein Restore-Test? | Erkannt beim |
|---|---|---|---|
| Schlüssel passt nicht mehr zu dem, womit ein Chunk geschrieben wurde | Nein | Ja | Entschlüsseln |
| Speicher beschädigt still einen Block, den niemand liest | Nein | Ja | Zurücklesen, vergleichen |
| Eine Formatänderung bricht ältere Backups | Nein | Ja | Zurücklesen |
Was Restow dagegen tut
Ein Backup, das nie zurückgelesen und verifiziert wurde, wird im Produkt als nicht erledigt angezeigt, nicht still zum Erfolg hochgerundet. Heute wird das durch eine wöchentliche Stichprobenprüfung der Wiederherstellbarkeit je Postfach und OneDrive durchgesetzt: Sie liest eine Stichprobe über den Restore-Pfad zurück und vergleicht sie mit den aufgezeichneten Hashes, jeder Fehler wird im eigenen Status dieses Postfachs sichtbar gemacht. Sie stellt nicht in ein Microsoft-365-Postfach oder OneDrive wieder her; der optionale Test-Restore in ein Ziel ist in 0.2.1 nicht verdrahtet. Dateifreigaben werden nach jedem neuen Sicherungsstand geprüft, und Proxmox VE (Preview) kann Sicherungsstände per Startprüfung testen; beides ist kein vollständiger Test-Restore in ein separates Ziel, der geplant ist. Vollständige, elementweise Verifizierung für alles Gesicherte (keine Stichprobe) ist geplant; siehe die Verifizierungs-Funktionsseite für den genauen aktuellen Status, und wie Restow entsteht für die Release-Checkliste, die jede Version bestehen muss: sie umfasst schon heute einen vollständigen Backup-und-Restore-Lauf mit Byte-für-Byte-Hash-Vergleich vor jedem Tag, dazu den Nachweis, dass ein Restore auch mit dem eigenständigen Werkzeug ganz ohne laufenden Restow-Server funktioniert.
Für 0.1.0 hat diese Checkliste benannte Lücken. Backup und Restore für Microsoft 365 sind noch nicht gegen einen echten Microsoft-365-Mandanten gelaufen; sie sind durch Tests gegen eine simulierte Graph-API abgedeckt. Das Installationsskript des Endpunkt-Agenten wurde nur in einem Linux-Container ausgeführt, der macOS-Installer gehörte nicht zu den Prüfungen. Im abschließenden Release-Lauf vom 01.10.2026 bestanden für den vollständigen Build 9 von 11 Prüfungen vollständig, eine teilweise (der Upgrade-Pfad lässt sich noch nicht prüfen, weil es kein früheres Release gibt), und die Microsoft-365-Prüfung wurde mangels Microsoft-365-Mandant übersprungen. Der Community-Build bestand 7 vollständig und eine teilweise und übersprang die Microsoft-365-Prüfung sowie planmäßig die Journal-Prüfung und die Prüfung der Speicherziele, die im vollständigen Build laufen.
Eine Methode, die mit jedem Backup-Tool funktioniert, vom Restore-Test über den Hash-Vergleich bis zu dokumentierten Ergebnissen, steht unter wie man nachweist, dass ein Backup wiederherstellbar ist.
Häufig gefragt
Warum ist ein ungetestetes Backup eigentlich kein Backup?
Weil „Backup erfolgreich abgeschlossen“ nur beweist, dass der Schreibvorgang geklappt hat. Es sagt nichts darüber aus, ob die Daten sich später auch korrekt zurücklesen lassen, was der ganze Sinn eines Backups überhaupt ist. Ein beschädigter Chunk, ein defekter Verschlüsselungsschlüssel, oder ein subtiler Formatfehler können sich alle monatelang unbemerkt in einem grün gemeldeten Backup verstecken, entdeckt erst im denkbar schlechtesten Moment: bei einem echten Notfall-Restore.
Was prüft Restow heute, und was kommt noch?
Heute: eine wöchentliche Stichprobenprüfung der Wiederherstellbarkeit je Postfach und OneDrive. Sie liest eine Stichprobe über den Restore-Pfad zurück und vergleicht sie mit den aufgezeichneten Hashes, ehrlich als Stichprobe gekennzeichnet. Sie stellt nicht in ein Microsoft-365-Postfach oder OneDrive wieder her; der optionale Test-Restore in ein Ziel ist in 0.2.1 nicht verdrahtet. Seit 0.4.0 werden außerdem Dateifreigaben nach jedem neuen Sicherungsstand geprüft (bis zu 20 stichprobenartig gewählte Dateien werden zurückgelesen und verglichen, dazu wöchentlich ein restic check von 5 Prozent des Repositorys), und Proxmox VE (Preview) kann Sicherungsstände per Startprüfung testen: Der Sicherungsstand wird als neuer, vom Netzwerk getrennter Gast wiederhergestellt, gestartet, auf eine Antwort des Gast-Agents geprüft und wieder gelöscht. Geplant: ein vollständiger Test-Restore in ein separates Ziel für alles und eine lückenlose Verifizierung jedes gesicherten Elements statt einer Stichprobe. Bekannte Lücke in 0.2.1: Backup und Restore für Microsoft 365 sind in den Release-Prüfungen noch nicht gegen einen echten Microsoft-365-Mandanten gelaufen; sie sind durch Tests gegen eine simulierte Graph-API abgedeckt. Siehe die Funktionsseite zur Verifizierung für den aktuellen, genauen Status.
Wie Restore selbst funktioniert →
Mehr in Wissen: die 3-2-1-Backup-Regel und die „0“ in 3-2-1-1-0 →