Warum verhält sich ein dedupliziertes Backup-Repository nach einem unterbrochenen Bereinigungsvorgang als schreibgeschützt?

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.

Why Does a Deduplicated Backup Repository Act Read-Only After an Interrupted Prune? - Zima Store Online

Ein Repository kann sich nach einem unterbrochenen Prune-Vorgang schreibgeschützt verhalten, wenn eine exklusive Sperre, ein Speicherfehler, ein unveränderliches Backend oder ein unvollständiger Wartungsstatus Änderungen verhindert.

„Schreibgeschützt“ kann die Sicherheitsreaktion des Backup-Clients sein und nicht dem tatsächlichen Einhängezustand des Dateisystems entsprechen. Ein abgebrochener Prune-Vorgang kann eine exklusive Sperre, nicht abgeschlossene Arbeiten an Pack-Dateien oder Indizes, unzureichenden temporären Speicher für die Bereinigung oder Backend-Operationen hinterlassen, die Lesezugriffe erlauben, Löschvorgänge jedoch ablehnen. Unabhängig davon kann das Betriebssystem das Repository-Dateisystem nach E/A- oder Konsistenzfehlern schreibgeschützt erneut einhängen. Ermitteln Sie, welche Ebene den ersten Schreibvorgang ablehnt, bevor Sie Sperren entfernen oder Prune erneut ausführen.

Ermitteln Sie den ersten Vorgang, der „schreibgeschützt“ meldet

Führen Sie einen Repository-Auflistungsbefehl und anschließend eine nicht destruktive Prüfung aus. Speichern Sie den ersten Fehler aus den Protokollen des Clients, Backends und Betriebssystems.

Die Restic-Dokumentation erklärt, dass Prune Repository-Daten neu schreibt und exklusiven Zugriff benötigt, da nicht referenzierte Inhalte entfernt und teilweise belegte Dateien neu gepackt werden können.

Wenn das Auflisten funktioniert, aber jeder Vorgang, der eine Sperre erstellt oder Metadaten schreibt, fehlschlägt, müssen Sie eine veraltete Sperre, fehlende Schreibberechtigungen im Backend und Objektaufbewahrung voneinander unterscheiden.

Prüfen Sie, ob der unterbrochene Prune-Vorgang eine exklusive Sperre hinterlassen hat

Listen Sie die Repository-Sperren über das Backup-Tool auf und ermitteln Sie für jede Sperre den Host, den Prozess, den Erstellungszeitpunkt und den Befehl, dem sie gehört.

Borg dokumentiert, dass Befehle zur Änderung des Repositorys Repository-Sperren verwenden, um gleichzeitige Schreibvorgänge zu verhindern, und warnt, dass das Aufheben einer aktiven Sperre den Repository-Status beschädigen kann.

Entfernen Sie eine veraltete Sperre ausschließlich über den dafür vorgesehenen Befehl und erst, nachdem Sie bestätigt haben, dass der zugehörige Prozess nicht mehr läuft.

Ermitteln Sie, ob das Dateisystem schreibgeschützt erneut eingehängt wurde

Prüfen Sie die Mount-Tabelle, das Kernel-Protokoll, den Zustand des Dateisystems und des Speicherpools sowie aktuelle Fehler an USB-, SATA-, Netzwerk- oder Controller-Komponenten.

Die Linux-Dokumentation zu ext4 führt errors=remount-ro als Sicherheitsrichtlinie auf und zeigt damit, wie ein Speicherfehler das Repository tatsächlich schreibgeschützt machen kann.

Erzwingen Sie kein erneutes Einhängen mit Schreibzugriff, solange Hardware- oder Dateisystemfehler weiterhin auftreten. Sichern Sie zunächst die Protokolle und reparieren Sie den Speicher.

-15% OFF

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

Single board computer zimaboard2

Untersuchen Sie den unvollständigen Status von Prune, Compact oder Index

