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, eine SharePoint-Website, 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).

Eine SharePoint-Website (seit 0.4.0) wird wie ein OneDrive geprüft: Die Stichprobe wird aus den Dateien ihrer Bibliotheken gezogen. Eine Microsoft-365-Gruppe (seit 0.4.5, Opt-in) wird wie ein Postfach geprüft: Die Stichprobe liest Beiträge ihrer Unterhaltungen und Ereignisse ihres Kalenders zurück.

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,
seit 0.4.2 gilt ein Pack, das ein Ziel 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 oder verweigerter Zugriff), nicht als beschädigt. Die Prüfung liest es zuerst bis zu dreimal ganz erneut und führt es dann unter Speicherintegrität als vorübergehend nicht lesbar auf, mit dem Fehler und der Zahl der Prüfungen in Folge, die es nicht lesen konnten.

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. Ein Pack, das nur im Moment nicht lesbar ist, bewertet die Objekte, die es nutzen, mit Achtung; Nicht wiederherstellbar werden sie erst, wenn ein Pack nachweislich beschädigt ist oder in 3 Prüfungen in Folge über mindestens 24 Stunden nicht gelesen werden konnte. Jede weitere Prüfung liest die markierten Packs zuerst, und Diese Packs erneut prüfen auf der Karte Speicherintegrität liest nur sie noch einmal. Lesen sich die Packs wieder intakt, endet der Befund, und die eigenen Restore-Prüfungen der Objekte bewerten sie wieder. Siehe Beschädigt oder vorübergehend nicht lesbar.

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; Einträge ohne ihn 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 kein Speicherziel hat das Pack) oder unlesbar (die gespeicherten Daten sind beschädigt: ein Pack oder Chunk, der sich nicht dekodieren lässt oder die Authentifizierung nicht besteht).

Scheitert ein Lesevorgang aus einem anderen Grund (der Speicher antwortet nicht, überschreitet die Zeit, liefert einen Serverfehler oder drosselt, oder ein Fehler, den niemand kennt), belegt das nichts über die Sicherung. Die Prüfung ist dann nicht abgeschlossen: Sie bewertet nichts, das Objekt behält sein letztes Ergebnis, kein Alarm geht hinaus, und die Prüfung wird noch dreimal wiederholt, beginnend zwei Minuten später, und erneut bei der nächsten geplanten Prüfung. Der Verlauf zeigt sie als „Nicht abgeschlossen, wird wiederholt“. Nur ein Beleg färbt eine Prüfung rot: Daten, die fehlen, nicht stimmen oder sich nicht dekodieren lassen. Die Einzelheiten stehen in Prüfung im Detail.

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, ein Pack davon ließ sich bei der letzten Speicherprüfung nicht lesen (ein Übertragungs- oder Berechtigungsfehler, seit 0.4.2), 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 beschädigt, Elemente der Stichprobe kamen fehlend, beschädigt (unlesbar) oder abweichend zurück, ein Scrub fand den zugrunde liegenden Speicher beschädigt und nicht repariert (oder ein Pack blieb in 3 Prüfungen in Folge über mindestens 24 Stunden nicht lesbar), eine Test-Wiederherstellung scheiterte aus einem dauerhaften Grund (sobald Test-Wiederherstellungen angebunden sind), oder die letzte Sicherung ist so alt (7 Tage oder mehr), dass aktuelle Daten nicht wiederhergestellt werden könnten. Ist das Alter der Sicherung der einzige Grund, sagen die Glocke und die Alarm-Mail „Sicherung zu alt“ statt „Restore-Prüfung nicht bestanden“.
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. Die beiden Gründe zum Alter gelten nicht für ein Objekt, das nicht mehr gesichert wird, siehe unten.

Objekte, die nicht mehr gesichert werden (seit 0.4.7)

Sagt die Quelle, dass ein Objekt weg, deaktiviert, unlizenziert oder gesperrt ist, hört Restow auf, es zu sichern (siehe Objekte, die nicht mehr gesichert werden). Die Aufbewahrung behält den neuesten Sicherungsstand eines solchen Objekts immer, deshalb bewertet die Wiederherstellbarkeit es anders:

