use debugfs!!!

Wenn man ein kaputtes Dateisystem hat, bzw. eine halb kaputte kaputte Festplatte und ein fehlschlägt: debugs verwenden!!!

Das Problem:
Ein -Dateisystem mit 1,5 TB auf einer Festplatte, die sich nicht mounten lässt, da die Festplatte etwas beschädigt ist. Die Platte wurde schon vor 6 Monaten aus dem Live-betrieb genommen, da Sie fehlerhaft war. Das Problem: Die Festplatte eines Desktop-PCs ging kaputt, dessen war früher auf der besagten kaputten Festplatte, das aktuelle gelöscht.
Blöde Situation!
Auf der besagten kaputten Festplatte ca. 20 GB Backup (welches extrem wichtig ist, da Steuererklärung und Buchführung etc.), ca 100 GB andere Backups und gut 1 TB Videos.

Ein fsck.ext3 direkt auf die Festplatte gestartet, bricht nach wenigen Sekunden ab, und die Festplatte wird mit fdisk -l nicht mehr angezeigt – reboot nötig. Dann ist mir aufgefallen, dass extundelete nicht direkt abbricht, sondern irgendwas von der Platte lesen kann. Der versuch, die Platte mit dd zu kopieren, war erstaunlicherweise erfolgreich. Nun also ein 1,5 TB großen image mit fsck prüfen. Beinahe unmöglich!
Das Problem hierbei ist fehlender Arbeitsspeicher. Ein Rechner mit 8 Kernen (AMD CPU) und 16 GB RAM und 8 GB Swap sollte das Image checken. Nach ca. 30-60 Minuten bricht es ab: “memory allocation failed”
Man googelt, schreibt

[scratch_files]
directory = /var/cache/e2fsck

in /etc/e2fsck.conf

Dann dauert der Check ewig!

Man löscht das also wieder raus und googelt nach alternativen. Swap adden! Verpasst man der Maschine also 500 GB Swap – kostet ja nix. Leider geht die Performance der ganzen Maschine ziemlich in die Knie, weil er nur noch mit swappen beschäftigt ist. ca 3 Tage dauert ein Durchlauf, das Ergebnis “memory allocation failed”

Die Idee: mehr Swap
Das Ergebnis: scheiße!

Mit 1TB Swap war die Maschine nicht mehr ansprechbar, als die Belegung im Swap über 50 % stieg. Nach 5 Tagen Ungewissheit und Krach durch den CPU-Lüfter, der Reset.

Also all den Swap wieder weg, nochmal mehrere Checks starten, da ein Check ja nach ca. 30-60 Minuten abbricht. Dann fiel mir auf, dass er immer beim gleichen Inode abbricht. Da liegt wohl ein Video :-) Also der Versuch, diesen Inode mittels zu löschen. Wie geht das? man debugfs

Da fällt mir doch ganz zufällig auf, das das ein verdammt mächtiges Tool ist und sogar Dateien Dumpen kann. Der versuch die Platte mit debugfs zu öffnen schläft fehl. in den Manpages steht doch glatt:

“ -c     Specifies  that  the file system should be opened in catastrophic mode, in which the inode and group bitmaps are not read initially.  This can be useful for filesystems with significant corruption, but because of this, catastrophic mode forces the filesystem to be opened read-only.”

Wie geil – ein catastrophic mode

Damit lässt sich die Platte tatsächlich öffnen! gleich ein ls eingegeben, schon listet er mir echt die Ordner auf! Wild mit cd reingewechselt, ls, cd, ls, cd, ls – schon sehe ich all die Dateien, die es zu retten gilt!
Nochmal die manpages auf, dump dateiname1 dateiname2 und boaahhh!

Er hat mir die Datei dateiname1 von der Kaputten Festplatte heile auf mein Lokales Dateisystem als dateiname2 abgespeichert.
Nochmal die manpages: rdump!
Die Lösung zusammengefasst:

debugfs -c /dev/sdg1
debugfs: rdump ordnername .

Dauert zwar einen Moment, sieht aber sehr vielversprechend aus!

Dieser Beitrag wurde unter Sonstiges, Storage abgelegt und mit , , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.