FAT32 partitie redden

[deepbass909]

Ik heb een gigantisch probleem met één van de schijven in m'n server...
Het betreft een schijf met mp3's die vermoedelijk aan het dood gaan is... Maar ik weet het niet zeker.

Het enige dat ik op het moment weet is dat ik een groot aantal bestanden niet meer kan benaderen (geschat ongeveer een 1/3de van het totaal).

Het is een 40GB Maxtor IDE schijf die FAT32 geformateerd is (hij komt oorspronkelijk uit een windows machine en was tijdelijk overgezet in m'n server vanwege mijn trip naar het buitenland).
Nu kwam ik er van de week dus achter dat een groot deel van mijn directories verdwenen waren en inplaats daarvan lege bestanden met ? voor de directory naam. Nu is een vraagteken de manier voor een FAT32 filesystem om aan te geven dat iets gedelete is, dus zou het weghalen daarvan genoeg kunnen zijn om het terug te krijgen. Echter krijg ik dan een Input/output error.

Ik ben nu bezig om een filescan uit te voeren met dosfsck maar dat lijkt nog weinig uit te richten. Omdat ik dus niet weet of m'n FAT beschadigd is of dat de schijf aan het kapot gaan is, ben ik opzoek naar oplossingen om het te kunnen checken.

Ik weer dat er user-space tools zijn, zoals dosfsck, die de schijf echt kunnen checken als deze niet gemount is, alleen kan ik ze niet vinden. Daarnaast ben ik ook op zoek naar vergelijkbare tools als dosfsck, maar die wat geavanceerder zijn.
De schijf is waarschijnlijk verloren, maar ik zou graag nog zoveel mogelijk data er van af krijgen (vooral omdat 40Gieg veel muziek is...)

[Cyphax]

Je kunt scannen naar bad blocks met badblocks, en dan de output even naar een file mikken. Verder fsck.msdos of dosfsck, wat je al probeert. Ik zou even afwachten of daar nog wat van terugkomt, anders dus badblocks eerst. Om het te recoveren ben je voor zover ik weet gebonden aan tools als getdataback en lost & found enzo... maar ik hoop dat iemand zo'n tool kent die wat minder duur is

[deepbass909]

op het moment ben ik met cat een volledige dump aan het maken van de partitie, hopelijk lukt dat. Badblocks kende ik nog niet, die zal ik eens proberen.

[Cyphax]

Van badblocks eerst even de manpage lezen, standaard is ie nogal weinig verbose, en dan heb je ook geen indicatie van hoever ie nou is

[DukeBox]

ik zou eerst een raw dump maken met een ignore van bad blocks..

[xzenor]

misschien is spinrite een optie?
Duurt effe maar 't schijnt goed te werken
Als het neit zo is krijg ik hier zo vanzelf de reacties

[deepbass909]

DukeBox schreef op dinsdag 04 april 2006 @ 17:04:
ik zou eerst een raw dump maken met een ignore van bad blocks..

Even een hele simpele vraag, hoe doe ik dat???

ik kan wel een dump maken met cat of dd maar die blijven toch stuk lopen op de beschadigde delen...

[Wilke]

Niet te lui he....

zie 'man dd' onder 'noerror'

Dus zoiets ws:

code:

dd if=/dev/juiste-hd-device of=/tmp/plek-waar-40gb-file-past.image bs=1M conv=noerror

Die 'conversie=noerror' betekent 'stug doorgaan na read errors'.

Een tip, niet te gehaast werken en altijd goed controleren of je niet 'if' en 'of' hebt verwisseld (input-file, output-file)

[deepbass909]

@Wilke
ok, dit was precies wat ik aan het doen was, alleen bleef m'n server al 3 dagen op dezelfde sector hangen... Het enige verschil met dezelfde opdracht zonder conv=noerror was dat hij er niet uitklapte...

Ik heb nu trouwens wel een image die ik kan mounten met mount -o loop {image} {mount punt} en die ook leesbaar is verder. Volgens mij staat het leesbare deel van de schijf er wel in, maar ik weet dus niet of er achter dat ene stuk nog iets staat.

Ik dacht dat DukeBox een ander soort dump bedoelde, vandaar m'n vraag.

Ik vraag me overigens af in hoeverre het een defecte schijf betreft. Toen ik deze schijf inbouwde had ik bijzonder veel ruzie met de bios die hem eigenlijk niet ondersteunde. Ik geloof dat hij in de bios ook uit staat (weet het alleen niet meer zeker). Omdat dit vlak voor m'n vertrek was, heb ik het niet echt kunnen testen en was ik allang blij dat hij wou mounten.
De reden dat ik twijfel is namelijk dat er, voor zover ik na kan gaan, een compleet deel van de data lijkt verdwenen. Ik heb een lijst gemaakt van wat er allemaal ontbreek en deze is nogal typisch. 90% van de schijf is dusdanig gedefragmenteerd dat alle mappen en bestanden in alfabetische volgorde staan. Begint het "beschadigde deel" bij de letter S en loopt tot het einde van het alfabet (op een paar mappen na). Daarnaast is de image 32GB (32254MB) groot, wat volgens mij een bekende limiet is.
Als dit veroorzaakt wordt door een bios/ide controller limiet, verklaard het ook waarom dd blijft steken op 1 bepaalde sector en daar niet voorbij aan komt... Het jammere is dat ik nog 4 weken geduld moet hebben voor ik deze schijf in een andere, nieuwe pc kan hangen...

Even voor de duidelijkheid, de machine waar deze schijf in zit heeft deze specs.
(Asus P2B-LS met een celeron Mendocino 333MHz)

[Wilke]

Hmm, dat zou inderdaad goed kunnen ja.

In dat geval is het waarschijnlijk bijzonder lastig om er op afstand iets aan te doen

[deepbass909]

niets eigenlijk, alleen de partitie unmounten en hooguit mounten als ro, zodat de data niet beschadigd kan worden met onbedoelde schrijf acties...
In ieder geval geeft het hoop dat de schijf niet kapot is en dat de data nog aanwezig is.

Daarnaast had ik het idee dat een volledige laag was uitgevallen, omdat er een heel blok onbereikbaar is. Maar nadat ik de omvang van de image heb gezien, lijkt dat ook onwaarschijnlijker te worden. De harddisk heeft namelijk 4 koppen (uit m'n hoofd) en ik kan niet aan de 32GB komen. Er is namelijk minder dan 1/4 van de data omvang weg.
Ook last ik net in de datasheet van Maxtor, dat 32GB een limitatie kan zijn.
Ik moet nu dus maar gedult hebben tot ik weer terug in Nederland ben en de schijf in m'n andere pc kan hangen om hem goed te testen....

[Verwijderd]

Probleem met dd bij gebruik van 'conv=noerror' is dat als er bij het lezen een block niet te lezen is, dan wordt deze overgeslagen, maar dan alleen bij de 'if', niet bij de 'of', dus een foute sector is niet zo'n ramp, maar alles verschuift dan wel in je image!!!
(het block ter grootte van wat je met 'bs=' opgeeft gaat daarbij verloren).
Gebruik dus dd_rescue, dit is een variant op dd, maar speciaal bedoeld voor schijven met fouten.
(zie http://www.garloff.de/kurt/linux/ddrescue/ )

En verder, over die ene evt. kapotte laag, als er 1 laag kapot is, lees je echt niks meer. Een aangeboden datastream wordt wordt namelijk verspreid over alle lagen (zodat de koppen niet onnodig veel bewegen).

[deepbass909]

Dat is dus ook een beetje het punt, dd sloeg geen sector over, maar bleef op 1 sector hangen. Na elke IO-fout stond dezelfde sector weer genoemd, terwijl hij dus eigenlijk door had moeten tellen. Het leek er heel sterk op dat dd tegen een bariëre aan liep.

Door de structuur van m'n data verlies heb ik dus heel sterk het vermoeden dat m'n schijf ook niet beschadigd is. In iedergeval heb ik een backup gemaakt van alles wat nu nog goed leesbaar is en is de machine waar ik ruimte over had nu weer uit.
Aangezien ik op het moment verder eigenlijk niks meer kan doen, ga ik er ook geen tijd meer aan besteden.