Kein Alter. Nichts sichert es mehr, ein wachsendes Alter ist also kein Befund. Das Objekt wird nur danach bewertet, ob sich seine aufbewahrte Sicherung wiederherstellen lässt: Die Gründe „Die letzte Sicherung ist N Tage alt“ und „Sicherung zu alt“ gelten nicht mehr, es ist nie überfällig, und es wird nicht rot, nur weil Zeit vergeht. Eine aufbewahrte Sicherung, die sich nicht wiederherstellen lässt, bleibt rot. Die Tabelle sagt In der Quelle entfernt, Sicherungen bleiben für ein aus seiner Quelle entferntes Objekt und Nicht gesichert: Konto deaktiviert, Sicherungen bleiben, Nicht gesichert: keine Lizenz, Sicherungen bleiben oder Nicht gesichert: gesperrt, Sicherungen bleiben für eines, das noch an der Quelle steht. Dieselbe Bewertung gilt in der Statistik, der Objektliste, der Gesamtbereitschaft des Mandanten, der Integrations-API und der Benachrichtigung verify.completed.
Der Bericht sagt es. Der Bericht eines solchen Objekts beginnt mit einem Hinweis (Aus der Quelle entfernt oder Nicht gesichert: Konto deaktiviert, Nicht gesichert: keine Lizenz, Nicht gesichert: gesperrt) und führt das Alter der aufbewahrten Sicherung als Nicht gewertet: … statt unter den Befunden auf.
Noch eine Prüfung, dann nichts mehr. Ein Objekt, dessen neueste Sicherung nie geprüft wurde, bekommt noch eine Prüfung von der wöchentlichen Prüfung und von der Prüfung eines Jobs; danach wird nichts mehr für es geplant.
Warten auf eine Bestätigung hält den Mandanten von Grün ab. Ein Objekt, das nicht mehr gesichert wird und das keine Administration mit Ja, beabsichtigt bestätigt hat, zählt in der Zusammenfassung als N Objekte nicht mehr gesichert, bitte bestätigen und hält die Gesamtbereitschaft des Mandanten mindestens auf Achtung (gelb, nie rot). Die eigene Bewertung des Objekts ändert sich dadurch nicht: Eine rote Prüfung bleibt rot. Nach der Bestätigung zeigt es Absichtlich nicht mehr gesichert und hält die Bereitschaft nicht mehr zurück.

Die Liste der Berichte hat eine Grenze: Ein Filter auf die Bewertung trifft die gespeicherte Bewertung. Ein Bericht, der vor 0.4.7 oder noch an der Quelle gespeichert wurde, zählt das Alter der Sicherung, sodass ein solcher Bericht eines aus seiner Quelle entfernten Objekts unter Rot erscheinen kann, obwohl er grün zeigt. Prüfungen ab 0.4.7 speichern die Bewertung ohne das Alter. Der Verlauf der Bereitschaft früherer Tage zeigt das Gelb unbestätigter Objekte nicht, weil nur die aktuelle Bestätigung gespeichert wird, nicht, wann sie erteilt wurde.

Server und Clients

Server und Clients, die der Restow-Agent sichert (Endpoint-Backup), stehen auf der Seite Wiederherstellbarkeit in derselben Tabelle wie Postfächer, OneDrives und IMAP-Konten (gekennzeichnet zum Beispiel mit „Server · Linux“), mit denselben Bewertungen, und zählen in der Zusammenfassung darüber mit. 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 fand eine Datei, die abweicht oder im Repository fehlt oder beschädigt ist, oder eine neuere Repository-Prüfung hat Schäden gefunden. Ein Test, der nicht vollständig laufen konnte (Repository beschäftigt, restic nicht startbar oder Repository nicht erreichbar, eine volle Platte auf dem Rechner, ein während des Tests angehaltener Agent), bewertet nichts und löst keinen Alarm aus, und der Rechner bleibt Nicht geprüft, bis ein Test vollständig läuft. Den eigenen Test des Servers bietet der Scheduler stündlich erneut an; den Test auf dem Rechner bekommt der Rechner nach 1 bis 24 Stunden erneut (1, 2, 4, 8, 16 und 24), solange die getestete Sicherung seine neueste ist, auch wenn sich der Agent während des Tests sechs Stunden lang nicht gemeldet hat. Ein solcher Test erscheint als „Nicht abgeschlossen, wird wiederholt“.

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. Er hasht nur Dateien, die nachweislich unverändert sind, seit der Snapshot sie gesehen hat (gleiche Größe, gleiche Änderungszeit). So kann eine Datei, die sich nach der Sicherung ä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 meldet, was er vorgefunden hat; der Server beurteilt das nach denselben Regeln, und ein rotes Ergebnis einer der beiden Seiten färbt den 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. Jeder Hash, jede Stichprobengröße und jede Regel im Einzelnen: Prüfung im Detail.

Freigaben

Freigaben der Freigabe-Sicherung des Servers (seit 0.4.0) stehen auf der Seite Wiederherstellbarkeit in derselben Tabelle, eine Zeile je Freigabe, bewertet nach der Restore-Prüfung des neuesten Sicherungsstands der Freigabe. Die Regel ist dieselbe wie überall: Eine Bewertung gehört zu dem Sicherungsstand, den sie geprüft hat.

