Wie die Wiederherstellbarkeit geprüft wird, im Detail

Diese Seite ist für Betreiber, die genau wissen wollen, was eine grüne Bewertung beweist. Sie beschreibt die Umsetzung in Restow 0.1.0; die Quelldateien stehen am Ende. Die Übersicht in einfacher Sprache ist Wiederherstellbarkeit.

Zwei Regeln gelten überall:

• Eine Bewertung gehört zu einer Sicherung. Eine Prüfung hält fest, welchen Snapshot sie gelesen hat. Eine neuere Sicherung ist Nicht geprüft, bis eine Prüfung genau dieser Sicherung gelaufen ist, egal wie eine ältere abgeschnitten hat.
• Grün braucht ein Zurücklesen. Ein beendeter Sicherungsjob ist kein Bestehen. Erst Inhalt, der zurückgelesen wurde und zu dem passt, was die Sicherung damals festgehalten hat, macht eine Sicherung Bereit.

Postfächer, OneDrive und IMAP-Konten

Was eine Sicherung festhält

Eintrag	Verfahren	Wovon	Wo
Chunk-ID	HMAC-SHA-256 mit einem Schlüssel des Mandanten	der Klartext jedes inhaltsdefinierten Chunks	im Snapshot-Manifest und im Chunk-Index (PostgreSQL)
Versiegelter Chunk	AES-256-GCM mit dem Datenschlüssel des Mandanten; die Chunk-ID ist als GCM-Zusatzdaten in den versiegelten Kopf eingebunden	jeder Chunk	in einer Pack-Datei auf dem Speicherziel
Pack-Hash	SHA-256	die ganze Pack-Datei (Kopf, Chunks, Index, Fußteil); der Fußteil des Packs trägt denselben Hash	im Pack-Katalog (PostgreSQL), zusammen mit der Pack-Größe
Objekt-Hash	SHA-256	die zusammengesetzten Bytes jedes Elements (eine Mail, eine Datei, ein Kalender- oder Kontakteintrag)	im Manifest-Eintrag, zusammen mit der Größe und den Chunk-IDs in ihrer Reihenfolge
Manifest	AES-256-GCM, versiegelt mit dem Mandantenschlüssel	die Liste der Elemente eines Snapshots	auf dem Speicherziel

Die Restore-Prüfung

Jede Prüfung liest den neuesten abgeschlossenen Snapshot eines geschützten Objekts:

1. Manifest. Das versiegelte Manifest wird geladen und geöffnet. Kommt es zurück, lässt sich aber nicht dekodieren (beschädigt, oder ein Schlüssel, der es nicht öffnet), ist das Ergebnis Nicht wiederherstellbar (manifest_unreadable). Liefert der Speicher es gar nicht, ist die Prüfung nicht abgeschlossen (siehe Rot nur mit Beleg), auch bei einem „nicht gefunden“: Genau so antwortet ein geleertes oder nicht eingehängtes Speicherziel.
2. Stichprobe. Aus den Elementen, die Inhalt tragen, wird je Kategorie zufällig gezogen: standardmäßig 20 Mails, 20 Dateien, 5 Kalendereinträge und 5 Kontakte. Ordner, Platzhalter, ältere Dateiversionen und Teile aufgeteilter Nachrichten werden nicht gezogen: Sie sind leer oder über ihr übergeordnetes Element abgedeckt. Der Zufallswert (Seed) wird mit dem Ergebnis gespeichert. Eine angeforderte Stichprobengröße darf 1 bis 200 je Kategorie betragen; Kalender- und Kontakteinträge erhalten ein Viertel davon, aufgerundet. Eine Gesundheitsprüfung liest statt einer Stichprobe jedes infrage kommende Element.
3. Zurücklesen über den Restore-Pfad. Jedes Element wird mit demselben Code gelesen, den ein Restore nutzt: Nachschlagen im Chunk-Index, Laden des Packs mit Ausweichen auf ein Kopie-Ziel, Entschlüsseln mit AES-256-GCM. Jeder Chunk wird zweimal adressiert: Die im versiegelten Kopf eingebundene ID muss der ID im Manifest entsprechen (geprüft vor dem Entschlüsseln), und die aus dem entschlüsselten Klartext neu berechnete HMAC-ID ebenfalls. Ein Chunk, der sich sauber entschlüsseln lässt, aber der falsche ist, fällt hier auf.
4. Ganzes Element. Die Zahl der gelesenen Bytes muss der Größe im Manifest entsprechen, und ein frisch berechneter SHA-256 der Bytes dem Objekt-Hash im Manifest. Elemente, deren Manifest-Eintrag keinen Objekt-Hash trägt, werden als not_recorded markiert und stützen sich allein auf die Chunk-Prüfungen.
5. Beschädigter Speicher. Packs, die die letzte Speicherprüfung als beschädigt hinterlassen hat, werden für diesen Snapshot über den Chunk-Index nachgeschlagen. Nutzt der Snapshot eines davon, ist das Ergebnis rot (storage_corrupt), auch wenn die Stichprobe dieses Pack nicht berührt hat.