Ermitteln Sie, welche Phase unterbrochen wurde: das Auswählen abgelaufener Snapshots, das Löschen von Referenzen, das erneute Packen von Daten, das Neuerstellen eines Index oder das Übernehmen von Metadaten.

Die Borg-Referenz zu Prune weist darauf hin, dass Prune und Compact separate Schritte sind. Daher können Archive weiterhin gültig sein, während die Speicherfreigabe noch nicht abgeschlossen ist.

Verwenden Sie vor einem weiteren destruktiven Durchlauf den Repository-Prüfbefehl. Löschen Sie niemals Pack-Dateien, Indizes oder Segmente manuell.

Prüfen Sie Objektsperren, Unveränderlichkeit und Backend-Anmeldedaten

Bei Cloud-Repositorys sollten Sie Objektaufbewahrung, rechtliche Sperren, Bucket-Richtlinien, Versionierung, Löschberechtigungen und die Rotation von Anmeldedaten prüfen.

AWS erklärt, dass S3 Object Lock das Löschen oder Überschreiben verhindert, solange eine geschützte Aufbewahrungsfrist gilt, sodass Lesezugriffe möglich bleiben, während Prune fehlschlägt.

Schwächen Sie die unveränderliche Aufbewahrung nicht nur ab, damit Prune erfolgreich beendet wird. Verwenden Sie ein vom Backup-Tool unterstütztes Repository-Design.

Prüfen Sie freien Speicher, Inodes und den Arbeitsbereich für Prune

Prüfen Sie die verfügbaren Bytes und Inodes des Dateisystems, Quoten, Snapshot-Reserven, temporäre Verzeichnisse, Limits des Objektspeichers und den verfügbaren Speicherplatz im lokalen Cache.

GNU Coreutils erklärt, dass df Blöcke und Inode-Nutzung anzeigen kann und damit ein volles Dateisystem von einer Repository-Sperre oder einem Berechtigungsfehler unterschieden werden kann.

Wenn das Dateisystem voll ist, schaffen Sie vorübergehend zusätzlichen Speicherplatz oder entfernen Sie andere, verifizierte Daten, anstatt Repository-Objekte zu löschen.

Führen Sie die Wiederherstellung mit Prüfung, Entsperren und einem kontrollierten Wartungsdurchlauf durch

Sichern Sie die zuletzt bekannten, erfolgreichen Wiederherstellungspunkte, stoppen Sie geplante Aufgaben, führen Sie eine unterstützte Prüfung durch, entfernen Sie nur eine nachweislich veraltete Sperre und starten Sie einen einzigen protokollierten Wartungsdurchlauf.

Der ZimaSpace-Leitfaden zur Wiederherstellung eines vollen Backup-Ziels enthält die entsprechende Grundregel: Behandeln Sie ein Repository als verwaltete Struktur und nicht als Sammlung unabhängiger Dateien.

Das Problem ist behoben, wenn Auflisten, Prüfen, Backup, Aufbewahrung und eine Testwiederherstellung ohne erzwungenes Entsperren oder manuelles Löschen erfolgreich funktionieren.

Häufig gestellte Fragen

Kann ich die Sperrdatei manuell löschen?

Nicht als ersten Schritt. Stellen Sie sicher, dass kein Prozess sie verwendet, und nutzen Sie die vom Backup-Tool unterstützte Funktion zum Entsperren.

Sollte ich Prune nach einem Absturz sofort erneut ausführen?

Nein. Überprüfen Sie zunächst den Zustand des Repositorys, des Index, des Dateisystems und des Backends, bevor Sie einen weiteren destruktiven Wartungsdurchlauf starten.

Bedeutet das schreibgeschützte Verhalten, dass die Backup-Daten sicher sind?

Nicht unbedingt. Fehlende Pack-Dateien, Speicherfehler, unveränderliche Objekte oder unvollständige Indizes können Wiederherstellungen weiterhin verhindern.