Checkliste zur Wiederherstellung von Btrfs-Metadaten für einen fast voll belegten Heimserver

Der sichere Ansatz besteht darin, Schreibvorgänge zu stabilisieren, Arbeitsbereich zurückzugewinnen, nur ein gefiltertes Balance auszuführen und die Daten vor dem normalen Betrieb zu überprüfen - und zwar als Folge beobachtbarer Prüfungen, nicht als einzelnen Befehl.

Bei einem nahezu vollen Btrfs-Dateisystem auf einem Home-Server besteht das praktische Risiko darin, dass Btrfs ENOSPC meldet oder schreibgeschützt wird, sobald der Metadatenbereich erschöpft ist. Erfassen Sie zunächst die aktuelle Identität und den Wiederherstellungspunkt, beginnen Sie mit dem am wenigsten invasiven Unterscheidungsschritt, werten Sie Pass- und Fehlermeldungen aus, bevor Sie eine weitere Variable ändern, und stoppen Sie, sobald der Speicher instabil wird oder nur noch die einzige wiederherstellbare Kopie offengelegt wäre. Der folgende Ablauf endet erst, wenn die ursprüngliche Arbeitslast erfolgreich ausgeführt wird oder die Belege eine Eskalationsgrenze erreichen.

Stabilisieren Sie das Dateisystem vor einem Reparaturversuch

Stoppen Sie Container, Downloads, Snapshots und protokollintensive Aufgaben, die in das betroffene Dateisystem schreiben. Speichern Sie Kernel-Fehler und die Ausgabe von btrfs device stats an einem anderen Ort. Wenn das Dateisystem schreibgeschützt erneut eingebunden wurde oder Prüfsummen-, Parent-Transid- oder E/A-Fehler meldet, lassen Sie es schreibgeschützt, bis Sie über eine wiederherstellbare Kopie verfügen.

Beginnen Sie nicht mit btrfs check --repair, einem vollständigen Balance, einer Defragmentierung oder massenhaftem Löschen. Die unmittelbare Frage ist, ob dem gültigen Dateisystemzustand lediglich Zuweisungsarbeitsbereich fehlt oder ob Speicherfehler Metadaten beschädigen. Ein reparaturorientiertes Vorgehen kann diese Unterscheidung erschweren und den verbleibenden Speicher verbrauchen.

Die Sicherheitsprüfung ist bestanden, wenn schreibintensive Dienste gestoppt sind, wichtige Daten eine weitere Kopie besitzen und Sie wissen, welches Blockgerät und welcher Einhängepunkt untersucht werden. Leiten Sie eine Wiederherstellungs-Imaging-Strategie ein, wenn das Gerät zurückgesetzt wird, verschwindet oder sich Lesefehler ansammeln.

Lesen Sie die Zuweisung statt der pauschalen Zahl zum freien Speicher

Führen Sie btrfs filesystem usage -T /mount, btrfs filesystem df /mount und btrfs device usage /mount aus und prüfen Sie aktuelle Kernel-Meldungen. Vergleichen Sie den zugewiesenen und den belegten Metadatenbereich sowie den auf jedem Gerät verfügbaren nicht zugewiesenen Speicher. Das gewöhnliche df allein zeigt nicht, ob Btrfs einen weiteren Metadaten-Chunk zuweisen kann.

Ein gezieltes Balance benötigt vollständig ungenutzten Arbeitsbereich. Ein ausführlicher Leitfaden zum gezielten Btrfs-Balance erklärt, dass ein ungefiltertes Balance alle geeigneten Blockgruppen neu schreibt und dass das Ziel darin besteht, nicht zugewiesenen Speicher auf Geräteebene aufrechtzuerhalten - nicht lediglich eine große Datei zu löschen und anzunehmen, dass Metadaten wachsen können.

