Wie Restow prüft, ob eine Sicherung wiederherstellbar ist

Restow behandelt eine Sicherung, die niemand zurückgelesen hat, als unbewiesen, nicht als „vermutlich in Ordnung“. Diese Seite erklärt genau, was die automatisierte Prüfung tut, nach welchem Zeitplan, und, ebenso wichtig, was sie noch nicht beweist.

Was läuft, und wann

Zwei getrennte, automatisierte Jobs prüfen, ob eine Sicherung wiederherstellbar ist.

Wiederherstellbarkeits-Prüfung (verify)

Für jedes geschützte Objekt (ein Postfach, ein OneDrive, ein IMAP-Konto) tut die Prüfung Folgendes:

Sie lädt den letzten abgeschlossenen Snapshot und dessen Manifest.
Sie zieht eine Zufallsstichprobe (standardmäßig 20 Mails und 20 Dateien, Kalendereinträge und Kontakte mit einem Viertel dieser Menge, je 5) oder, bei einer vollständigen Prüfung, jedes berechtigte Objekt des Snapshots statt einer Stichprobe.
Sie liest jedes ausgewählte Element über denselben Code-Pfad, den auch ein echter Restore nutzt, zurück: Chunk-Index, Pack-Abruf mit Ausweichen auf eine Kopie, AES-256-GCM-Entschlüsselung.
Sie vergleicht das Gelesene mit dem Manifest.
Sie bewertet das Objekt als Bereit, Achtung, Nicht wiederherstellbar, Nicht geprüft oder Noch keine Sicherung (siehe unten).

Sie läuft:

wöchentlich, nach dem empfohlenen Standard-Zeitplan (Sonntag, 03:00 Uhr, Standard-Zeitzone der Installation: Europe/Berlin, sofern nicht anders konfiguriert, am Zeitplan selbst hinterlegt),
nach jeder Sicherung eines Objekts, automatisch, sobald für einen Mandanten ein aktiver Verifizierungs-Zeitplan besteht (sodass auch eine gerade erst erstellte Sicherung geprüft wird, nicht nur die älteste), außer es ist für dieses Objekt bereits eine Prüfung eingereiht oder läuft gerade,
auf Anfrage, über Wiederherstellbarkeit („Jetzt prüfen“ für ein Objekt, „Alle jetzt prüfen“ für den Mandanten).

Ohne aktiven Verifizierungs-Zeitplan bleibt die Wiederherstellbarkeit dauerhaft unbewiesen, selbst wenn Sicherungen selbst weiter erfolgreich laufen. Restow sagt das unverblümt, statt stillschweigend einen grünen Zustand anzunehmen.

Speicher-Integritätsprüfung (scrub)

Getrennt davon prüft ein Scrub-Job den rohen Speicher, in dem die Chunks liegen, unabhängig von einer einzelnen Sicherung:

eine Stichproben-Prüfung wöchentlich (SHA-256 über eine Zufallsauswahl von Packs, auf jedem Speicherziel, das eine Kopie hält),
eine vollständige Prüfung monatlich (jedes Pack),
automatische Reparatur einer beschädigten Kopie aus einer intakten Kopie auf einem anderen Ziel, wenn eine existiert,
ein Pack, das auf jedem Ziel beschädigt zurückkommt, wird als beschädigt markiert: spätere Sicherungen deduplizieren nicht mehr dagegen und schreiben dessen Inhalt stattdessen intakt neu, allerdings nur den Inhalt, den die Quelle (das Postfach, OneDrive oder IMAP-Konto) noch besitzt; nicht mehr an der Quelle vorhandener Inhalt lässt sich so nicht wiederherstellen.

Ein Scrub-Befund unreparierter Beschädigung wird nicht nur für die nächste wöchentliche Prüfung vermerkt. Er wird direkt in eine Bewertung Nicht wiederherstellbar für jedes geschützte Objekt umgesetzt, dessen Snapshots das beschädigte Pack tatsächlich nutzen.

Was „zurücklesen“ tatsächlich prüft

Der Zurücklese-Pfad ist keine verkürzte Kopie des Restore-Codes. Er ist der Restore-Code: derselbe Chunk-Index-Abruf, derselbe Pack-Abruf mit Ausweichen auf eine Kopie, dieselbe AES-256-GCM-Entschlüsselung, die auch ein echter Restore durchführt. Jeder Chunk wird zweifach adressiert: Die in seinem eigenen Header versiegelte ID und die aus dem entschlüsselten Inhalt neu berechnete ID müssen beide mit dem im Manifest genannten Wert übereinstimmen. Das erkennt einen Chunk, der zwar sauber entschlüsselt, aber tatsächlich der falsche ist, nicht nur einen, der gar nicht entschlüsselt. Zum Schluss werden, sofern das Manifest einen SHA-256 des gesamten Objekts enthält, dessen Größe und ein frisch berechneter SHA-256 damit verglichen; ältere Einträge von vor Einführung dieses Felds liefern not_recorded und erhalten nur die oben beschriebenen Chunk-Prüfungen, ohne diesen zusätzlichen Gesamtobjekt-Vergleich. Ein Element kommt zurück als verifiziert, abweichend (die Bytes weichen vom Manifest ab), fehlend (seine Chunks stehen nicht im Chunk-Index) oder unlesbar (ein Pack ließ sich nicht abrufen, parsen oder entschlüsseln).

Jede Prüfung wird gegen den genauen Snapshot erfasst, den sie gelesen hat, nicht gegen das Objekt allgemein. Das hat eine direkte Konsequenz, die es wert ist, klar ausgesprochen zu werden: Eine Sicherung, die nach einer bestandenen Prüfung entstanden ist, ist selbst noch nicht geprüft, bis eine Prüfung genau diesen Snapshot zurückliest, unabhängig davon, wie eine frühere Sicherung bewertet wurde.