Jedes Element der Stichprobe endet mit einem dieser Zustände:

Zustand	Bedeutung
verified	jeder Chunk neu adressiert, Größe und Objekt-Hash stimmen
mismatch	die Bytes kamen zurück, weichen aber vom Manifest ab (Größe, Objekt-Hash oder ein Chunk, der nicht der ist, den seine ID nennt)
missing	Chunks, die das Manifest nennt, stehen nicht im Chunk-Index, oder ein Pack, von dem jedes Speicherziel geantwortet hat, dass es ihn nicht hat
unreadable	gespeicherte Daten, die sich nicht dekodieren lassen: ein beschädigtes Pack, oder ein Chunk, der die AES-GCM-Authentifizierung nicht besteht oder den sein Pack nicht enthält; der Bericht nennt die eingeordnete Ursache (zum Beispiel ein beschädigtes Pack oder ein Schlüssel, der die Daten nicht öffnet)

Ein Element, dessen Lesen aus einem anderen Grund scheiterte, erhält keinen Zustand: Es belegt nichts über die Sicherung und macht die Prüfung nicht abgeschlossen (siehe Rot nur mit Beleg).

Wie das Ergebnis bewertet wird

Die Bewertung ist der schwerste Grund, den die Prüfung gefunden hat:

Grund	Schwere	Wann
no_snapshot	rot	es gibt keine abgeschlossene Sicherung
manifest_unreadable	rot	das Manifest der neuesten Sicherung kam zurück, lässt sich aber nicht dekodieren
items_missing, items_unreadable, items_mismatched	rot	mindestens ein Element der Stichprobe kam fehlend, beschädigt oder abweichend zurück (die Zustände oben)
storage_corrupt	rot	der Snapshot nutzt ein Pack, das die Speicherprüfung ohne unversehrte Kopie als beschädigt fand
test_restore_failed	rot	ein Test-Restore in ein Ziel ist aus einem eingeordneten, dauerhaften Grund gescheitert (in 0.1.0 nicht angebunden, siehe unten)
snapshot_outdated	rot	die neueste Sicherung ist 7 Tage (168 Stunden) alt oder älter: neuere Daten gingen verloren. Ist das der einzige rote Grund, sagen die Glocke und die Alarm-Mail Sicherung zu alt, nicht Restore-Prüfung nicht bestanden
snapshot_stale	gelb	die neueste Sicherung ist 48 Stunden alt oder älter
nothing_to_verify	gelb	der Snapshot enthält nichts, was sich zurücklesen ließe
test_restore_unconfirmed	gelb	ein Test-Restore kam an, aber das Ziel hat ihn nicht bestätigt (in 0.1.0 nicht angebunden)

