← Alle Funktionen

Beweisen, dass Backups sich wiederherstellen lassen

Von Lucas Flores, IT Systeme Flores UG. Zuletzt aktualisiert am 2026-10-29

Ein Backup, das nie über den Restore-Pfad zurückgelesen wurde, ist eine Theorie, kein Nachweis. Deshalb behandelt Restow „gesichert“ und „bewiesen wiederherstellbar“ als zwei getrennte, getrennt angezeigte Zustände, und ein Backup ohne verifiziertes Zurücklesen wird als nicht erledigt angezeigt, nicht als leiseres Grün.

1. 1

   Sichern

   Mail, Kalender, Kontakte und OneDrive, inkrementell und verschlüsselt, auf Ihrem Speicher.

2. 2

   Stichprobe ziehen

   Jede Woche, je Postfach und OneDrive: rund 20 Mails, 20 Dateien, Kalender und Kontakte.

3. 3

   Zurücklesen

   Aus dem neuesten Backup, über denselben Weg wie ein echter Restore.

4. 4

   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 eine Restore-Prüfung liest, wie oft sie läuft und was Grün, Rot und „Nicht nachgewiesen“ bedeuten, in einfacher Sprache für Kunden und IT-Dienstleister: wie Restow belegt, dass Ihre Sicherungen wiederherstellbar sind.

Was heute geprüft wird

Eine wöchentliche Stichprobenprüfung der Wiederherstellbarkeit läuft je Postfach, OneDrive und SharePoint-Website: Restow liest eine Stichprobe über den Restore-Pfad zurück und vergleicht sie mit den gespeicherten Prüfsummen, dann zeigt es das Ergebnis ehrlich als stichprobenbasierte Prüfung, nicht als vollständige Abdeckung, die es sich noch nicht verdient hat. Die Prüfung stellt nichts in ein Microsoft-365-Postfach, OneDrive oder IMAP-Konto wieder her; der optionale Test-Restore in ein separates Ziel ist noch nicht angebunden (siehe unten). Wo eine Prüfung fehlschlägt, taucht dieser Fehler im eigenen Status des Postfachs oder OneDrives auf. Er wird nicht in einem grünen Gesamt-Dashboard weggemittelt.

Ein Objekt, das aus seiner Quelle entfernt wurde, wird anders bewertet. Seit 0.4.7 wird zum Beispiel ein in Microsoft 365 gelöschtes Postfach nicht mehr rot, weil seine letzte Sicherung altert: Nichts sichert es mehr, und die Aufbewahrung behält immer seinen neuesten Sicherungsstand. Es wird danach bewertet, ob sich diese Sicherung wiederherstellen lässt, ohne Gründe zum Alter wie „Die letzte Sicherung ist N Tage alt“, und ist nie überfällig; eine aufbewahrte Sicherung, die sich nicht wiederherstellen lässt, bleibt rot. Die Tabelle sagt „In der Quelle entfernt, Sicherungen bleiben“, und die Berichtsseite beginnt mit „Aus der Quelle entfernt“ und führt das Alter als „Nicht gewertet: ...“ auf. Dieselbe Bewertung gilt in der Statistik, in der Objektliste, in der Gesamtbereitschaft des Mandanten, in der Integrations-API und in der Benachrichtigung verify.completed. Ein Objekt, dessen neueste Sicherung nie geprüft wurde, bekommt vom wöchentlichen Planer noch eine Prüfung.

Microsoft-365-Objekte, die Restow nicht mehr sichert (das Konto ist deaktiviert, es hat keine Lizenz, Microsoft hat es gesperrt, oder es wurde aus der Quelle entfernt), stehen zuerst gelb als „Nicht mehr gesichert, bitte bestätigen“, mit dem Grund. Das ist kein Fehler, kein Rot und nicht überfällig, aber die Bereitschaft des Mandanten bleibt mindestens gelb, nie grün, und die Integrations-API zählt sie in readiness.toConfirm, bis ein Administrator mit „Ja, beabsichtigt“ bestätigt; danach steht das Objekt grau als „Absichtlich nicht mehr gesichert“. Deaktivierte oder unlizenzierte Postfächer und gesperrte OneDrives und Websites stehen als „Nicht gesichert: Konto deaktiviert“, „Nicht gesichert: keine Lizenz“ oder „Nicht gesichert: gesperrt“ und sind neutral: Sie erhöhen keine Fehlerzahl.

Server und Clients sind ebenfalls abgedeckt

Bei einem Server oder Client, der mit dem Agent gesichert wird (siehe Server- und Client-Backup), läuft die Prüfung nach jedem neuen guten Backup. Der Agent hält die SHA-256-Prüfsummen von bis zu 20 zufälligen Dateien fest, der Restow-Server liest sie aus dem Repository zurück und vergleicht die Hashes, und das Ergebnis ist nur grün, wenn sie übereinstimmen. Zusätzlich wird das Repository einmal pro Woche geprüft. Beide Ergebnisse fließen in die Recovery Readiness ein, sodass ein Rechner erst dann als wiederherstellbar gilt, wenn Dateien tatsächlich mit übereinstimmenden Hashes zurückgelesen wurden. Gäste von Proxmox VE (eine Preview) zählen bei der Recovery Readiness ebenfalls mit. Eine fehlgeschlagene Prüfung sagt, was passiert ist, warum und was zu tun ist: siehe die Fehlererklärungen in der Dokumentation.

