ext3 data recovery?

[Verwijderd]

Gisteren is 1 van de 2 HD's in mijn linux software raid (striping) gaan haperen, en ik ben op zoek naar een mogelijkheid mijn data zoveel mogelijk terug te halen.

Omschrijving systeem (maakt volgens mij voor het probleem niet veel uit maar je weet maar nooit):
2x Maxtor 60 gb 7200 rpm liquid bearing schijven, beide master van 1 van de 2 kanalen op mijn Silicon Image 0680 kaartje. Schijven zijn hde en hdg.
Elke schijf heeft 4 partities, waarvan hde2 en hdg2, elk 50 Gb, mijn 100 Gb raid vornen, md0 genaamd. Op md0 staat een ext3 filesystem met 4k blocks en intern journal.

Omschrijving probleem: van de hdg schijf kan een (naar mijn inschatting) klein deel niet meer worden gelezen. Helaas valt dit net in de eerste 15 Mb van hdg2, zodat de eerste 30 Mb van md0 onleesbaar zijn. Dit is dus typisch het deel waar het ext3 journal staat. Het fs is niet clean ge-unmount.

Ik heb de volgende mount/fsck-pogingen ondernomen (alle als read-only)

Gewoon mounten/fscken als ext3 geeft het probleem dat de journal inode (waarschijnlijk net als het journal zelf) niet gelezen kan worden; wat het onmogelijk maakt te mounten.

Een reserve-superblock opgeven (nummers afgeleid uit mke2fs -n) geeft een "Magic mismatch". (zowel uitgaand van 1k als 4k blocks)

Mounten als ext2 kan in principe met ext3; maar de ext2 driver ziet het unclean zijn van ext3 als een unsupported feature en wil hem dus ook niet mounten. Zelfde probleem als ik een ander superblock opgeef.

Kort gezegd: ext2 wil niet mounten omdat ie ext3-unclean is; en omdat de ext3 jounal zo goed als weg is wil ie ook niet als ext3 mounten.

Op de HCC dagen wil ik een 120 gb schijf kopen zodat ik het leesbare fs-deel daarheen kan dd-en en ik wat kan prutsen en een eventueel gemount fs ook kan worden teruggeschreven.

Wie heeft er mogelijke oplossingen? Dus bijvoorbeeld:
- Een manier om het fs als clean te markeren zonder met een hexeditor over de superblock heen te gaan zodat ik hopelijk als ext2 kan mounten.
- Iets dat het journal op een semi-nette manier kan legen+opnieuw aanmaken (evt op andere lokatie of zelf externe file) zonder dat het eerst moet worden verwerkt.
- Als het echt niet anders kan: een programma dat me helpt om ext2/3 op een laag niveau door te werken zodat ik dat niet zelf hoef te schrijven.

alvast mijn eeuwige dank voor wie de oplossing heeft...

PS Voor mij offtopic-ness verweten wordt, naar mijn mening is dit meer linux-gerelateerd dan HD-gerelateerd en is veruit de meeste nuttige kennis erover hier aanwezig.

[ Voor 5% gewijzigd door Verwijderd op 27-11-2003 12:31 . Reden: kleine aanpassing+PS ]

[Vae Victis]

Heb zelf al aantal keren ext3 fs gerecovered door dit te doen:
mkfs.ext3 -S /dev/hdx + meer opties die nodig zijn
iig dezelfde opties gebruiken die je bij het maken van die fs gebruikt hebt.
-S is belangrijk.

-S Write superblock and group descriptors only.

daarna fsck.ext3 + -y als je default alles met yes wil beantwoorden.
Alle files die gerecovered worden staan daarna in lost+found.

Zou wel even een backup maken als dat mogelijk is.
Ik geef geen garantie dat alles gerecovered word

[ Voor 10% gewijzigd door Vae Victis op 27-11-2003 12:42 ]

[ny-hardcore]

ik weet niet hoe het zit met een striping raid..

maar als je journal corrupt is (wat mij laatst gebeurde) kan je terug naar ext 2 door de journal te verwijderen
en daarna weer naar terug naar ext3

http://www.troubleshooters.com/linux/ext2toext3.htm
onderaan de pagina wordt beschreven hoe je de journal weghaalt

mischien heb je erwat aan ..

[ Voor 10% gewijzigd door ny-hardcore op 27-11-2003 14:11 . Reden: info ]

[mocean]

ny-hardcore schreef op 27 november 2003 @ 14:09:
ik weet niet hoe het zit met een striping raid..

maar als je journal corrupt is (wat mij laatst gebeurde) kan je terug naar ext 2 door de journal te verwijderen
en daarna weer naar terug naar ext3

http://www.troubleshooters.com/linux/ext2toext3.htm
onderaan de pagina wordt beschreven hoe je de journal weghaalt

mischien heb je erwat aan ..

De journal weghalen is volgens mij niet nodig. Je kan de partitie ook gewoon als ex2 mounten, dan wordt de journal genegeert.

[igmar]

Verwijderd schreef op 27 november 2003 @ 12:25:
G
Kort gezegd: ext2 wil niet mounten omdat ie ext3-unclean is; en omdat de ext3 jounal zo goed als weg is wil ie ook niet als ext3 mounten.

Op de HCC dagen wil ik een 120 gb schijf kopen zodat ik het leesbare fs-deel daarheen kan dd-en en ik wat kan prutsen en een eventueel gemount fs ook kan worden teruggeschreven.

Wie heeft er mogelijke oplossingen? Dus bijvoorbeeld:
- Een manier om het fs als clean te markeren zonder met een hexeditor over de superblock heen te gaan zodat ik hopelijk als ext2 kan mounten.

