6
EXT4 Dateisystem komplett zusammengebrochen
Hallo, ich habe eine Frage zu ext4!
Ich habe eine Platte mit nur 16 defekten Sektoren auf einer Partition. Als ich merkte, dass die Platte ein Problem hat, habe ich die kurz weiterlaufen lassen und die wichtigsten Dinge noch schnell gesichert da ich unterwegs war und so keinen Zugriff auf mein Backup hatte.
Naja den Großteil habe ich noch runterbekommen bevor die Platte gar keine Dateien mehr angezeigt hat.
Wieder zu hause habe ich ein Image erstellt und das genauer angesehen - die erste Partition hat nur 16 defekte Sektoren einmal genau die ersten 8 Sektoren der Partition und dann 8 ein stück weiter drin.
Die zweite Partition hat 156 defekte Sektoren und ich konnte diese ganz normal vom Image lesen und bis auf ein paar Dateien sind alle OK.
Aber dennoch interessiert mich folgendes:
Wenn ich auf der Partition bzw. einem Image der Partition
aufrufe bekomme ich eine Liste der Backup-Superblocks, die Info, dass es sich um eine EXT4 Partition mit 4k Blocksize handelt und den letzten Mount-Zeitpunkt...
Ich habe alle diese Backup-Superblocks versucht, bekomme aber ca. 100.000 errors! Kein Witz - 70 bis 80 Sek. läuft nur Nummern-Gewirr über den Bildschirm wenn ich zB
aufrufe.
Wenn ich dann alle diese Fehler beheben lasse dann sind keine 20.000 Dateien auf der Partition und der Großteil davon in lost+found! Aber ein RAW-recovery findet ca. 216.000 Dateien, was ungefähr stimmen kann. Wenn ich r-Studio verwende dann findet dieses Programm 187.000 Dateien aber Großteils in Ordnern mit Namen wie $InodeJrnlXXXXXX.
Ich frage mich wie 16 Sektoren (8kb) soviel Schaden anrichten können und wie es sein kann, dass 156 defekte Sektoren auf einer anderen Partition kaum was ausmachen?
Ich habe eine Platte mit nur 16 defekten Sektoren auf einer Partition. Als ich merkte, dass die Platte ein Problem hat, habe ich die kurz weiterlaufen lassen und die wichtigsten Dinge noch schnell gesichert da ich unterwegs war und so keinen Zugriff auf mein Backup hatte.
Naja den Großteil habe ich noch runterbekommen bevor die Platte gar keine Dateien mehr angezeigt hat.
Wieder zu hause habe ich ein Image erstellt und das genauer angesehen - die erste Partition hat nur 16 defekte Sektoren einmal genau die ersten 8 Sektoren der Partition und dann 8 ein stück weiter drin.
Die zweite Partition hat 156 defekte Sektoren und ich konnte diese ganz normal vom Image lesen und bis auf ein paar Dateien sind alle OK.
Aber dennoch interessiert mich folgendes:
Wenn ich auf der Partition bzw. einem Image der Partition
mke2fs -n part_img.dd aufrufe bekomme ich eine Liste der Backup-Superblocks, die Info, dass es sich um eine EXT4 Partition mit 4k Blocksize handelt und den letzten Mount-Zeitpunkt...
Ich habe alle diese Backup-Superblocks versucht, bekomme aber ca. 100.000 errors! Kein Witz - 70 bis 80 Sek. läuft nur Nummern-Gewirr über den Bildschirm wenn ich zB
e2fsck -b 32768 part_img.dd aufrufe.
Wenn ich dann alle diese Fehler beheben lasse dann sind keine 20.000 Dateien auf der Partition und der Großteil davon in lost+found! Aber ein RAW-recovery findet ca. 216.000 Dateien, was ungefähr stimmen kann. Wenn ich r-Studio verwende dann findet dieses Programm 187.000 Dateien aber Großteils in Ordnern mit Namen wie $InodeJrnlXXXXXX.
Ich frage mich wie 16 Sektoren (8kb) soviel Schaden anrichten können und wie es sein kann, dass 156 defekte Sektoren auf einer anderen Partition kaum was ausmachen?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 504535
Url: https://administrator.de/contentid/504535
Ausgedruckt am: 13.11.2024 um 12:11 Uhr
6 Kommentare
Neuester Kommentar
Moin,
Wenn es die richtigen Sektoren trifft, kann man schon größtmöglichen Schaden anrichten.
Aber ein fsck ist nicht dazu da kaputte Sektoren zu reparieren, sondern ein durch OS oder Programme verhunztes filesystem wieder in einen konsistenten Zustand zu bringen. Dabei können durchaus Dateien veloren- oder kaputtgehen
Dadurch, daß Du die Kiste hast weiterlaufen lassen und dann noch durch fsck vermutlich hast kaputtreparieren lassen, hast Du nun diesen Datensalat.
Also Restore vom Backup und alles wird wieder gut.
lks
Wenn es die richtigen Sektoren trifft, kann man schon größtmöglichen Schaden anrichten.
Aber ein fsck ist nicht dazu da kaputte Sektoren zu reparieren, sondern ein durch OS oder Programme verhunztes filesystem wieder in einen konsistenten Zustand zu bringen. Dabei können durchaus Dateien veloren- oder kaputtgehen
Dadurch, daß Du die Kiste hast weiterlaufen lassen und dann noch durch fsck vermutlich hast kaputtreparieren lassen, hast Du nun diesen Datensalat.
Also Restore vom Backup und alles wird wieder gut.
lks
OK und was hätte man sonst machen können?
Ich meine das Image habe ich und zum Not sind ca. 1,5 Tage arbeit weg aber wenn es einen Trick gibt da aus dem Image noch was rauszuholen dann gern. Die 160GB hab ich in 20-25 Min. wieder aus dem Komplettimage rausgezogen.
Ich meine das Image habe ich und zum Not sind ca. 1,5 Tage arbeit weg aber wenn es einen Trick gibt da aus dem Image noch was rauszuholen dann gern. Die 160GB hab ich in 20-25 Min. wieder aus dem Komplettimage rausgezogen.
Bin Dir noch eine Antwort schuldig:
Vor irgendwelchen Reparaturversuchen als erste ein image mit ddrescue versuchen, was Du ja anscheinend gemacht hast.
Danach versuchen das filesystem mit alternativen Superblöcken zu mounten und schauen, ob man dann die Daten runterziehen kann. braucht u.u. mehrere Anläufe.
bevor man mit fsck dann an das "reparieren geht" soltle man aus den ddrescue-log die Liste der "kaputten" Blocks nehmen und diese beim fsck angeben oder mit badblocks ins filesystem eintragen lassen.
Erst danach kann man fsck auf das Image (besser Kopie davon) loslassen. Und man sollte nicht automatisiert einfach alles mit yes abnicken lassen sondern erstmal schauen, welche Fehler gemeldet werden und ggf. das ganz manuell durchgehen. Ist natürlich sisyphus-Arbeit und wird schlecht bezahlt.
Und natürlich gibt es für solche Fälle ja auch forensische Tools und Distributionen, die man darauf dann loslassen kann, je nachdem, wie wichtig die Daten sind. manche Leute schreiben sich spezielle Tools dafür sogar selbst für den konkreten Einzelfall. Habe ich in meiner Jugend zwar auch gemacht, aber die Zeiten sind lange rum. Heute schicke ich das einfach zum Datenretter, falls notwendig.
lks
Vor irgendwelchen Reparaturversuchen als erste ein image mit ddrescue versuchen, was Du ja anscheinend gemacht hast.
Danach versuchen das filesystem mit alternativen Superblöcken zu mounten und schauen, ob man dann die Daten runterziehen kann. braucht u.u. mehrere Anläufe.
bevor man mit fsck dann an das "reparieren geht" soltle man aus den ddrescue-log die Liste der "kaputten" Blocks nehmen und diese beim fsck angeben oder mit badblocks ins filesystem eintragen lassen.
Erst danach kann man fsck auf das Image (besser Kopie davon) loslassen. Und man sollte nicht automatisiert einfach alles mit yes abnicken lassen sondern erstmal schauen, welche Fehler gemeldet werden und ggf. das ganz manuell durchgehen. Ist natürlich sisyphus-Arbeit und wird schlecht bezahlt.
Und natürlich gibt es für solche Fälle ja auch forensische Tools und Distributionen, die man darauf dann loslassen kann, je nachdem, wie wichtig die Daten sind. manche Leute schreiben sich spezielle Tools dafür sogar selbst für den konkreten Einzelfall. Habe ich in meiner Jugend zwar auch gemacht, aber die Zeiten sind lange rum. Heute schicke ich das einfach zum Datenretter, falls notwendig.
lks
Danke - das war damals mein Einstieg in die Materie und ein paar Monte nach der Frage habe ich dann endlich die Cert. als Datenretter gemacht. Mittlerweile mache ich das und IT-Forensik hauptberuflich.
Das Image hatte ich damals schon mit MRT gemacht. Die Idee mit den Superblöcken ist nicht schlecht. Reparieren ist mir dann ja egal wenn ich die entsprechenden Daten sichern kann.
Das Image hatte ich damals schon mit MRT gemacht. Die Idee mit den Superblöcken ist nicht schlecht. Reparieren ist mir dann ja egal wenn ich die entsprechenden Daten sichern kann.
Da kann ich nur sagen
Noch viel lernen Du mußt junger Padawan.
lks
Noch viel lernen Du mußt junger Padawan.
lks
Das stimmt - es ist bei vielen Fällen immer wieder was neues zu entdecken.