Kein Grund bedeutet grün: Jedes Element der Stichprobe kam unversehrt aus einer aktuellen Sicherung zurück. In der Oberfläche heißt grün Bereit, gelb Achtung, rot Nicht wiederherstellbar. Der Bericht jeder Prüfung nennt die Ursache jedes gescheiterten Elements.

Rot nur mit Beleg

Eine Prüfung bewertet nur dann rot, wenn belegt ist, dass die Sicherung selbst kaputt ist, nach derselben Regel wie bei Servern und Clients:

• Daten fehlen: ein Chunk, den der Chunk-Index nicht kennt, oder ein Pack, von dem jedes Speicherziel geantwortet hat, dass es ihn nicht hat (ein eindeutiges „nicht gefunden“, nie eine Zeitüberschreitung),
• Daten stimmen nicht: eine abweichende Größe oder ein abweichender SHA-256, oder ein Chunk, der nicht der ist, den seine ID nennt,
• gespeicherte Daten lassen sich nicht dekodieren: ein beschädigtes Pack, oder ein Chunk, der die AES-GCM-Authentifizierung nicht besteht.

Alles andere belegt nichts über die Sicherung: ein Netzwerkfehler, eine Zeitüberschreitung, eine 5xx-Antwort, Drosselung, eine zurückgesetzte Verbindung, ein DNS-Fehler und jeder Fehler, den Restow nicht kennt. Ein solcher Lesevorgang macht die Prüfung nicht abgeschlossen:

• Das Zurücklesen endet beim ersten solchen Lesevorgang, statt denselben Fehler für jedes weitere Element erneut abzuwarten.
• Die Prüfung schreibt keinen Bericht und lässt die letzte Prüfung des Objekts, wie sie war. Sie löst keine Benachrichtigung, kein verify.completed und kein job.failed aus.
• Der Job wird mit dem Backoff der Warteschlange wiederholt (drei weitere Versuche, ab zwei Minuten). Der letzte Versuch schließt den Job ohne Bewertung ab, und die nächste geplante Prüfung versucht es erneut.
• Der Verlauf und die Seite des Laufs zeigen die Prüfung als Nicht abgeschlossen, wird wiederholt, in neutralem Ton. Solange Versuche übrig sind, erklärt die Seite des Laufs auch die Ursache (zum Beispiel war der Speicher nicht erreichbar oder hat gedrosselt).

Ein Kopie-Ziel, das antwortet, dient der Prüfung auch dann, wenn das primäre Ziel nicht antwortet. Ein Beleg, der gefunden wurde, bevor der Speicher nicht mehr antwortete, ergibt trotzdem rot, ebenso ein Pack, das die Speicherprüfung als beschädigt fand (storage_corrupt). Eine Sicherung, die nur alt ist, ist kein solcher Beleg: Eine Prüfung einer alten Sicherung, die ihre Daten nicht lesen konnte, ist ebenfalls nicht abgeschlossen.

Wann sie läuft

• Wöchentlich, nach dem empfohlenen Prüfzeitplan: sonntags um 03:00 in der Zeitzone des Mandanten (Europe/Berlin, sofern nicht anders eingestellt).
• Nach jeder Sicherung, solange der Mandant einen aktiven Prüfzeitplan hat: Der neue Snapshot wird geprüft, sofern für dieses Objekt nicht schon eine Prüfung wartet oder läuft.
• Auf Anforderung: Jetzt prüfen für ein Objekt und Alle jetzt prüfen für den Mandanten auf der Seite Wiederherstellbarkeit.
• Vorrang in der Warteschlange: Restores vor Prüfungen, Prüfungen vor Sicherungen.

Eine Bewertung, die älter als 8 Tage ist, gilt als überfällig.

Der Test-Restore