Wenn der Metadatenbereich stark belegt ist, aber nicht zugewiesener Speicher verbleibt, kann ein kleines gefiltertes Balance leere oder wenig belegte Chunks zurückgewinnen. Wenn kein Gerät über Arbeitsbereich verfügt, entfernen Sie zunächst sicher entbehrliche Daten oder Snapshots in kleinen Paketen oder fügen Sie ein temporäres, für das Dateisystemprofil geeignetes Gerät hinzu. Starten Sie keine Verschiebung, die nicht abgeschlossen werden kann.

Gewinnen Sie mit der am wenigsten invasiven Maßnahme Arbeitsbereich zurück

Beginnen Sie mit dem Löschen entbehrlicher Dateien, die nicht von Snapshots erhalten werden, und löschen Sie anschließend nur bestätigte, nicht benötigte Snapshots. Synchronisieren Sie und prüfen Sie die Auslastung nach jeder kleinen Änderung erneut. Wenn ein Balance gerechtfertigt ist, beginnen Sie mit btrfs balance start -dusage=0 -musage=0 /mount oder einem anderen engen Filter, der anhand der beobachteten Zuweisung ausgewählt wurde, nicht mit einem vollständigen Balance.

Die Linux-Handbuchbeschreibung des Verhaltens eines gefilterten Balance weist darauf hin, dass Filter die Verschiebung begrenzen und ENOSPC auftreten kann, wenn dem Balance selbst Arbeitsbereich fehlt. Beobachten Sie btrfs balance status und die Kernel-Protokolle. Wenn die Verschiebung die Fehlerzahl erhöht, mit Gerätefehlern ins Stocken gerät oder den letzten Sicherheitspuffer verbraucht, brechen Sie sie ab und kehren Sie zur schreibgeschützten Wiederherstellung zurück.

Stapeln Sie Filter und Löschvorgänge nicht, ohne zwischen den Schritten zu messen. Der Wiederherstellungszweig ist erfolgreich, wenn der Metadatenbereich über ausreichenden Spielraum verfügt, auf den erforderlichen Geräten nicht zugewiesener Speicher vorhanden ist und ein kleiner Schreibvorgang ohne neues ENOSPC oder ein erzwungenes Zurücksetzen auf schreibgeschützt abgeschlossen wird.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Überprüfen Sie die Daten und verhindern Sie einen sofortigen Rückfall

Starten Sie nur einen Dienst mit geringem Risiko neu und reproduzieren Sie die Arbeitslast, die den Metadatenbereich ursprünglich gefüllt hat, etwa das Erstellen eines Snapshots oder viele kleine Dateiänderungen. Prüfen Sie die Auslastung und die Kernel-Protokolle nach der Arbeitslast und nach einem Neustart erneut. Ein Einhängen, das einmal funktioniert, aber unter normaler Änderungsaktivität wieder schreibgeschützt wird, ist keine Wiederherstellung.

Verwenden Sie die ZimaSpace-Methode zur Unterscheidung, ob Snapshots oder Live-Dateien NAS-Speicher belegen, bevor Sie die Aufbewahrung ändern. Von Snapshots gehaltene Extents können dazu führen, dass ein Löschen wirkungslos erscheint, während die Änderungsaktivität vieler kleiner Live-Dateien den Metadatendruck hoch halten kann. Die richtige Richtlinie hängt davon ab, welchen Zustand die Messungen belegen.

Nehmen Sie den normalen Betrieb erst wieder auf, wenn das Dateisystem schreibfähig bleibt, die Gerätestatistiken nicht weiter ansteigen, eine repräsentative Datei korrekt wiederhergestellt oder gehasht werden kann und die Überwachung alarmiert, bevor derselbe Puffer erneut verschwindet. Eskalieren Sie anhaltende strukturelle Fehler an einen Btrfs-Wiederherstellungsspezialisten und arbeiten Sie von einem Klon statt erneut Reparaturbefehle auf der einzigen Kopie auszuführen.