Restic-Repository nach einem Absturz gesperrt: Ursachen, Prüfungen und Lösungen

Ein Restic-Repository kann gesperrt bleiben, weil ein anderer Prozess noch aktiv ist, ein Absturz veralteten Zustand hinterlassen hat, das Backend Aktualisierungen verzögert oder eine Wartung weiterhin eine exklusive Sperre hält.

Bei einem Home-Server mit mehreren Hosts ist die Annahme gefährlich, dass der letzte sichtbare Absturz die einzige Sperre verursacht hat. Möglicherweise läuft noch ein Prune-Job auf einem anderen Host, ein Container wurde mit demselben Zeitplan neu gestartet oder der Objektspeicher zeigt den neuesten Zustand noch nicht an. Frieren Sie zunächst neue Zeitpläne ein und lesen Sie die Identität der Sperre aus. Entfernen Sie eine Sperre erst, wenn Host, Prozess, Zeitpunkt und Repository-Aktivität eindeutig auf einen beendeten Vorgang hindeuten.

Lesen Sie die Sperridentität, bevor Sie handeln

Pausieren Sie auf jedem Rechner, der auf das Repository zugreifen kann, neue Zeitpläne für Backup, Forget, Check und Prune. Listen Sie die Sperren auf und speichern Sie Host, Prozess-ID, Benutzer, Erstellungszeitpunkt, Aktualisierungszeitpunkt sowie die Rolle als exklusive oder nicht exklusive Sperre. Prüfen Sie anschließend den zugehörigen Prozess und die Serviceprotokolle auf dem angegebenen Host, anstatt allein anhand des Alters zu raten.

Veraltete Sperren entstehen häufig nach einem unterbrochenen Restic-Prozess, aber eine unterbrochene Pipeline ist nur eine mögliche Ursache. Ein Prozess, der ein unsauberes Signal empfängt, kann einen Zustand hinterlassen, der einem weiterhin laufenden Remote-Job ähnelt.

Wenn die PID aktiv ist und die Protokolle fortlaufend aktualisiert werden, warten Sie oder beenden Sie den Job über den Service-Manager. Entsperren Sie nicht, während er noch läuft. Wenn der Prozess nicht vorhanden ist und der Host denselben Job nicht neu gestartet hat, wird die Sperre zu einem Kandidaten für eine veraltete Sperre. Ist der Host nicht erreichbar oder die Ansicht des Backends inkonsistent, bleibt der Status ungeprüft; eine destruktive Aktion ist dann nicht gerechtfertigt.

Unterscheiden Sie die vier Sperrsignaturen

Ein aktiver Schreibprozess hat einen passenden Prozess, aktuelle Protokollaktivität und eine Sperre, die aktualisiert wird. Ein unsauberes Beenden liegt vor, wenn kein aktiver Prozess existiert und der Zeitstempel der Sperre unverändert bleibt, nachdem der Host oder Container beendet wurde. Eine Verzögerung des Backends zeigt sich, wenn Clients unterschiedliche Sperrlisten anzeigen oder Zeitstempel hinter der bekannten Repository-Aktivität zurückbleiben. Eine nicht abgeschlossene Wartung zeigt sich durch eine exklusive Sperre und ein Check- oder Prune-Protokoll, das sich weiterhin verändert.

Eine umfassende Reihenfolge zur Restic-Fehlerbehebung hält Repository-Sperren, Prune-Fehler und mögliche Beschädigungen als getrennte Untersuchungszweige auseinander, damit eine Lösung für veraltete Sperren nicht auf ein Speicherproblem angewendet wird.

Prüfen Sie jeweils nur eine Signatur. Bestätigen Sie zuerst, ob der Prozess aktiv ist, vergleichen Sie anschließend Zeitstempel und Protokolle, prüfen Sie danach Backend-Erreichbarkeit und Uhrzeit und untersuchen Sie schließlich die Wartung. Wenn zwei Signaturen weiterhin plausibel sind, behalten Sie die Sperre bei und untersuchen Sie den sichereren Zweig. Das Entsperren ist kein Diagnosetest, da es den Schutz verändert, den Sie gerade verstehen wollen.

Löschen Sie nur nachweislich veraltete Sperren

Prüfen Sie vor dem Entsperren erneut jeden Client, jede Automatisierungssteuerung, jeden Container-Host und jeden Service auf Repository-Seite. Speichern Sie die aktuelle Sperrliste und die neuesten Protokolle. Verwenden Sie den normalen Befehl zum Entfernen veralteter Sperren, nicht eine Option zum Entfernen aller Sperren oder zum Deaktivieren von Sperren, da der Standardweg aktive Sperren bewusst beibehält.

Ein realer Fehler durch eine veraltete Sperre kann einen ansonsten etablierten Backup-Zeitplan stoppen. Das Alter eines einzelnen Falls legt jedoch keinen allgemein sicheren Schwellenwert für das Löschen fest.

Wenn der Standardbefehl den veralteten Eintrag entfernt und nicht sofort wieder eine Sperre erscheint, fahren Sie mit einer schreibgeschützten Repository-Auflistung fort. Wenn der Befehl die Entfernung verweigert, weil die Sperre aktiv ist, halten Sie an und ermitteln Sie den Besitzer. Erscheint sofort eine neue Sperre, läuft weiterhin ein Zeitplan oder ein neu gestarteter Container. Deaktivieren Sie diese Quelle, bevor Sie einen weiteren Reparaturversuch unternehmen.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Testen Sie den ursprünglichen Vorgang erneut und achten Sie auf ein Wiederauftreten

Führen Sie denselben fehlgeschlagenen Vorgang erneut aus und erfassen Sie dabei Fortschritt und Exit-Status. Beobachten Sie, wie die Sperre erscheint, während der aktive Job sie aktualisiert und sie nach einem sauberen Beenden verschwindet. Lassen Sie anschließend einen normalen geplanten Durchlauf zu. Dadurch wird der ursprüngliche Auslöser reproduziert und mehr nachgewiesen als durch eine erfolgreiche Repository-Auflistung.

Wenn das Repository nach dem Aufheben der Sperre schreibgeschützt wird oder die Wartung fehlschlägt, folgen Sie dem separaten Wiederherstellungsweg für ein unterbrochenes Prune, anstatt die Sperre wiederholt zu entfernen.

Die Wiederherstellung ist erfolgreich, wenn zwei Zyklen unter der ursprünglichen Last abgeschlossen werden, jede Sperre während der Aktivität aktualisiert und beim Beenden entfernt wird und eine Repository-Prüfung oder eine beispielhafte Wiederherstellung normal funktioniert. Leiten Sie den Fall weiter, wenn Sperren nach sauberen Beendigungen erneut auftreten, Clients unterschiedliche Backend-Zustände anzeigen oder die Prüfung fehlende oder beschädigte Repository-Objekte meldet. Lassen Sie die Sperrung während der gesamten Untersuchung aktiviert.