Die Prüfung kann laut Entwurf die geprüfte Stichprobe zusätzlich in ein eigenes Testziel wiederherstellen und darauf warten, dass das Ziel jedes Element bestätigt (test_restore_failed, test_restore_unconfirmed). Ein gescheitertes Element zählt nur aus einem eingeordneten, dauerhaften Grund als rot (eine Berechtigung, ein fehlendes Postfach); Drosselung oder ein unbekannter Fehler machen die Prüfung nicht abgeschlossen. In 0.1.0 stellt niemand ein solches Ziel bereit: Prüfungen lesen nur intern zurück und stellen nicht in ein Microsoft-365-Postfach, ein OneDrive oder ein IMAP-Konto wieder her.

Die Speicherprüfung (Scrub)

Die Speicherprüfung betrachtet die Pack-Dateien selbst, unabhängig von einer einzelnen Sicherung:

• Stichprobe, wöchentlich (im empfohlenen Zeitplan samstags um 04:00): 5 Prozent der Packs des Mandanten, mindestens 16, zufällig gezogen, dazu jedes Pack, das eine frühere Prüfung als beschädigt hinterlassen oder markiert hat.
• Vollständig, monatlich (am 1., 05:00): jedes Pack.

Jedes ausgewählte Pack wird von jedem Speicherziel gelesen, das es halten sollte (dem primären und jeder Kopie), und mit dem verglichen, was PostgreSQL beim Schreiben festgehalten hat: der Größe, dem SHA-256 der ganzen Datei, einem gültigen Pack (Kopf, Index und Fußteil, geprüft beim Öffnen), dem im Kopf genannten Mandanten und einem Index, der noch jeden Chunk enthält, den der Chunk-Index dort verortet, an derselben Stelle und mit derselben Länge.

• Eine Kopie, die durchfällt, während ein anderes Ziel eine unversehrte Kopie hat, wird repariert: Die unversehrten Bytes werden unter demselben Schlüssel zurückgeschrieben und zur Bestätigung des SHA-256 erneut gelesen.
• Ein Pack ohne unversehrte Kopie ist beschädigt. Jedes geschützte Objekt, dessen aktive Snapshots es nutzen, erhält sofort einen roten Bericht (es wartet nicht auf die nächste Wochenprüfung), und eine Benachrichtigung geht raus.
• Als beschädigt markiert wird ein solches Pack nur, wenn kein Ziel mit einem Ein- oder Ausgabefehler scheiterte, also wenn der Schaden bewiesen ist und nicht nur ein Ziel unerreichbar war. Spätere Sicherungen deduplizieren dann nicht mehr gegen seine Chunks und schreiben unversehrte Kopien von allem, was die Quelle noch hat.

Vor dem Integritätsdurchlauf bringt derselbe Job jedes Kopie-Ziel auf den Stand des primären. Stichproben-Läufe vergleichen Kopien nach Größe, vollständige Läufe nach SHA-256.

Server und Clients (Endpoint-Backup)

Die Sicherung eines Rechners ist ein restic-Repository auf der Restow-Instanz. restic speichert seine Daten inhaltsadressiert (SHA-256 jedes Blobs) und verschlüsselt (AES-256 im Counter-Modus mit Poly1305-AES-Authentifizierung), siehe das Design-Dokument von restic.

Was der Agent festhält

Nach jeder erfolgreichen Sicherung wählt der Agent Stichprobendateien aus dem Snapshot: bis zu 80 zufällige reguläre Dateien als Kandidaten, keine größer als 256 MiB, insgesamt höchstens 1 GiB zu hashen. Er hasht einen Kandidaten auf der Platte nur, wenn die Datei nachweislich die ist, die der Snapshot gesehen hat: gleiche Größe wie im Snapshot, Änderungszeit höchstens zwei Sekunden neben der im Snapshot, und beides vor und nach dem Hashen unverändert. Bis zu 20 solcher Dateien meldet er mit Pfad, Größe und SHA-256; sie werden als Stichprobe der Sicherung gespeichert (90 Tage). Eine nach der Sicherung bearbeitete Datei wird übersprungen, statt mit einem Hash festgehalten zu werden, den die Sicherung nie hatte.

