Restic-Repository-Wartungsworkflow: Prüfen, Bereinigen, Komprimieren und Wiederherstellung testen

Der sichere Ansatz besteht darin, Gate-Zeitpläne, Integritätsprüfungen, die Vorschau der Aufbewahrung, das Bereinigen für das Neupacken, eine erneute Prüfung und eine isolierte Wiederherstellung als eine Abfolge beobachtbarer Prüfungen zu behandeln, nicht als einen einzelnen Befehl.

Bei einem Restic-Repository, das von einem oder mehreren Home-Server-Hosts verwendet wird, besteht das praktische Risiko darin, ein Restic-Repository instand halten zu müssen, ohne Backups zu blockieren oder die Rückgewinnung von Speicherplatz mit Wiederherstellbarkeit zu verwechseln. Erfassen Sie die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungskriterium, interpretieren Sie erfolgreiche und fehlgeschlagene Ergebnisse, bevor Sie eine weitere Variable ändern, und halten Sie an, sobald der Speicher instabil wird oder die einzige wiederherstellbare Kopie gefährdet wäre. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wurde oder die Beweislage eine Eskalationsgrenze erreicht.

Ein repositoryweites Wartungsfenster öffnen

Pausieren Sie auf jedem Host, der auf das Repository zugreifen kann, die Zeitpläne für Backup, Forget, Check, Copy und Prune. Bestätigen Sie, dass kein aktiver Lock-Besitzer mehr vorhanden ist, speichern Sie die Restic-Version und die Repository-ID und testen Sie die Zugangsdaten, ohne sie in der Shell-History oder in Protokollen offenzulegen. Die Repository-Wartung ist eine gemeinsame Zustandsänderung und keine Aufgabe pro Container.

Wenn ein vorheriger Absturz einen Lock hinterlassen hat, befolgen Sie vor dem Entsperren den ZimaSpace-Workflow für ein gesperrtes Restic-Repository nach einem Absturz. Ein Lock ist ein Hinweis auf einen Besitzer; entfernen Sie ihn erst, nachdem der genannte Prozess, der Host, die Zeitstempel und die Backend-Aktivität zeigen, dass der Vorgang beendet ist.

Prüfen Sie den freien Speicherplatz im Backend, Inodes oder Objektlimits, Schreibberechtigungen sowie lokalen Cache- oder temporären Speicherplatz. Halten Sie an, wenn der Speicherpfad instabil ist, unveränderliche Aufbewahrungsregeln die erforderliche Löschung verhindern oder ein anderer Schreiber nicht pausiert werden kann.

Struktur prüfen und Repository-Daten stichprobenartig lesen

Führen Sie restic snapshots und eine normale restic check-Prüfung aus und speichern Sie Ausgabe und Exit-Status. Planen Sie anschließend --read-data oder unterstützte Teilmengen für das Lesen von Daten entsprechend der Repository-Größe und Bandbreite ein. Ein erfolgreicher Strukturcheck beweist nicht, dass jedes Pack lesbar ist.

Eine Diskussion in der Restic-Community unterscheidet die routinemäßigen Rollen von Check, Prune und Rebuild-Index und erklärt, dass das erneute Erstellen des Index keine normale vorbeugende Wartung ist. Führen Sie Rebuild-Index nicht aus und löschen Sie keine Pack-Dateien, nur weil eine Prüfung langsam ist; reservieren Sie Wiederherstellungsbefehle für eine diagnostizierte Inkonsistenz.

Wenn Check fehlende Packs, eine Hash-Abweichung, einen Lesefehler im Backend oder eine Inkonsistenz im Index meldet, halten Sie vor Prune an. Schützen Sie das Repository, wiederholen Sie nur den fehlgeschlagenen Lesevorgang über einen stabilen Pfad und eskalieren Sie zur dokumentierten Wiederherstellung auf einer Kopie.

Aufbewahrung in der Vorschau anzeigen, dann bereinigen und neu packen

Führen Sie die vorgesehene restic forget-Richtlinie mit --dry-run aus und prüfen Sie die beibehaltenen und entfernten Snapshots nach Host, Pfad und Tags. Übernehmen Sie Forget erst, wenn die Liste die erforderlichen Wiederherstellungspunkte bewahrt. Bewahren Sie nach Möglichkeit einen kürzlich verifizierten Snapshot außerhalb einer experimentellen Richtlinienänderung auf.

In Restic ist „Compact“ kein separater Befehl: prune entfernt nicht referenzierte Daten und packt Repository-Dateien bei Bedarf neu. Ein aktueller Leitfaden zur Fehlerbehebung beschreibt Fehler bei Restic Prune, darunter Fehler durch freien Speicherplatz und Locks, die vor einem weiteren destruktiven Versuch behoben werden sollten.

Führen Sie Prune einmal ohne parallele Backups aus und bewahren Sie das vollständige Protokoll auf. Falls der Vorgang fehlschlägt, wiederholen Sie ihn nicht blind und löschen Sie keine scheinbar temporären Objekte. Prüfen Sie erneut Locks, freien Arbeitsbereich, Backend-Berechtigungen und die zuletzt abgeschlossene Phase; bewahren Sie den Repository-Zustand zur Diagnose auf.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Erneut prüfen und eine isolierte Wiederherstellung durchführen

Führen Sie nach einem erfolgreichen Prune erneut restic check aus und schließen Sie die geplante Abdeckung durch das Lesen der Daten ab. Vergleichen Sie Snapshot-Anzahl, Repository-Größe und Fehler mit der Ausgangsbasis vor der Wartung. Wenn der Speicherplatz nicht um den geschätzten Wert sinkt, ist das kein Fehler, solange beibehaltene Snapshots weiterhin auf die Daten verweisen.

Stellen Sie einen aktuellen Snapshot sowie eine ältere repräsentative Teilmenge in ein leeres Verzeichnis wieder her. Überprüfen Sie Dateiinhalte, Berechtigungen, Zeitstempel, symbolische Links und ein Artefakt auf Anwendungsebene. Eine Mount- oder Listenoperation allein ist kein Wiederherstellungstest.

Setzen Sie die Zeitpläne erst fort, wenn die Prüfung nach Prune erfolgreich ist, die wiederhergestellten Daten verwendet werden können und ein neues kleines Backup erstellt und wiederhergestellt werden kann. Eskalieren Sie jede neue Beschädigung, jeden wiederholten Backend-Fehler oder jeden unvollständigen Prune, bevor mehrere Hosts wieder schreiben dürfen.