Das Ergebnis lesen

Bewertung	Bedeutung
Bereit	Jedes Element der Stichprobe der letzten Sicherung kam byte-genau zurück, und diese Sicherung ist aktuell.
Achtung	Wiederherstellbar, aber etwas braucht einen Blick: Die letzte Sicherung ist 48 Stunden oder älter, der Snapshot enthielt nichts, was geprüft werden konnte, oder eine Test-Wiederherstellung lief, wurde vom Ziel aber nicht bestätigt (sobald Test-Wiederherstellungen angebunden sind).
Nicht wiederherstellbar	Ein Restore dieses Objekts würde heute scheitern oder unvollständig ausfallen: Manifest nicht lesbar, Elemente der Stichprobe kamen fehlend, unlesbar oder abweichend zurück, ein Scrub fand den zugrunde liegenden Speicher beschädigt und nicht repariert, eine Test-Wiederherstellung scheiterte (sobald Test-Wiederherstellungen angebunden sind), oder die letzte Sicherung ist so alt (7 Tage oder mehr), dass aktuelle Daten nicht wiederhergestellt werden könnten.
Nicht geprüft	Eine Sicherung existiert, aber noch keine Prüfung hat diese Sicherung zurückgelesen.
Noch keine Sicherung	Es gibt nichts zu prüfen.

Jede Bewertung trägt ihre konkreten Gründe (welche Elemente, wie viele, wie alt die Sicherung ist). Öffnen Sie den Bericht des Objekts, um genau zu sehen, was geprüft wurde und was, falls überhaupt, nicht stimmte, statt sich nur auf die Farbe zu verlassen.

Server und Clients

Server und Clients, die der Restow-Agent sichert (Endpoint-Backup), fließen in dieselbe Übersicht und in die Zusammenfassung des Mandanten ein, in einem Abschnitt Server und Clients, mit denselben Bewertungen. Die Regel ist dieselbe wie bei Postfächern: Eine Bewertung gehört zu der Sicherung, die sie geprüft hat.

Noch keine Sicherung: Es gibt noch keine gute Sicherung.
Nicht geprüft: Eine Sicherung existiert, aber noch kein Restore-Test hat genau diese Sicherung zurückgelesen. Ein bestandener Test einer älteren Sicherung zählt nicht.
Bereit: Der Restore-Test der neuesten Sicherung wurde bestanden.
Achtung: Der Test wurde bestanden, aber die Sicherung war teilweise (einige Dateien waren nicht lesbar).
Nicht wiederherstellbar: Ein Restore-Test der neuesten Sicherung ist fehlgeschlagen, oder eine neuere Repository-Prüfung hat Schäden gefunden.

Nach jeder erfolgreichen Sicherung wählt der Agent bis zu 20 zufällige reguläre Dateien (keine größer als 256 MiB) und meldet Pfad, Größe und SHA-256-Hash. Der Hash muss der des Inhalts im Snapshot sein, nicht der der lebenden Datei. So kann eine Datei, die sich zwischen Sicherung und Hash ändert, den Test nicht fälschlich rot färben. Der Server liest diese Dateien dann mit restic aus dem Repository zurück, bildet den Hash und vergleicht. Eine Bewertung ist nur grün, wenn jeder Hash passt und mindestens eine Datei geprüft wurde. Der Agent stellt dieselben Dateien außerdem in einen temporären Ordner auf dem Rechner wieder her und vergleicht sie erneut; scheitert eine der beiden Seiten, ist der Rechner rot. Eine Bewertung, die älter als 8 Tage ist, gilt als überfällig. Eine wöchentliche Repository-Prüfung liest ein Zwanzigstel der gespeicherten Daten und färbt den Rechner rot, wenn sie Schäden findet.

Was das noch nicht beweist

Die Wiederherstellbarkeits-Prüfung bestätigt, dass eine Zufallsstichprobe des letzten Sicherungsstands intakt zurückgelesen wird und über den echten Restore-Pfad korrekt entschlüsselt; der getrennte Scrub-Job prüft unabhängig von einer einzelnen Sicherung Pack-Hashes über den gesamten gespeicherten Datenbestand, stichprobenartig oder vollständig. Sie beweist noch nicht, dass das Schreiben dieser Daten in ein lebendes Postfach, OneDrive oder IMAP-Konto heute tatsächlich gelingt: Berechtigungen, API-Änderungen und Drosselung auf Microsoft- oder IMAP-Seite sind nicht Teil der automatisierten Prüfung.

Eine Test-Wiederherstellungs-Sonde: die geprüfte Stichprobe in ein echtes Test-Postfach oder -Laufwerk wiederherstellen (im selben nicht-destruktiven, umbenennungssicheren Modus wie jeder andere Restore in ein anderes Konto) und prüfen, ob das Ziel jedes Element bestätigt, existiert als Design im Restore-Prüfungscode von Restow, ist im aktuellen Release aber nicht angeschlossen: Noch liefert nichts ein echtes Ziel dafür, sodass eine Prüfung heute nur das interne Zurücklesen durchführt. Die Anbindung an ein echtes Ziel ist geplant; bis dahin ist selbst von Hand eine Wiederherstellung durchzuführen von Zeit zu Zeit der nächstliegende Ende-zu-Ende-Beweis, den es heute gibt.

Weiterlesen

Backup und Restore: was gesichert wird und wie Restore selbst funktioniert.
Backups und Zeitpläne: Verifizierung und Speicherprüfung auf einen Zeitplan legen.
Backup vs. Archiv: Sicherungsstände, Aufbewahrung, und wie sich Backup vom Archiv unterscheidet.