Der Restore-Test des Servers

Der Server testet jede neue gute Sicherung, die eine Stichprobe und noch keinen Test des Servers hat. Er liest jede Stichprobendatei mit restic dump aus dem Repository, führt sie durch SHA-256, ohne sie auf die Platte zu schreiben, und vergleicht den Hash mit dem, den der Agent gemeldet hat.

• Die kleinste Datei wird zuerst und allein gelesen, die übrigen zu viert. restic 0.19 kann einen neuen Cache-Ordner nicht aus mehreren Prozessen zugleich anlegen: Ein Prozess schreibt die Versionsdatei des Ordners, während ein anderer sie noch leer liest und aufgibt (“unable to open cache: readVersion”). Dadurch scheiterte der erste Restore-Test eines neu angemeldeten Rechners zufällig. Hat ein Prozess den Ordner einmal angelegt, teilt restic ihn sicher.
• Grün: Jede Stichprobendatei stimmte überein, und mindestens eine Datei wurde getestet.
• Rot braucht einen Beleg: ein abweichender Hash, oder restic beendet das Lesen mit Exit-Code 1 und als letzter Zeile einem schweren Fehler, der die Sicherung selbst betrifft: Die Datei steht nicht im Snapshot, ein data-, index- oder snapshot-Objekt existiert nicht, ein Objekt fehlt im Repository, die Prüfung des Chiffrats ist gescheitert, oder es kamen ungültige Daten zurück. Frühere Warnzeilen zählen nicht, nur der Fehler, mit dem restic aufgegeben hat.
• Alles andere ist unvollständig, nicht rot: das Repository beschäftigt oder gesperrt, restic durch ein Signal beendet, abgestürzt, nicht startbar, Zeitüberschreitung, Repository nicht erreichbar, oder ein falsches Passwort oder ein fehlendes Repository (das bewertet die Repository-Prüfung). Der Job schreibt dann keinen Bericht und scheitert mit RestoreTestIncompleteError; die Warteschlange wiederholt ihn (dreimal, ab 2 Minuten mit wachsendem Abstand), und der Scheduler bietet ihn jede Stunde wieder an, bis ein Test vollständig läuft. Bis dahin bleibt der Rechner Nicht geprüft. Ein gescheiterter Lesevorgang zählt nie als Übereinstimmung.
• Der Test teilt sich das Repository mit dem Durchsuchen und mit Downloads und läuft nie neben der Aufbewahrung oder der Repository-Prüfung (eine Advisory-Sperre in PostgreSQL je Rechner). Ein Job, der die Sperre nicht binnen einer Minute bekommt, wird ohne Bewertung wiederholt.
• Ein Administrator kann einen Test auf der Seite des Rechners starten (Wiederherstellungstest starten).

Der eigene Restore-Test des Agenten

Nach einem bewerteten Test des Servers gibt der Server dieselben Dateien als verify_sample-Aufgabe an den Agenten (sieben Tage gültig). Der Agent stellt sie alle mit einem einzigen restic restore in einen temporären Ordner auf dem Rechner her, hasht jede Datei und löscht die Kopie. Er schickt kein Urteil, nur was er vorgefunden hat: je Datei den SHA-256 der hergestellten Kopie, missing, wenn unter dem Pfad nichts liegt, oder einen Fehler, wenn der Rechner die Datei nicht prüfen konnte (keine reguläre Datei, nicht lesbar); und, wenn restic restore scheiterte, den Exit-Code von restic, den Fehler, mit dem restic aufgegeben hat, und die Fehler, die restic zu einzelnen Elementen gemeldet hat. Der Server beurteilt den Bericht nach denselben Regeln wie seinen eigenen Test:

