So entfernst du eine veraltete Restic-Sperre, ohne eine aktive Sicherung zu unterbrechen

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Clear a Stale Restic Lock Without Interrupting an Active Backup - Zima Store Online

Eine veraltete Restic-Sperre sollte erst gelöscht werden, wenn nachgewiesen ist, dass jeder aufgeführte Host und Prozess inaktiv ist. Die Behebung besteht in einer normalen Aufhebung einer veralteten Sperre, nicht in der erzwungenen Entfernung aller Sperren.

Wenn mehrere Heimserver ein Repository gemeinsam nutzen, kann eine alt wirkende Sperre zu einem langsamen Remote-Job, einem neu gestarteten Container oder einem Prozess gehören, dessen Uhrzeit von der des Rechners des Administrators abweicht. Halten Sie zunächst neue Zeitpläne an, speichern Sie die Sperrmetadaten, überprüfen Sie den genannten Host und jeden Wartungscontroller und verwenden Sie anschließend den standardmäßigen Bereinigungspfad. Wenn ein Besitzer nicht verifiziert werden kann, brechen Sie ab und bewahren Sie die Sperre auf.

Neue Jobs anhalten und jeden Sperrbesitzer identifizieren

Deaktivieren Sie die Timer, Cron-Einträge, Container-Zeitpläne und Orchestrierungsjobs, die Restic für das Repository starten können. Speichern Sie die aktuelle Sperrliste und die letzten Serviceprotokolle. Erfassen Sie für jede Sperre Host, Prozess-ID, Benutzer, Zeitstempel und ob sie exklusiv ist, und überprüfen Sie anschließend den genannten Prozess auf genau diesem Host.

Eine exklusive Repository-Prüfung kann andere Arbeiten blockieren, und eine unterbrochene Prüfungssperre kann wie eine aufgegebene Backup-Sperre aussehen, bis Vorgang und Besitzer einander zugeordnet wurden.

Wenn ein Prozess aktiv ist oder seine Protokolle fortgeschrieben werden, warten Sie oder beenden Sie ihn ordnungsgemäß über seinen Service-Manager. Wenn der Host nicht erreichbar ist, ist nicht nachgewiesen, dass die Sperre veraltet ist. Fahren Sie erst fort, wenn jeder relevante Prozess beendet ist, kein Scheduler ihn neu starten kann und keine Schreibvorgänge am Repository eingehen.

Bestätigen, dass die Sperre nicht nur aufgrund ihres Alters veraltet ist

Warten Sie ein kurzes Beobachtungsfenster ab und listen Sie die Sperren erneut auf. Ein veralteter Kandidat hat keinen aktiven Besitzer, keine fortschreitenden Protokolle, keine Aktualisierung und keine Schreibaktivität am Repository. Vergleichen Sie die Uhren und fragen Sie dasselbe Backend von einem anderen vertrauenswürdigen Client ab, wenn das Repository remote ist.

Ein vollständiger Restic-Repository-Workflow behandelt das Aufheben einer Sperre als einen administrativen Vorgang neben Backups, Prüfungen, Aufbewahrung und Wiederherstellungen; es ersetzt nicht die Feststellung, wer noch Besitzer des Repositorys ist.

Wenn die Sperre aktualisiert wird, sich ein Protokoll verändert oder Clients unterschiedliche Ansichten des Backends melden, brechen Sie ab. Wenn die Sperre unverändert bleibt und ihr Besitzer nachweislich beendet ist, fahren Sie fort. Das Alter unterstützt das Ergebnis, begründet es aber nicht; ein langsamer aktiver Vorgang kann älter sein, als der Administrator erwartet.

Zuerst die standardmäßige Bereinigung veralteter Sperren verwenden

Verwenden Sie das normale Aufhebungsverhalten von Restic, damit veraltete Sperren entfernt werden, während Sperren, die weiterhin als aktiv gelten, erhalten bleiben. Fügen Sie keine Option zum Entfernen aller Sperren hinzu und führen Sie den nächsten Befehl nicht ohne Sperrung aus. Speichern Sie die Befehlsausgabe und erstellen Sie unmittelbar danach eine frische Sperrliste.

Der standardmäßige Befehl zum Aufheben der Sperre ist ausdrücklich für veraltete Sperren vorgesehen, während die erzwungene Entfernung eine separate, risikoreichere Maßnahme ist, die nicht Teil der normalen Reparaturabfolge sein sollte.

Wenn der veraltete Eintrag verschwindet und keine aktive Sperre entfernt wird, fahren Sie mit der Validierung fort. Wenn eine aktive Sperre bestehen bleibt, respektieren Sie sie und kehren Sie zur Prüfung des Besitzers zurück. Wenn eine Sperre sofort wieder erscheint, hat ein Timer, Container oder Remote-Host einen Vorgang gestartet; deaktivieren Sie diese Quelle und wiederholen Sie das Aufheben der Sperre erst, wenn der neue Besitzer verstanden wurde.

-15% OFF

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

Single board computer zimaboard2

Das ursprüngliche Backup und den nächsten geplanten Lauf validieren

Führen Sie genau das blockierte Backup aus und erfassen Sie Start, Fortschritt, Exit-Status und den Lebenszyklus der Sperre. Bestätigen Sie, dass die Sperre während der Arbeit von Restic erscheint und nach einem sauberen Ende verschwindet. Listen Sie den neuen Snapshot auf und stellen Sie ein kleines Beispiel an einem separaten Speicherort wieder her, bevor Sie die Automatisierung wieder aktivieren.

Wenn sich das Repository schreibgeschützt verhält oder die Wartung unvollständig bleibt, behandeln Sie den Zustand nach einem unterbrochenen Prune-Vorgang getrennt von der Bereinigung veralteter Sperren.

Aktivieren Sie den normalen Zeitplan für einen Zyklus wieder. Die Reparatur ist erfolgreich, wenn beide Läufe abgeschlossen werden, ihre Sperren normal gelöscht werden und das wiederhergestellte Beispiel übereinstimmt. Eskalieren Sie den Vorgang, wenn eine veraltete Sperre nach einem sauberen Prozessende zurückkehrt, die Backend-Ansichten weiterhin nicht übereinstimmen oder die Ergebnisse von Repository-Prüfung und Wiederherstellung voneinander abweichen. Automatisieren Sie das erzwungene Aufheben von Sperren nicht als Lösung für wiederkehrende Probleme.