Jeder neue gute Sicherungsstand bekommt eine Restore-Prüfung. Während der Sicherung wählt der Runner bis zu 20 zufällige reguläre Dateien, nur Dateien, deren Änderungszeit mehr als eine Stunde vor dem Beginn des Laufs liegt und die sich beim Hashen nicht geändert haben, und meldet Pfad, Größe und SHA-256. Der Server liest genau diese Dateien mit restic aus dem Repository der Freigabe zurück, bildet den Hash und vergleicht. Grün braucht, dass jeder Hash passt und mindestens eine Datei geprüft wurde.
Eine wöchentliche Repository-Prüfung liest mit restic check 5 % der gespeicherten Daten der Freigabe und färbt die Freigabe rot, wenn sie Schäden findet.
Ein Sicherungsstand ohne Stichproben (jede Datei hat sich in der Stunde vor dem Lauf geändert) hat nichts zum Zurücklesen. Die Prüfung bewertet ihn mit Achtung und sagt, warum, löst keinen Alarm aus, und die nächste Sicherung nimmt Stichproben aus den Dateien, die unverändert bleiben. Ein Kopierjob zählt einen solchen Sicherungsstand nicht als geprüft.
Rot braucht einen Beleg, wie bei Servern: ein Hash, der abweicht, oder die Meldung von restic, dass die Daten der Sicherung selbst fehlen oder beschädigt sind. Eine Prüfung, die nicht vollständig laufen konnte, bewertet nichts und wird erneut angeboten.
Eine Bewertung, die älter als 8 Tage ist, gilt als überfällig.

Freigaben wurden in den Release-Prüfungen gegen Samba getestet, nicht gegen Windows Server, eine Synology- oder TrueNAS-Freigabe oder echte NFS-Exporte; was das heißt, steht auf den Seiten zu Freigaben.

Proxmox-VE-Gäste

VMs und Container von Proxmox VE (eine Preview, siehe Proxmox-VE-Backup) stehen auf der Seite Wiederherstellbarkeit in derselben Tabelle wie Postfächer, OneDrives, IMAP-Konten und Rechner, mit denselben Bewertungen, und zählen in der Zusammenfassung darüber mit. Jede Zeile zeigt die Art und die VMID mit dem Knoten, und Öffnen führt zur Seite des Gasts. Eine Bewertung gehört zu dem Sicherungsstand, den sie geprüft hat, wie überall sonst.

Noch keine Sicherung: Es gibt noch keinen Sicherungsstand. Die Zeile sagt „Keine Sicherung innerhalb von 24 Stunden, nachdem der Gast in einen Backup-Job kam“, sobald die erste Sicherung überfällig ist.
Nicht nachgewiesen (die Bewertung, die oben Nicht geprüft heißt): Ein Sicherungsstand existiert, aber seine Restore-Prüfung ist noch nicht gelaufen.
Bereit: Die Restore-Prüfung des neuesten Sicherungsstands hat jeden geprüften Block bestätigt und, wo es eine gibt, hat seine Startprüfung bestanden (siehe unten).
Nicht wiederherstellbar: Die Restore-Prüfung oder die Startprüfung des neuesten Sicherungsstands ist fehlgeschlagen: Blöcke stimmten nicht überein oder ließen sich nicht lesen, oder der Gast ist nicht gestartet.

Ein Gast, den eine Administration von der Sicherung ausgeschlossen hat (seit 0.4.7), zählt in den Übersichten, der Bereitschaft und den Warnungen nirgends als ungeschützt und hält den Mandanten nie von Grün ab. Seine Sicherungsstände bleiben wiederherstellbar, und die wöchentliche Restore-Prüfung seines neuesten Sicherungsstands läuft weiter. Siehe Einen Gast von der Sicherung ausschließen.

Achtung kommt bei Gästen auf zwei Wegen vor. Durch ihre Startprüfung: Die VM ist gestartet, aber ihr QEMU Guest Agent hat nicht geantwortet, was nicht beweist, dass das System funktioniert. Und seit 0.4.3, wenn die Restore-Prüfung des neuesten Sicherungsstands zwei Stunden lang nicht laufen konnte, weil ein anderer Vorgang die Sperre des Repositorys des Containers hielt (Nicht prüfbar: Repository gesperrt, oder Prüfung unterbrochen, wenn restic wiederholt gestoppt wurde): Über den Sicherungsstand ist noch nichts bekannt, er ist also weder Bereit noch Nicht wiederherstellbar. Die Zeile sagt, warum und wer die Sperre hält; Restow versucht es nach zehn Minuten erneut, entfernt veraltete Sperren selbst und versucht es nach einem Tag wieder. Siehe Restore-Prüfungen, die nicht laufen konnten. Ein Gast, der in keinem Backup-Job ist, aber noch einen Sicherungsstand hat, wird ebenfalls bewertet und trägt die Markierung In keinem Backup-Job; einer, der länger keine erfolgreiche Sicherung hatte, als seine Jobs vorsehen, trägt Überfällig.