• Grün: Der Lauf war erfolgreich, und jede Datei kam mit ihrem Hash zurück.
• Rot braucht einen Beleg: ein abweichender Hash; eine Datei, die in der hergestellten Kopie fehlt, nachdem restic restore ohne Fehler endete (die Datei steht nicht im Snapshot); oder die eigenen Befunde von restic: restic endete mit Exit-Code 1, und entweder ist der Fehler, mit dem es aufgegeben hat, einer der beim Test des Servers genannten Befunde, oder es gab mit „There were N errors“ auf, der Agent hat alle N weitergegeben, und jedes gescheiterte Element hat mindestens einen solchen Befund unter seinen Fehlern. „Der Snapshot existiert nicht“ ist kein Beleg, wenn der getestete Snapshot nicht mehr die neueste Sicherung des Rechners ist: Die Aufbewahrung kann ihn entfernt haben.
• Alles andere ist unvollständig, nicht rot: zum Beispiel eine volle oder nicht beschreibbare Platte auf dem Rechner, ein Agent, der während des Tests angehalten oder neu gestartet wurde, ein beschäftigtes oder nicht erreichbares Repository, ein restic, das nicht starten konnte, eine Datei, die der Rechner nicht prüfen konnte, oder Befunde zusammen mit anderen Fehlern. Der Test bewertet dann nichts: kein Bericht, Letzter Wiederherstellungstest bleibt stehen, kein Alarm und kein job.failed. Der Rechner bekommt denselben Test nach 1, 2, 4, 8, 16 und 24 Stunden erneut, solange er nicht gesperrt ist, die getestete Sicherung seine neueste ist und noch kein Test dieser Sicherung wartet; danach bringt die nächste Sicherung einen neuen Test. Dasselbe gilt, wenn der Monitor einen Test schließt, dessen Agent sich sechs Stunden lang nicht gemeldet hat. Die Seite des Rechners zeigt einen solchen Test als Nicht abgeschlossen, wird wiederholt, in neutralem Ton mit seiner Ursache und mit dem Zeitpunkt, ab dem der nächste Versuch abgeholt wird.

Ein beurteiltes Ergebnis wird ein zweiter Bericht zum selben Snapshot (Herkunft agent), und ein roter Bericht einer der beiden Herkünfte macht den Rechner rot.

Die Repository-Prüfung

Einmal pro Woche führt der Server restic check --read-data-subset=n/20 auf dem Repository jedes Rechners aus: ein Zwanzigstel der gespeicherten Daten, der Abschnitt rückt mit der Kalenderwoche weiter, sodass das ganze Repository über 20 Wochen (etwa fünf Monate) zurückgelesen wird, ohne es je auf einmal ganz zu lesen. restic prüft dabei den Aufbau des Repositorys sowie Hashes und Authentifizierung der gelesenen Daten.

• Eine bestandene Prüfung schreibt einen grünen Bericht.
• Eine Prüfung, die nicht laufen konnte (Repository gesperrt, restic unterbrochen oder durch ein Signal beendet, restic nicht startbar), ist keine Prüfung: Es wird nichts berichtet, und sie wird erneut angeboten. Sechs gesperrte Versuche in Folge über mindestens zwölf Stunden lösen die Benachrichtigung endpoint.repository_locked aus.
• Jeder andere Fehler von restic schreibt einen roten Bericht mit der Meldung von restic.

Wie ein Rechner bewertet wird

Es zählt der neueste Restore-Test jeder Herkunft (Server, Agent) zur neuesten Sicherung des Rechners:

Zustand	Wann
Noch keine Sicherung	es gibt keine gute Sicherung
Nicht geprüft	eine Sicherung existiert, aber kein vollständiger Restore-Test genau dieser Sicherung
Bereit	die Restore-Tests der neuesten Sicherung sind grün
Achtung	grün, aber die Sicherung selbst war teilweise (einige Dateien ließen sich auf dem Rechner nicht lesen)
Nicht wiederherstellbar	ein Restore-Test der neuesten Sicherung ist rot, oder eine Repository-Prüfung, die neuer ist als der letzte Test, fand Schäden

