IO errors, is dit te recoveren?

[Boudewijn]

Hoi


Zoals sommigen weten is mijn IO controller gisteren gesneuveld, deze bleek bij default op write back te staan (thanks areca, heel fijn als je dat doet maar geen BBU hebt....).

Nu zit ik dus met wat gebakken peren, als ik met een rescue cd ga rsyncen naar een 2e machine:

code:

sending incremental file list
virtuele-machine/
virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem": Input/output error (5)
virtuele-machine/virtuele-machine-000001.vmdk
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/virtuele-machine-000001.vmdk": Input/output error (5)
virtuele-machine/virtuele-machine-Snapshot1.vmem
virtuele-machine/virtuele-machine-Snapshot1.vmsn
virtuele-machine/virtuele-machine-flat.vmdk
rvirtuele-machine/virtuele-machine.nvram
virtuele-machine/virtuele-machine.vmdk
virtuele-machine/virtuele-machine.vmsd
virtuele-machine/virtuele-machine.vmx
virtuele-machine/virtuele-machine.vmxf
virtuele-machine/vmware-0.log
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/vmware-0.log": Input/output error (5)
virtuele-machine/vmware-1.log
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/vmware-1.log": Input/output error (5)
virtuele-machine/vmware-2.log
virtuele-machine/vmware.log
virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem.lck/
virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem.lck/M22513.lck
virtuele-machine/virtuele-machine-000001.vmdk.lck/
virtuele-machine/virtuele-machine-000001.vmdk.lck/M31429.lck
virtuele-machine/virtuele-machine.vmdk.lck/
virtuele-machine/virtuele-machine.vmdk.lck/M48948.lck
WARNING: virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem failed verification -- update discarded (will try again).
virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem": Input/output error (5)
WARNING: virtuele-machine/virtuele-machine-000001.vmdk failed verification -- update discarded (will try again).
virtuele-machine/virtuele-machine-000001.vmdk
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/virtuele-machine-000001.vmdk": Input/output error (5)
WARNING: virtuele-machine/vmware-0.log failed verification -- update discarded (will try again).
virtuele-machine/vmware-0.log
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/vmware-0.log": Input/output error (5)
WARNING: virtuele-machine/vmware-1.log failed verification -- update discarded (will try again).
virtuele-machine/vmware-1.log
rsync: read errors mapping "/mnt/data/home/vm/virtuele-machine/vmware-1.log": Input/output error (5)
ERROR: virtuele-machine/564d5274-e90a-ce9d-4fd9-ddecf8ac54b9.vmem failed verification -- update discarded.
ERROR: virtuele-machine/virtuele-machine-000001.vmdk failed verification -- update discarded.
ERROR: virtuele-machine/vmware-0.log failed verification -- update discarded.
ERROR: virtuele-machine/vmware-1.log failed verification -- update discarded.

Het FS is een ext3, op debian linux.
De controller is een areca1120 met raid6.

Weet iemand of ik die vmware files nog kan redden? Ik kan zo proberen vmware gewoon te starten, maar echt jofel ziet dit er niet uit.

Is dd eventueel een optie?

[SpamLame]

Ik heb mijn twijfels of dat gaat werken.
Ik bedoel met dd overzetten lukt vast wel aangezien dat het kopieren van blokken betreft, maar de files blijven evengoed corrupt in mijn ogen.
Door de cache in te zetten heet het FS de schrijfacties als succesvol beschouwd. Dat de data uit de cache nooit op de schijven geland is is vervelend maar kan, vzmb, niet meer door het FS teruggedraait worden.

Ben je geen backup van je spullenboel?

[Boudewijn]

Heb geen backup nee. Waarlijk stupide.

Maar is die hele file te gaar voor vmware, of alleen een deel?
Kan ik niets iets met mijn journal doen?

[SpamLame]

Dat weet ik niet, kom je achter als je de VM probeert te starten.
De journal van je FS heeft de IO's als succesvol bestempeld dankzij de cache.
Als EXT3 iets specials heeft om dat terug te draaien (denk aan snapshotting zoals ZFS (meen ik) en het filesystem van dragonfly bsd hebben) verwacht ik daar weinig van.
Had je al een fsck gedraaid en wat geeft die dan aan?

[Boudewijn]

fsck is al een uur bezig.

Net een paar opeenvolgende inodes met fors veel errors.

Maar we zijn nu op 274miljoen (van de 750m) en al 20 mins geen errors gezien.


Nu (terwijl ik het typ) rond de 560 miiljoen ook weer een paar opeenvolgende inodes met illegal blocks.

[Boudewijn]

Gisteren is na een paar uur fsck zelfs vastgelopen.
Herstarten leverde weer heel veel errors op (en een half uur alleen maar getallen printen ,te snel om te lezen... hele beeldscherm stond vol).

Lijkt me einde oefening, of heeft iemand nog een goed idee?

[Rainmaker]

Probeer eens een dd_rescue van je hele schijf te trekken naar een andere schijf, en ga daar in ieder geval op experimenteren (als je zo'n schijf nog ergens hebt).

Je zou daarna eens kunnen kijken of foremost of sleuthkit er nog iets van kan maken.

En dat je geen backup hebt, kan ik me op zich nog best voorstellen; je waant je redelijk veilig met dubbele pariteit

[deadinspace]

Rainmaker schreef op donderdag 28 mei 2009 @ 21:39:
Je zou daarna eens kunnen kijken of foremost of sleuthkit er nog iets van kan maken.

PhotoRec (die ondanks de naam een hoop meer kan recoveren dan plaatjes) is er ook nog zo een. Daarmee heb ik nog eens een hoop teruggehaald toen ik iets te enthousiast aan het rm -rf'en was.

[Boudewijn]

Rainmaker schreef op donderdag 28 mei 2009 @ 21:39:
Probeer eens een dd_rescue van je hele schijf te trekken naar een andere schijf, en ga daar in ieder geval op experimenteren (als je zo'n schijf nog ergens hebt).

Je zou daarna eens kunnen kijken of foremost of sleuthkit er nog iets van kan maken.

En dat je geen backup hebt, kan ik me op zich nog best voorstellen; je waant je redelijk veilig met dubbele pariteit

Ouch, hij is gisteren geformatteerd.
Ik heb geen andere 6tb 'schijf' over trouwens.

Nou ja , lekker handig.

[Rainmaker]

De grootte stond niet in je posts (of ik lees er overheen), maar ik had al verwacht dat het groot was

Je zou alsnog met bovenstaande tooltjes. Die zouden ook een format moeten kunnen terughalen.

[Bergen]

Als het om bad sectors gaat, zou je misschien (met SMART?) kunnen achterhalen op welke schijf deze bad sectors staan. Als je die schijf vervolgens uit je RAID-array verwijdert, zou de data weer goed kunnen worden gelezen van de andere schijven, toch?

[Boudewijn]

Uhhh maar de raid kaart hoort sowieso niet afhankelijk te zjin van een gare schijf.
Het zat over alle schijven heen trouwens.