Meine Home-Partition auf einer Debian-Wheezy-Installation ist ein verschlüsseltes LVM-Volume. Es ist ext3. Heute früh hatte ich eine seltsame Meldung in einem Terminalfenster, dass ein Versuch, in eine Datei in meinem /homeBaum zu schreiben, fehlschlug, weil ich ein schreibgeschütztes Dateisystem habe. Ich habe neugestartet und bekam am Ende die Fehlermeldung /dev/sda1 is reported as clean. fsck.ext3, die automatisch ausgeführt wird und meldet, dass es kein solches Gerät gibt /dev/mapper/sda1_cryptund den Exitcode 8 meldet. Ich werde zu einer Wartungsshell weitergeleitet und mir wird mitgeteilt, dass versucht wurde, ein Protokoll in zu schreiben /var/log/fsck/checkfs.
In diesem Protokoll heißt es:
[Timestamp]
fsck from util-linux 2.20.1
/dev/mapper/sda1_crypt: Super blocks need_recovery flag is clear, but journal has data.
/dev/mapper/sda1_crypt: Run journal anyway
/dev/mapper/sda1_crypt: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
(i.e., without -a or -p options)
fsck died with exit status 4
Ich rannte
$ fsck -vnM /dev/mapper/sda1
Ein Haufen illegal block #nnnn (mmmmmmmmm) in inode ppppppp IGNOREDNachrichten flog vorbei, gefolgt von
too many blocks in Inode somenumberhere
Führen Sie dann zusätzliche Durchläufe aus, um Blöcke aufzulösen, die von mehr als einem Inode beansprucht werden.
Es gibt dann
Pass 1B: Rescanning for multiply claimed blocks
Nach einer Weile bekam ich eine Wand aus
Illegal block number passed to ext2fs_test_block_bitmap somenumberhere for multiply claimed block map
Darauf folgten 2 mehrfach beanspruchte Blöcke im I-Knoten anothernumber: [Listen mit 5 und 8 Blocknummern]
Dann bekam ich eine Reihe von Strophen wie
[ 3828.181915] ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 3828.182462] ata1.01 BMDMA stat 0x64
[ 3828.183810] ata1.01 failed command: READ DMA EXT
[ 3828.185889] ata1.01 cmd 25/00:08:08:10:9c/00:00:29:00:00/f0 tag dma 4096 in
[ 3828.185891] res 51/40:00:09:10:9c/40:00:29:00:00/f0 Emask 0x9 (media error)
[ 3828.190071] ata1.01 status: { DRDY ERR }
[ 3828.192153] ata1.01 status: { UNC }
Es folgten
[ 3830.509338] end_request: I/O error, deb SDA, sector 698093577
[ 3830.509841] Buffer I/O error on device dm-3, logical block 87261184
Error reading block 87261184 (Attempt to read block from filesystem resulted in short read) while reading I node and block bitmaps. Ignore error? no
fsck.ext3: Can't read an block bitmap while retrying to read bitmaps for /dev/mappersfa1_crypt
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
e2fsck: aborted
/dev/mapper/sda1_crypt: ******* WARNING: Filesystem still has errors *******
Und dann wurde der Vorgang mit der Warnung abgebrochen, dass das Dateisystem immer noch Fehler aufwies.
Meine Fragen sind:
Sind meine Daten ruiniert? (Ich habe meine strenge Datensicherungsrichtlinie in letzter Zeit nicht mehr strikt befolgt. Ich werde dafür mit Sicherheit vom Universum bestraft.)
Was kann/sollte ich jetzt tun?
Habe ich schon das Falsche getan?
Wird mich jemand festhalten, bis das Zittern aufhört?
BEARBEITEN
Ich habe auch auf meiner lokalen LUG-Mailingliste nachgefragt. Dort wurde mir geraten, mit ddrescue ein Image des Laufwerks zu erstellen und fsck auf einer Kopie dieses Images auszuführen. Das scheint vernünftig und wird die Dinge wahrscheinlich nicht verschlimmern. Das ist also der derzeitige Angriffsplan, bis bessere Vorschläge vorliegen.
Antwort1
Es klingt, als ob die Festplatte selbst Probleme hat („kurzer Lesevorgang“ usw.). Wenn das zutrifft, dmesg | tailwerden wahrscheinlich einige E/A-Fehler angezeigt.
Eine andere Möglichkeit, dies zu überprüfen, besteht darin, es auf der Problempartition auszuführen badblocks -n. Oder besser auf der gesamten Festplatte. Was auch immer Sie testen, es muss ausgehängt werden. Dies wird auf einer großen modernen Festplatte Stunden dauern. Wenn sich auf den Partitionen, die eingehängt werden, etwas befindet, ohne das Sie nicht leben können, kopieren Sie es zuerst auf Wechseldatenträger oder ein Netzwerkvolume.
Der Vorschlag, die Festplatte zu spiegeln, ist auch gut. Es ist eine Art „Light“-Version der badblocks -nPrüfung, denn indem die Festplatte gezwungen wird, jeden Sektor zu lesen, kann dies dazu führen, dass die Festplatte Problemblöcke verschiebt, wie badblocks -nes der Fall ist. badblocks -nist effektiver, da problematische Sektoren kaum lesbar sein können und der Festplatte nur dann als schlecht genug angezeigt werden, um verschoben zu werden, wenn versucht wird, auf sie zu schreiben. Wenn die Festplatte jedoch noch genug Leben hat, um eine Rettung zu überleben, wird der zusätzliche Lesedurchgang nicht ausreichen, um sie zu erledigen.
Ich habe nicht viel Hoffnung, dass das Ausführen fsckdes Disk-Images alles wiederherstellen wird. Sie werden bei diesem Vorgang mit ziemlicher Sicherheit Sektoren verlieren, was bedeutet, dass einige Dateien unlesbar oder unbrauchbar werden. Ein JPEG wird beispielsweise teilweise mit beschädigten Daten dekodiert, aber ein JPEG, bei dem die unteren ⅔ abgeschnitten sind, ist für Sie möglicherweise nicht von Nutzen.
Werden meine Daten geröstet?
Möglicherweise, möglicherweise auch nicht. badblocks -nManchmal kann der Versuch das Problem beheben. Wenn das der Fall ist, müssen Sie die Festplatte trotzdem austauschen, da eine Festplatte nur dann in einen so schlechten Zustand geraten kann, wenn sie beim Starten fast tot ist.
Habe ich schon das Falsche getan?
Abgesehen davon, dass ich die Bedeutung des Wortes „streng“ vergessen habe, nein. :)
Antwort2
Hoffentlich verfügen Sie über ein aktuelles Backup-Image, von dem Sie die Wiederherstellung durchführen können.
Ich würde JETZT eine begrenzte Sicherung von allem machen, was Sie behalten möchten, und dann prüfen, ob die Festplatte noch verwendbar ist. Ein Trick, den ich früher verwendet habe, war, das RAW-Partitionsgerät zu verwenden und es nach /dev/null zu dden.....mit einer entsprechenden Option würde ein Bereich identifiziert, der nicht gelesen werden konnte.