Eine Bewertung, die älter als 8 Tage ist, gilt als überfällig.

Nachweisketten

Zwei Hash-Ketten machen spätere Änderungen an Aufzeichnungen sichtbar. Sie sind keine Restore-Prüfungen, gehören aber zu dem, was ein Bericht belegen kann:

• Audit-Log. Der Hash jedes Eintrags ist SHA-256 über den Hash des Vorgängers, die Felder des Eintrags als kanonisches JSON und seinen Zeitstempel, je eine Kette pro Mandant und eine für die Installation. Die Datenbankrollen der Anwendung können Einträge weder ändern noch löschen, und ein tägliches Siegel des letzten Eintrags jeder Kette macht eine abgeschnittene oder neu berechnete Kette erkennbar. Die Prüfung der Kette in der Oberfläche gehört zu Business und Service Provider; aufgezeichnet wird in jeder Edition.
• Archiv. Der Ketten-Hash jedes archivierten Elements ist SHA-256 über den Ketten-Hash des Vorgängers, den SHA-256 des archivierten Originals und den Empfangszeitpunkt. Die Archivseite prüft die Kette.

Wo Ergebnisse gespeichert und gezeigt werden

Was	Gespeichert in	Gezeigt
Restore-Prüfung eines Postfachs, OneDrive oder IMAP-Kontos	verify_reports (Bewertung, Snapshot-ID, Gründe, Zählungen, die Elemente der Stichprobe, der Seed, Dauer); der Job-Datensatz	Wiederherstellbarkeit (Tabelle, Bericht je Objekt), Übersicht (Reiter Status und Statistik), Verlauf
Speicherprüfung	der Job-Datensatz; eine rote Zeile in verify_reports je betroffenem Objekt	Wiederherstellbarkeit, Seite Repositories, Benachrichtigungen
Restore-Test und Repository-Prüfung eines Rechners	endpoint_reports (Art, Herkunft, Snapshot-ID, Bewertung, Zusammenfassung mit den abweichenden Dateien)	Wiederherstellbarkeit, die Seite des Rechners
Änderungen der Bewertung	Benachrichtigungen verify.red (lautet Sicherung zu alt, wenn der einzige rote Grund eine alte Sicherung ist), verify.yellow, verify.recovered; bei beschädigtem Speicher scrub.corrupt	die Glocke, Benachrichtigungsregeln (Mail, Webhook), das Zustellprotokoll
Jede bewertete Prüfung eines Postfachs (nicht eine, die nicht abgeschlossen werden konnte)	Webhook-Ereignis verify.completed	Ihr RMM oder PSA

Die Integrations-API meldet dieselben Zustände für die Automatisierung.

Eine Sicherung selbst prüfen

Die Prüfungen oben laufen in Restow. Um unabhängig von einem laufenden Restow-Server zu prüfen:

• Ohne Server und Datenbank: restow-restore verify liest einen Snapshot mit dem Master-Key (oder einem exportierten Schlüsselbund) aus dem Speicher und setzt ihn so zusammen wie ein Restore, ohne etwas zu schreiben: Jeder Chunk muss sich entschlüsseln lassen und die ID tragen, die das Manifest nennt, und jedes Element muss die Größe haben, die das Manifest festhält. restow-restore restore schreibt die Dateien aus. Siehe Restow selbst sichern und Releases prüfen.
• Das Repository eines Rechners: Öffnen Sie sein Repository-Passwort mit restow-restore endpoint-password (Master-Key und Speicher genügen) und nutzen Sie dann restic selbst, zum Beispiel restic check --read-data oder ein Restore in einen Testordner. Siehe Endpoint-Backup: Restore.
• Von Anfang bis Ende: Stellen Sie von Zeit zu Zeit ein Testpostfach, einen OneDrive-Ordner oder einen Ordner eines Rechners wieder her und sehen Sie sich das Ergebnis an. Die automatischen Prüfungen schreiben nicht in ein laufendes Postfach und nicht über vorhandene Dateien eines Rechners.