met ext2ed en/of debugfs moet dit te doen zijn. Simpel zal het niet wezen, aangezien kennis van het FS is vereist. Je zal ook het superblock moeten wijzigen, wat er met je journal gebeurd kan ik niet zeggen, in principe blijft die gewoon staan.

[igmar]

mocean schreef op 28 november 2003 @ 01:02:
De journal weghalen is volgens mij niet nodig. Je kan de partitie ook gewoon als ex2 mounten, dan wordt de journal genegeert.

Dat gaat dus niet werken, aangezien het ext3 fs niet clean is. Staat overigens ook in de startpost.

[ny-hardcore]

idd, als je journal corrupt is dan zegt ie dat hij unclean is..

in mijn geval was mijn root partitie journal corrupt, ext3 flipte daardoor uit en maakte het read-only ... kun je dus niet meer werken met je systeem ..

[Verwijderd]

Even een korte samenvatting van de voortgang met het herstel, mede ten behoeve van mensen met hetzelfde probleem die na een search dit topic nalezen:
Ik heb op de HCC dagen een 120 gb Maxtor schijf gekocht (klojo's van PowerLine zijn er in geslaagd me eerst 2 keer het verkeerde te geven: een CD-ROM drive en een WD HDD...).

Hier heb ik zoveel mogelijk van het originele fs (dus md0, zie mijn beginpost) heen gekopieerd, en wel met een scriptje dat het volgende deed (overigens blijkt niet alleen het begin van het fs brak te zijn):
Lees eerst mbv "dd" blokken van 100 meg van de schijf naar een image file, en schrijf naar een logfile welke blokken fouten bevatten. Ga de blokken-met-fouten opnieuw over maar kopieer nu in 10M grote blocks, en log wederom de fouten. Daarna nog een keer voor 1M blocks; en tot slot een dd conv=noerror. Dit lijkt onnodig moeilijk maar ik kan me voorstellen dat een dd conv=noerror in 1 keer over de hele schijf het vroegtijdig helemaal overlijden bevordert. Het hele gedoe heeft een uur of 6 gekost (mede omdat linux dma uitzet als een schijf hardware errors geeft, zie ook opmerking onderaan).

Vervolgens heb ik een User Mode Linux kernel met support voor Copy On Write (COW) en de nodige filesystems gebakken en deze geboot met een simpel basissysteem en de image file van de brakke raid via een COW device. Als ik nu vanuit UML het filesystem mishandel gaan de wijzigingen naar een copy-on-write file en niet naar de originele image, wel zo geruststellend ;-)
In UML heb ik een mke2fs -S /dev/ubd1 (de ge-COW-de image file) gedaan, gevolgd door een fsck -y die nu na een paar uur nog steeds bezig is en VEEL fouten geeft. Dat laatste begint mij enigszins verdacht over te komen aangezien er weinig echt stuk is; van de andere kant kan het ook een onvermijdelijk bij-effect van de mke2fs -S zijn.

Tegelijk ben ik ook een andere mogelijkheid aan het verkennen. Met het "debugfs" commando ben ik nu door de image file heen aan het fietsen (luide *zucht* toen ik zag dat debugfs iig nog veruit het grootste deel van mijn oude directory structuur kan zien en steekproefsgewijs volledig intacte files naar een ander fs kan dumpen).

Kortgezegd zijn debugfs en User Mode Linux met copy-on-write echte aanraders als je een filesystem wil herstellen. Misschien schrijf ik er nog wel eens een howto over als het allemaal goed gaat en ik tijd over heb.

Paar wijze lessen:
- de conv=notrunc optie van dd is geen slecht idee als je opnieuw over een image file gaat schrijven en de oude data niet kwijt wil.
- dma aanzetten (hdparm -d1 /dev/[schijf] ) voor een op dat moment hevig bezige schijf is geen goed idee (HD gaf niet thuis tot ik de pc helemaal compleet uitzette, zelfs een harde reset hielp niet).
- voor een tegeltje aan de muur: there's no such thing as too many backups.

[Verwijderd]

Inmiddels is mijn filesystem weer grotendeels leesbaar (zeker 75 vd 90 gb aan data terug, en waarschijnlijk meer als ik er nog even goed voor ga zitten).
De Gouden Weg was in dit geval:
- Maak een zo volledig modelijke image van de raid op een andere schijf
- Start een User Mode Linux kernel met de image als 2e virtuele harddisk via een copy-on-write file
- Draai hierbinnen /sbin/debugfs -w op de COW device, controleer of de tree een beetje in orde lijkt (met name een root inode is leuk om te hebben ;-)
- In debugfs, gebruik "features -needs_recovery" om de needs_recovery flag uit te zetten (gebruik "features" zonder optie voor een lijst van flags, evt had ik has_journal ook nog kunnen uitzetten), en verlaat debugfs
- nog steeds in de UML, mount het fs expliciet als ext2
- kopieer de data naar een nuttiger plek (bv door de UML kernel netwerk support en een netwerk FS te geven, maar als deze stap gelukt is kun je misschien ook het risico nemen om debugfs direct op de image file toe te passen, of na stoppen van UML met uml_moo de COW file in de image te integreren). Bestanden die toch verloren zijn geven waarschijnlijk een input/output error, wat evt weer nuttig is om naar een log door te sturen.

Nu nog een plek vinden om al die data heen te zetten... zal wel DVD+R worden.

Btw, de methode dmv mke2fs -S leek ook wel wat op te leveren; maar na 15 uur fsck-en heb ik hem gestopt; op dat moment bleek er na mounten ongeveer 30 gb op het fs aanwezig te zijn (na een volledige fsck waarschijnlijk veel meer) waarvan het merendeel in lost+found. Vooralsnog lijkt de debugfs methode meer succesvol.

En nu ga ik een tempel oprichten voor Theodore Ts'o, de god die debugfs heeft geschreven.