Dateifreigaben sind ebenfalls abgedeckt

Bei einer Freigabe (siehe Dateifreigaben) wird jeder neue Sicherungsstand geprüft: Restow liest bis zu 20 Stichproben-Dateien zurück und vergleicht sie mit dem Gesicherten, und das Repository bekommt wöchentlich ein restic check von 5 Prozent seiner Daten. Die Wiederherstellbarkeit bewertet eine Freigabe nach ihrem neuesten Sicherungsstand. Ein Sicherungsstand ohne Stichproben, weil sich jede Datei in der Stunde vor dem Lauf geändert hat, wird gelb bewertet und sagt, warum. Kopierjobs nutzen nur einen Sicherungsstand, der seine Prüfung bestanden hat.

Proxmox VE: eine Prüfung nach jedem Backup und Startprüfungen

Seit 0.4.2 wird jeder neue Sicherungsstand einer Proxmox-VE-VM oder eines Containers (eine Preview) binnen Minuten nach seiner Sicherung zurückgelesen: Der Server vergleicht eine Stichprobe seiner Blöcke mit dem aufgezeichneten SHA-256 (bei einem Container ein restic-Check einer Teilmenge), neben der wöchentlichen Prüfung jedes Gasts. Das ist standardmäßig an (Installation › Proxmox VE) und lässt sich für die Installation ausschalten. „Jetzt prüfen“ und „Alle ungeprüften prüfen“ in der Wiederherstellbarkeit starten Prüfungen von Hand, und eine rote Prüfung zeigt den Fehler, den sie gefunden hat. Sie liest Daten aus dem Speicher zurück; den Gast startet sie nicht.

Eine Prüfung, die nicht laufen konnte, ist keine fehlgeschlagene Prüfung. Seit 0.4.3 wird die Prüfung verschoben und zehn Minuten später erneut versucht, wenn ein anderer Vorgang die Sperre auf dem restic-Repository eines Containers hält; das bisherige Ergebnis bleibt solange stehen. Nach zwei Stunden steht der Sicherungsstand als „Nicht prüfbar: Repository gesperrt“ da: gelb (Achtung) in der Wiederherstellbarkeit, nie rot und nie grün, mit dem Bericht von restic, wer die Sperre hält. Veraltete Sperren werden vor der Prüfung entfernt (Einzelheiten). Ein gesperrtes Repository erzeugt deshalb kein rotes „Restore-Prüfung fehlgeschlagen“ mehr, das die Daten nie verdient haben, und auch kein grünes: Ein Sicherungsstand, den keine Prüfung lesen konnte, bleibt unbewiesen. Prüfungen, die vor 0.4.3 wegen einer Sperre rot ausfielen, bleiben rot, bis die nächste Prüfung läuft („Jetzt prüfen“).

Proxmox VE (eine Preview) hat mehr als die Stichprobenprüfung. Ein Job kann den neuesten Sicherungsstand jedes Gasts wöchentlich oder nach jedem Backup starten, und „Jetzt Start prüfen“ an einem Sicherungsstand fordert eine von Hand an. Sie ist standardmäßig aus und hat ein Speicherlimit und eine Wartezeit auf den Guest Agent. Der Knoten des Gasts stellt den Sicherungsstand als neuen Gast im Pool restow-restore wieder her, isoliert ihn vor dem Start (jede Netzwerkschnittstelle getrennt oder an einer isolierten Bridge, Passthrough-Geräte, serielle Ports und Bind-Mounts entfernt), startet ihn, wartet auf den QEMU Guest Agent (bei einem Container: seinen Init) und zerstört ihn in jedem Fall. Je Knoten läuft ein Test zur Zeit, nie neben einem Backup. Grün heißt, der Guest Agent hat geantwortet, Gelb, die VM ist nur gestartet und nichts hat geantwortet, Rot, die Wiederherstellung, der Start oder der Boot ist fehlgeschlagen. Die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand nach seiner Startprüfung, wo es eine gibt. Ports oder Anwendungen im Gast werden nicht geprüft. Sie braucht restow-pve 0.4.0 auf dem Knoten und wurde gegen einen simulierten Knoten getestet, nicht gegen einen echten Proxmox-VE-Cluster.

Die Speicherprüfung: beschädigt ist nicht dasselbe wie nicht lesbar