Grenzen

• Eine Stichprobe ist eine Stichprobe. 20 Mails eines großen Postfachs belegen, dass der Restore-Pfad und diese Mails funktionieren, nicht dass jede andere Mail es tut. Die Speicherprüfung ergänzt das, indem sie jeden Monat jedes Pack hasht; eine Gesundheitsprüfung liest auf Anforderung jedes Element.
• Die Prüfungen belegen, dass sich die Sicherung auf Ihrem Speicher unversehrt zurücklesen lässt. Sie belegen nicht, dass das Schreiben in ein laufendes Microsoft-365-Postfach, OneDrive oder IMAP-Konto heute gelingt; der Test-Restore ist in 0.1.0 nicht angebunden.
• Microsoft-365-Backup und -Restore liefen in den Release-Prüfungen noch nicht gegen einen echten Microsoft-365-Mandanten; sie sind durch Tests gegen eine simulierte Graph-API abgedeckt.
• Die Stichprobe eines Rechners umfasst Dateien, die während der Sicherung unverändert waren. Ob ein Datenbank-Dump oder eine geöffnete Datei konsistent ist, hängt von den Hooks ab, die sie vorbereiten.
• Ein Speicherziel, das mitten in einer Prüfung seine Einbindung verliert, nachdem das Manifest gelesen wurde, antwortet für die Datendateien „nicht gefunden“, und das zählt als fehlende Daten: Das Objekt wird rot bewertet. Ein Ziel, das schon vor der Prüfung nicht eingehängt ist, macht sie nicht abgeschlossen.
• Die Prüfungen erkennen Schäden, sie verhindern kein Löschen: Schützen Sie den Speicher selbst (siehe den Hinweis für Betreiber).

Umsetzung

Das Verhalten oben im Quellcode des Produkts (Repository restow-backup/restow):

• Restore-Prüfung der Postfächer: packages/core/src/verify/engine.ts, check.ts, evidence.ts (was als Beleg zählt), errors.ts (VerifyIncompleteError), sampling.ts, readiness.ts, report.ts; der Worker-Job apps/worker/src/handlers/verify.ts; die Regel, dass eine Bewertung zu ihrem Snapshot gehört, apps/api/src/features/verify/verification-state.ts.
• Chunks, Packs und Manifeste: packages/core/src/crypto.ts, chunkId.ts, pack.ts, manifest.ts, engine/chunkstore.ts (openChunkAs, RestoreIntegrityError).
• Speicherprüfung: packages/core/src/verify/scrub.ts, integrity.ts; der Worker-Job apps/worker/src/handlers/scrub.ts.
• Zeitpläne: packages/core/src/schedule/defaults.ts; Endpoint-Jobs apps/scheduler/src/endpoints.ts, Einstellungen der Warteschlangen packages/core/src/endpoints/queues.ts.
• Restore-Test der Endpunkte: packages/core/src/endpoints/restore-test.ts (restoreTestSamples, isBackupFinding, isRestoreFinding, judgeAgentRestoreTest), die Wartezeiten eines wiederholten Tests packages/core/src/endpoints/restore-test-retry.ts, der Job apps/worker/src/endpoints/verify.ts (RestoreTestIncompleteError), der Monitor apps/worker/src/endpoints/monitor.ts, die Stichprobe des Agenten agent/internal/core/sample.go, sein Test agent/internal/core/verify.go, sein Bericht apps/api/src/features/endpoints/agent-service.ts.
• Repository-Prüfung: apps/worker/src/endpoints/check.ts; Bewertung packages/core/src/endpoints/readiness.ts.
• Nachweisketten: packages/core/src/audit-chain.ts, packages/core/src/archive/chain.ts.
• Eigenständiges Werkzeug: packages/cli.