it-swarm.com.de

Wie stelle ich eine BTRFS-Partition wieder her, die nicht eingehängt werden kann?

Die Installation für 12.04 schlug weiterhin fehl und die Lösung bestand darin, dass das Installationsprogramm die btrfs-Partition ignorierte, die ich zuvor für/home verwendet hatte.

Nun, da es installiert ist, habe ich versucht, es zum Mounten der btrfs-Partition zu bringen, damit ich auf meine 70 GB Dateien zugreifen kann. Es wird nicht eingebunden, und btrfsck-Fehler werden mit den folgenden drei Zeilen ausgegeben:

parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456

Kann mir bitte jemand sagen, wie diese Partition funktioniert? Ich habe online gelesen, dass ich die Daten wahrscheinlich mit btrfs-restore wiederherstellen kann, aber ich kann das Programm nirgendwo finden.

10
Tony

Einfachster Weg

btrfs-zero-log /dev/sda5

Sie erhalten dieses Problem, weil eine Transaktion (Schreiben oder Löschen) im Journalprotokoll steckt und der Datenträger nicht damit übereinstimmt.

Wie es funktioniert:

Wenn also Daten zuerst in das Journal geschrieben werden, dann auf die Festplatte (oder zur gleichen Zeit, aber das Journal speichert nur Metadaten über das bevorstehende Schreiben - ich bin mir nicht sicher ... brauche mehr Nachforschungen zu diesem Teil) ...

Wie auch immer, wenn Sie das System während dieses Schreibens/Löschens ausschalten oder etwas unternehmen, das das System stört (trennen Sie den USB-Stick, der Ihren btrfs-Mount-Punkt enthält), dann schlägt der Mount fehl, wenn er zurückgegeben wird (dmesg und btrfsck zeigen Ihnen die Fehler genauer an) ...

Wenn Sie auf dmesg schauen, werden Sie dieselben Transid-Nachrichten sehen.

Sie werden so etwas sehen:

parent transid verify failed on 109973766144 wanted 1823 found 1821

Dies bedeutet, dass btrfs Transif 1826 wollte (das war im Journal), aber auf der Platte sah es 1821. Die Platte war also 2 Transaktionen von der Synchronisation mit dem Journal entfernt. Ich persönlich würde hier ein brtfs-zero-log riskieren, nur weil es nur 2 Transaktionen sind. Aber um 100% sicher zu sein, wenn dies Ihre einzigen Daten sind (übrigens, wenn Sie kritische Daten haben, sollten Sie NIEMALS nur eine Kopie davon haben, sondern immer eine Kopie/ein Backup an einem sicheren anderen Ort - und den Erstellern von btrfs die Schuld geben Begründen Sie dies mit der mangelnden Verantwortung der Personen, kein Backup zu haben - btrfs ist keine Backup-Lösung, es ist ein Dateisystem - nichts ist eine echte Backup-Lösung, außer eine Kopie davon, wo - nicht einmal Parität oder gespiegelte Laufwerke - ein echtes Backup ist irgendwo unter der Erde in den Alpen sitzen, während sich die aktive Kopie in Ihrem Büro in Texas befindet)

parent transid verify failed on 31302336512 wanted 62455 found 62456

Hier will das Tagebuch 62455, aber der Datenträger hat bei 62456 einen Vorsprung. In Ihrem Fall würde ich das Tagebuch also einfach löschen. Das Journal wurde dieses Mal nicht aktualisiert. Wieder sagte ich Ihnen, dass Sie sicher sein sollten, wenn es Ihre einzigen Daten sind und es sehr kritisch ist (Schande für Sie), und ich würde die folgenden Operationen zuerst durchführen, um sicher zu sein.

Wenn Sie ein btrfsck/dev/sda5 ausführen (das übrigens nur eine Readonly-Prüfung durchführt, um die Sicherheit zu gewährleisten, werden Ihnen auch die einzigen btrfsck-Optionen angezeigt, über die Sie sich Sorgen machen müssen).

Aber Vorsicht, wenn diese Daten kritisch sind, würde ich zuerst tun (wie die anderen Herren sagten)

mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

Dann cp oder rsync alle Ihre Dateien an einen sicheren Ort, dann, wenn es sicher ist, machen Sie das btrfs-zero-log, wenn es ein erfolgreicher Vorgang ist, haben Sie gerade viel Zeit damit verschwendet, Ihr System zu sichern (aber wenn es nicht erfolgreich ist, haben Sie gerade Ihr Log gespeichert) Arsch)

Wenn die Mounts fehlgeschlagen sind, führen Sie eine BTRFS-Wiederherstellung durch (Speicherauszug des Systems, wie ich verstehe, ist es ein wiederaufsetzbarer Vorgang, der jedoch immer wieder nach Y oder y fragt, also beobachten Sie die Ausgabe).

