Warum stockt ein Restic-Backup, wenn ein anderer Host mit dem Bereinigen beginnt?

Die Sicherung bleibt normalerweise hängen, weil „Prune“ exklusiven Zugriff auf das gemeinsam genutzte Repository benötigt und der zweite Host den Zustand desselben Repositorys in diesem Moment nicht weiterverarbeiten kann.

In einer Heimnetzwerkumgebung mit mehreren Hosts ist der zeitliche Ablauf der beste erste Anhaltspunkt: Die Sicherung läuft zunächst normal, ein anderer Rechner startet „Prune“, und anschließend wartet die Sicherung oder meldet eine Sperre. Bestätigen Sie den Besitzer der Sperre und das aktive Wartungsprotokoll, bevor Sie etwas unternehmen. Lassen Sie „Prune“ abschließen oder beenden Sie den Vorgang kontrolliert auf dem Host, der ihn gestartet hat. Entfernen Sie niemals die Sperre vom wartenden Sicherungsclient.

Bestätigen, dass „Prune“ der genaue Auslöser ist

Speichern Sie das Protokoll der wartenden Sicherung sowie das Wartungsprotokoll des Hosts, auf dem „Prune“ ausgeführt wird, jeweils mit Zeitstempeln. Listen Sie die Repository-Sperren auf und gleichen Sie Host, Prozess und den exklusiven Status mit dem „Prune“-Job ab. Die Ursache gilt als bestätigt, wenn der Fortschritt der Sicherung stoppt, nachdem „Prune“ das Repository gesperrt hat, und nach der Freigabe der Sperre wieder einsetzt.

Betreiber, die ein Repository von mehreren Hosts aus verwenden, berichten von Sperrkonflikten während des Prune-Vorgangs, da die Wartungsoperation mit ansonsten unabhängigen Sicherungszeitplänen konkurriert.

Wenn die Sicherung bereits zuvor langsam war, der „Prune“-Host keine Sperre erhalten hat oder beide Protokolle bei einem Speicherfehler stoppen, erzwingen Sie diese Diagnose nicht. Überprüfen Sie die Verfügbarkeit des Backends, die Latenz und den Sicherungsprozess selbst. Die Erklärung mit der Prune-Sperre gilt nur, wenn Auslöser, Sperrenbesitzer und Zeitpunkt der Freigabe übereinstimmen.

Die exklusive Sperre als Sicherheitsgrenze behandeln

„Prune“ verändert den Speicher des Repositorys und benötigt daher während der Ausführung eine konsistente Ansicht. Die wartende Sicherung hängt nicht unbedingt im üblichen Sinn eines blockierten Prozesses; möglicherweise respektiert sie lediglich die Wartungssperre. Die erste Frage lautet daher, ob „Prune“ Fortschritte macht – nicht, wie die Sicherung die Sperre ignorieren kann.

Ein Design mit gemeinsam genutztem Repository benötigt einen einzigen Wartungsbesitzer, da repositoryweite Wartung jeden Client betrifft, selbst wenn die Quelldaten verschiedenen Hosts gehören.

Wenn die „Prune“-Protokolle fortschreiten und die Ein-/Ausgabe des Repositorys weiterläuft, lassen Sie die Sperre bestehen und warten Sie, bis der Job abgeschlossen ist. Wenn der Job tatsächlich feststeckt, beenden Sie ihn kontrolliert über den Host, der ihn besitzt, und warten Sie auf einen sauberen Abschluss. Das Entfernen der Sperre von einem anderen Client, während „Prune“ noch schreibt, verwandelt ein kontrolliertes Warten in eine unsichere Überschneidung.

Die wartende Sicherung wiederherstellen, ohne die Sperrung zu umgehen

Die am wenigsten invasive Lösung besteht darin, den Abschluss von „Prune“ abzuwarten. Wenn die Sicherung über eine begrenzte Wiederholungsrichtlinie verfügt, lassen Sie sie erneut versuchen, sobald die exklusive Sperre verschwunden ist. Wenn „Prune“ beendet werden muss, verwenden Sie den Dienstmanager oder Prozess-Supervisor auf dem zuständigen Host, warten Sie auf das Herunterfahren und bestätigen Sie anhand der Sperrliste, dass sich die Sperren geändert haben, bevor Sie die Sicherung neu starten.

Die Aufbewahrung kann auf einen Host begrenzt sein, die physische Rückgewinnung von Speicherplatz bleibt jedoch Arbeit am Repository. Eine hostbezogene Aufbewahrungsrichtlinie verhindert, dass die falschen Snapshots ausgewählt werden. Sie macht gleichzeitiges „Prune“ für voneinander unabhängige Sicherungsclients jedoch nicht sicher.

Wiederholen Sie die wartende Sicherung mit der normalen Sperrung. Wenn sie abgeschlossen wird, entspricht die Behebung der bestätigten Ursache. Wenn unmittelbar ein weiterer „Prune“-Vorgang startet, deaktivieren Sie den doppelten Wartungszeitplan. Wenn die Sicherung weiterhin ohne exklusive Sperre hängen bleibt, erhöhen Sie die Anzahl der Wiederholungen nicht weiter, sondern kehren Sie zur Diagnose von Backend, Netzwerk, Quellenscan oder Prozess zurück.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Die ursprüngliche Überschneidung erneut testen und die Grenze festlegen

Verwenden Sie ein kontrolliertes Zeitfenster mit vollständigen Protokollen. Starten Sie eine normale Sicherung, rufen Sie anschließend den geplanten Wartungscontroller auf und bestätigen Sie, dass keine unsichere Überschneidung entsteht. Wiederholen Sie den vorgesehenen Ablauf mit „Prune“ zuerst und überprüfen Sie, dass die Sicherung gemäß der konfigurierten Richtlinie wartet oder beendet wird und anschließend nach Freigabe der Sperre erfolgreich ist.

Wenn ein unterbrochener „Prune“-Vorgang das Repository in einen anderen Betriebszustand versetzt, folgen Sie der Diagnose für unterbrochenes Prune, anstatt jeden späteren Fehler als gewöhnlichen Sperrkonflikt zu behandeln.

Die Wiederherstellung ist erfolgreich, wenn die ursprüngliche Überschneidung vorhersehbar behandelt wird, die Sicherung anschließend abgeschlossen wird, „Prune“ sauber beendet wird und ein Beispiel-Snapshot wiederhergestellt werden kann. Eskalieren Sie den Fall, wenn die Sperre nie aktualisiert oder freigegeben wird, mehrere Hosts weiterhin Wartungsvorgänge starten oder eine Repository-Prüfung Schäden meldet. Diese Ergebnisse gehen über die einzelne Ursache eines laufenden „Prune“-Vorgangs hinaus.