Neben den Restore-Prüfungen liest eine Speicherprüfung Packs zurück und vergleicht sie mit ihrer aufgezeichneten Größe und Prüfsumme (jede Woche eine Stichprobe, jeden Monat jedes Pack). Seit 0.4.2 unterscheidet sie ein Pack, das sie im Moment nicht lesen konnte (ein mitten in der Übertragung abgebrochener Download, eine zurückgesetzte Verbindung, ein Timeout, S3 mit der Bitte um langsameres Tempo, verweigerter Zugriff), von einem beschädigten. Sie liest ein solches Pack erneut, bis zu dreimal; eines, das unlesbar bleibt, steht in Wiederherstellbarkeit › Speicherintegrität als „vorübergehend nicht lesbar“, mit dem Fehler, in wie vielen Prüfungen in Folge es nicht lesbar war und wann. Objekte, die es verwenden, bekommen „Achtung“, nicht „Nicht wiederherstellbar“: Dazu braucht es ein nachweislich beschädigtes Pack (fehlt, falsche Größe oder Prüfsumme) oder eines, das in 3 Prüfungen in Folge über mindestens 24 Stunden nicht gelesen werden konnte. Lesen die Packs wieder intakt, endet der Befund, und die Restore-Prüfungen der Objekte bewerten sie wieder selbst.

Die Ransomware-Erkennung beurteilt, sie beweist nicht

Jeder neue Sicherungsstand wird außerdem auf Anzeichen von Ransomware beurteilt, aus Daten, die das Backup ohnehin hat. Das ist eine andere Frage als „lässt sich das wiederherstellen“: Ein Sicherungsstand ohne Befund beweist nichts, und ein Befund ist ein Grund nachzusehen. Siehe Ransomware-Erkennung.

Das Archiv hat eine eigene Prüfung

Die SHA-256-Hash-Kette des Archivs wird getrennt von den Backups geprüft. Die Kettenprüfung verifiziert jedes Glied, die täglichen Anker (jede Nacht geschrieben) und auf Wunsch eine Stichprobe der Nachrichteninhalte. Sie gehört zum Archiv, in jeder Edition, siehe das Archiv.

Was geplant ist

Ein vollständiger Test-Restore in ein separates Ziel für jede Art von Backup ist geplant, ebenso die Verifizierung jedes gesicherten Elements statt einer Stichprobe; die Startprüfung bei Proxmox VE deckt nur Gäste ab. Bis dahin ist die Stichprobenprüfung der ehrlich benannte Zwischenzustand: siehe die Roadmap für den genauen Status, und wie Restow entsteht für den automatisierten Release-Smoke-Lauf, den jedes Release bestehen muss, bevor es veröffentlicht wird, einschließlich eines IMAP-Backups und -Restores mit Byte-für-Byte-Vergleich und eines Restores bei gestopptem Server.

Was die Release-Prüfungen abdecken

Ein Release-Smoke-Lauf muss jedes Release bestehen, bevor es veröffentlicht wird: Neuinstallation, Restores mit Hash-Vergleich, Endpoint-Backup, Backup einer Freigabe gegen Samba, Archiv-Erfassung aus einem IMAP-Konto und Mail-Import, unter 13 Prüfungen. In jedem Release seit 0.4.4 haben für die vollständigen Images 12 von 13 Prüfungen vollständig bestanden und 1 wurde übersprungen; für die Community-Images haben 9 von 13 vollständig bestanden und 4 wurden übersprungen, darunter planmäßig die Prüfungen, die ein Business-Modul oder einen zweiten Mandanten brauchen: der Empfang von Journalberichten, die Speicherziele und, seit 0.4.4, die Archiv-Erfassung. Von 0.4.0 bis 0.4.3 hatte der Lauf 12 Prüfungen (die Prüfung der Freigaben kam mit 0.4.0): 11 von 12 haben für die vollständigen Images vollständig bestanden und 1 wurde übersprungen, für die Community-Images haben 9 von 12 vollständig bestanden und 3 wurden übersprungen. Von 0.2.1 bis 0.3.6 hatte er 11 Prüfungen: 10 von 11 haben für die vollständigen Images vollständig bestanden und 1 wurde übersprungen, für die Community-Images haben 8 von 11 vollständig bestanden und 3 wurden übersprungen. Der Bericht, mit dem Grund für jede übersprungene Prüfung, liegt jedem Release bei.

Die übersprungene Prüfung ist Nummer 4, die automatisierte Prüfung von Microsoft-365-Backup und -Restore gegen einen echten Tenant, ausgeführt gegen einen Dev-Tenant. Sie ist noch nicht aktiv und wurde in jedem bisherigen Release übersprungen. Microsoft 365 ist durch Tests gegen eine simulierte Graph-API abgedeckt. Restow ist eine Beta: Betreiben Sie es neben Ihren bestehenden Sicherungen, bis Sie Restores gegen Ihre eigenen Daten geprüft haben. In den Release-Prüfungen läuft das Installationsskript des Agents nur in einem Linux-Container; der macOS-Agent wird ausgeliefert, sein Installer ist aber nicht Teil der Release-Prüfungen (die eigenen Tests des Agents liefen nativ auf macOS).

Häufig gefragt

Warum Restore-Tests wichtiger sind als Backups →

Mehr in Wissen: die 3-2-1-Backup-Regel und die „0“ in 3-2-1-1-0 →

Mehr in Wissen: RPO und RTO erklärt →