btrfs restore /dev/sda5 /USB

Wenn Sie sicher sind (wenn die Wiederherstellung von btrfs abgeschlossen ist), führen Sie das Protokoll btrfs-zero aus. Wenn die Operation erfolgreich war, haben Sie nur viel Zeit mit dem Sichern Ihres Systems verschwendet. Wenn sie nicht erfolgreich ist, haben Sie nur Ihren Arsch gerettet.

Sie können zuerst screen ausführen

screen /bin/bash

btrfs restore /dev/sda5 /USB

BILDSCHIRM SEITLICHER HINWEIS

Zum Trennen (Befehl wird weiterhin ausgeführt): STRG-a, dann ": Trennen" ohne Anführungszeichen eingeben und dann die EINGABETASTE drücken

Eine andere Möglichkeit zum Trennen: Wenn Sie PuTTY oder Ihr Terminal schließen, wird die Verbindung getrennt (der Befehl/die Wiederherstellung wird weiterhin ausgeführt).

Um es zu überprüfen, gehen Sie einfach zurück zum Bildschirm:

screen -x

screen -x wird an Sitzungen angehängt, auch wenn es nicht verbunden ist, und anders als -h sagt, wird es angehängt, auch wenn es bereits verbunden ist.

Wenn Sie über mehrere Bildschirme verfügen, gibt screen -x an, dass Sie spezifischer vorgehen müssen, um eine Verbindung zur Sitzung herzustellen:

screen -ls

wenn Sie alle Sitzungen auflisten möchten, können Sie sich das leicht merken.

um die PID zu sehen, können Sie auch Folgendes tun:

ps aux | grep screen

Sobald Sie Ihre PID herausgefunden haben, führen Sie den folgenden Bildschirm aus:

screen -x PID

Das hängt mit einer bestimmten Sitzung zusammen. Sie können mehrere Sessions/Puttys an denselben Bildschirm anhängen (sie geben denselben Text aus, Sie können Befehle in einen eingeben und sie werden auf den anderen PuTTY gespiegelt).

8
kossboss

Mounten beim Booten mit root-fs-Mount-Optionen:

rootflags=recovery,nospace_cache

oder

rootflags=recovery,nospace_cache,clear_cache

Die vollständige Liste der btrfs-Mount-Optionen sollte hier sein https://btrfs.wiki.kernel.org/index.php/Mount_options und andere Dinge können ebenfalls nützlich sein, wie noatime, nodatacow (behoben a Kernel-Fehler für mich, der mir die Möglichkeit gibt, meine Dateien zu kopieren).

Fügen Sie es zu grub.cfg/menu.lst hinzu oder geben Sie es beim Booten ein.

Das nospace_cache-Zeug wird die Dinge furchtbar langsam machen. Einfach hochfahren, warten (lang), herunterfahren und normal hochfahren.

Ich hatte vor ein paar Tagen dasselbe und das oben Genannte hat es behoben. Aber auch danach gab es einige Platzprobleme ... der gemeldete Platz ist nicht 100%, aber es kann immer noch gesagt werden, dass nicht genügend Platz vorhanden ist.

==

Ich denke, Sie können die gleichen Optionen auch in Ihre fstab einfügen, zum Beispiel:

UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,[email protected] 0  
 2

Wenn Sie versucht haben, ein über eine Partition eingehängtes/home-Verzeichnis mit UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf wiederherzustellen.

7
Peter

Ich hatte das gleiche problem Nach einem Neustart konnte ich meine btrfs-Partition nicht mehr mounten. Keine der hier genannten Lösungen konnte es jedoch lösen.

Das Problem wurde behoben, indem der Kernel von 3.10 auf 3.12 aktualisiert wurde. Nach einem Neustart konnte die btrfs-Partition erneut gemountet werden.

1
Fabian Jakobs
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3

ro = schreibgeschützt

Diese Arbeit für mich

1
Dan

Peters Antwort löste das Problem für mich, obwohl nicht auf Ubuntu. Ich hatte eine /home Partition, die natürlich beschädigt wurde. Das System konnte nicht gestartet werden, da es sich in fstab befand. Ich habe den Wartungsmodus aufgerufen, die Zeile mit dieser Partition gelöscht und normal gebootet (ich hatte eine freie ext4-Partition, die ich als /home verwenden konnte).

Ich habe die Partition manuell mit dem folgenden Befehl gemountet:

mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3 und konnte meine Daten tatsächlich speichern. Obwohl es nicht lange gedauert hat, es zu montieren. Also DANKE Peter.

1
Nikos