Restow liest eine Stichprobe eines Sicherungsstands zurück: bei einer VM 8 Datenblöcke je Festplatte, verglichen mit der SHA-256 in der Blockkarte, bei einem Container ein restic check auf einer 5-%-Teilmenge seines Repositorys. Seit 0.4.2 wird jeder neue Sicherungsstand binnen Minuten nach seiner Sicherung geprüft (eine Einstellung der Installation unter Installation → Proxmox VE, standardmäßig eingeschaltet), und der neueste Sicherungsstand jedes Gasts wird außerdem mindestens wöchentlich geprüft. Jetzt prüfen bei einem Gast fordert eine Prüfung seines neuesten Sicherungsstands sofort an, Alle ungeprüften prüfen eine für den neuesten Sicherungsstand jedes Gasts, den noch keine Prüfung gelesen hat (seit 0.4.3 auch für die, deren Prüfung nicht laufen konnte), und Jetzt prüfen bei einem Sicherungsstand auf der Seite des Gasts prüft genau diesen. Eine eingereihte Prüfung sagt Prüfung eingereiht, und die Seite sagt, bei wie vielen Gästen die Wiederherstellbarkeit noch nicht nachgewiesen ist und wie viele Prüfungen auf den nächsten Durchlauf warten (alle fünf Minuten). Eine rote Prüfung zeigt den Fehler, den sie gefunden hat, zum Beispiel den von restic, statt nur „Blöcke stimmten nicht überein oder ließen sich nicht lesen“. Ein Job kann eine monatliche Wiederherstellung in den Pool restow-restore hinzufügen, die wieder gelöscht wird. Die Fußzeile nennt den Zeitplan für Microsoft 365 als solchen und sagt in einer eigenen Zeile, wie VMs und Container geprüft werden. Siehe Restore-Prüfungen.

Startprüfung (seit 0.4.0, standardmäßig aus). Ein Job kann außerdem den neuesten Sicherungsstand jedes Gasts starten, wöchentlich oder nach jeder Sicherung. Der Knoten des Gasts stellt ihn als neuen Gast im Pool restow-restore wieder her, trennt vor dem Start sein Netzwerk, startet ihn, wartet auf den QEMU Guest Agent (bei einem Container: auf seinen Init) und zerstört ihn in jedem Fall. Die Wiederherstellbarkeit bewertet den neuesten Sicherungsstand dann, wo es eine gibt, nach seiner Startprüfung: Bereit, wenn der Guest Agent geantwortet hat, Achtung, wenn eine VM nur gestartet ist, Nicht wiederherstellbar, wenn die Wiederherstellung, der Start oder der Boot fehlgeschlagen ist. Ein fehlgeschlagenes Zurücklesen hält ihn ebenfalls rot. Ohne Startprüfung entscheidet das Zurücklesen, wie bisher. Eine Startprüfung braucht restow-pve 0.4.0 oder neuer auf dem Knoten, läuft je Knoten nur eine zur Zeit und nie neben einer Sicherung und wurde gegen einen simulierten Proxmox-VE-Knoten getestet, noch nicht gegen einen echten Cluster. Siehe Startprüfungen. Siehe Backup-Jobs und Schutz und Inventar, Gäste und Sicherungsstände.

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.

Lesbar ist nicht dasselbe wie sauber

Ein Sicherungsstand kann Bereit sein und trotzdem verschlüsselte Dateien enthalten: Die Prüfung beweist, dass die Sicherung intakt zurückgelesen wird, nicht, dass das, was sie enthält, gesund ist. Seit 0.4.0 beurteilt die Ransomware-Erkennung jeden neuen Sicherungsstand auf Anzeichen von Ransomware und markiert verdächtige mit einem roten Kennzeichen Verdächtig, unabhängig von der Bewertung auf dieser Seite, und hält die Aufbewahrung des Objekts an, bis eine Administration den Befund klärt. Sie ist eine Heuristik, kein Virenscanner. Bei einem Repository mit unveränderbaren Backups hindert der Speicher zusätzlich daran, gesperrte Sicherungsstände zu löschen. Die Prüfungen auf dieser Seite erkennen Schäden; sie verhindern kein Löschen.

Weiterlesen

Prüfung im Detail: Hashes, Stichproben, Zeitpläne und Bewertungsregeln genau so, wie der Code sie anwendet, und wie Sie eine Sicherung selbst prüfen.
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.
Ransomware-Erkennung und Unveränderbare Backups: der Schutz vor Angriffen, den die Prüfungen auf dieser Seite nicht abdecken.