dd gebruik: filesystem beschadigd

[cheazers]

Zonder maar 1 sec na te denken heb ik het volgende commando uitgevoerd op mijn gentoo systeem:

dd if=/dev/zero of=/dev/md1 bs=4k count=100000, daarna
dd if=/dev/zero of=/dev/md4 bs=4k count=100000 en daarna
dd if=/dev/zero of=/dev/md4 bs=8k count=100000

ter info:
/dev/md1 tm md4 ware resp gemount op ,/boot ,swap, /, /home

Nadat ik problemen van de /home directory constateerd heb ik het systeem opnieuw opgestart. Grub gaf error 17. En ik besefte me dat het goed mis was.

Na geboot te hebben in knoppix en de arrays weer geassembled heb. Probeer ik e2fsck uit te voeren. De superblocks op /md1 konden niet meer gebruikt worden. Voor mijn home dir heb ik nog wel superblocks gevonden. De melding die ik krijg is: Superblock has an invalid ext3 journal (inode . Clear<y>?

Moet ik dit doen?, Wat is wijsheid om in dit geval te doen? Mijn home dir is dus het aller voornaamste om te recoveren.

Alvast bedankt voor de tips

[cheazers]

ter update:

ik heb superblocks 32768 tm 214990848 in totaal 18. De 1e drie geven een "could not be read" melding terwijl de anderen melden dat het een incorrect ext3 journal bevat.

de /md4 en daarmee /home bevat volgens mdstat: 865485504 blokken en de chunk size is 64k het betreft een raid5 array

[Osiris]

Nu is het niet geheel echt meteen gerelateerd aan een oplossing voor je probleem, maar ik ben zeer benieuwd naar het 'waarom' van je drie `dd`-acties?

[jant]

Tijger, je hebt je file systems verpaald. Kortom reinstall.

[ Voor 0% gewijzigd door jant op 23-05-2008 21:06 . Reden: edit: s/em/ems ]

[Kokkers]

Van alle dingen die je zonder nadenken kan doen op een filesystem valt deze in een redelijk destructieve categorie...

In de categorie zinnige reply:
Bij data recovery is het vaak een best practice om eerst een image te trekken van de partitie schijf voordat je gaat hobby'en.

Ironisch genoeg ken je het te gebuiken commando daarvoor al.

[ Voor 49% gewijzigd door Kokkers op 23-05-2008 21:09 ]

[deadinspace]

cheazers schreef op vrijdag 23 mei 2008 @ 19:09:

dd if=/dev/zero of=/dev/md4 bs=8k count=100000

...

Wat is wijsheid om in dit geval te doen? Mijn home dir is dus het aller voornaamste om te recoveren.

Allereerst: je hebt ongeveer de eerste 781 MB van je /home overschreven met nullen. Alles wat daar stond ben je helaas echt kwijt.

Verder kan ik Kokkers' tip erg aanraden. Als je met de restanten van je filesystem gaat rommelen, dan loop je het risico het alleen maar erger te maken. Wel zo fijn als je dan een kopie aan het verklooien bent ipv je originele partitie.


Lang geleden is mij iets vergelijkbaars overkomen; Ik had DOS geinstalleerd op een partitie helemaal achteraan de harde schijf. DOS kan daar blijkbaar niks van en heeft gedaan alsof zijn partitie helemaal vooraan de schijf stond, en heeft daardoor vrolijk een paarhonderd MB over mijn ext2 partitie lopen kalken.

Ik heb dat destijds weer goed gekregen door mke2fs met de -S optie te draaien op mijn partitie. Dat maakt de superblocks en dat soort zooi opnieuw aan, maar initialiseert geen nieuwe inhoud van het filesystem. Daarna heb ik er e2fsck overheen gedraaid die een heleboel in lost+found heeft gegooid.

Ik had één grote partitie voor alles, en blijkbaar is het filesystem van voor naar achter vol gelopen, want ik was alleen systeem-files (vooraan het filesystem, overschreven door DOS) kwijt, heel mijn /home was nog te recoveren.

Maar probeer dat alsjeblieft op een kopie, want als mke2fs en e2fsck zich verslikken op je beschadigde filesystem dan kunnen ze lelijke dingen doen. Lees ook de manpages van die twee goed door (zeker die van de -S optie van mke2fs).

[cheazers]

dat ik een gb kwijt ben aan data is mij duidelijk. Ik vraag me echter af op welk deel vd partitie de gig overschreven is. De totale homedir is enkele honderden gb's, dus hopelijk valt er nog iets te redden.

Kan iemand me zeggen of de vraag met beantwoord kant worden, en zo een deel van het filesystem gered kan worden?

Ik zal eerst met dd een backup maken, mijn fantastische hulpmiddel.

BTW ik had verschillende blocksizes in een script gezet, vandaar 3 maal.

Hopelijk kan iemand deze ervaring met mij delen, en een advies geven.

[DusHmaniac]

je hebt met deze geweldig slimme actie ook je journals gesloopt, waarvan de eerste inodes aan het begin van je schijf staan. het is namelijk het eerste bestand dat wordt aangemaakt als je een nieuw ext3 filesystem aanmaakt en dd begint bij sector 0 te schrijven. tenzij je dus idioot grote journals hebt ingesteld op je filesystems ben je die kwijt. e2fsck gaat dus niet veel zinnigs meer kunnen doen, zelfs al druk je op yes. waarschijnlijk maakt dit zelfs nog meer stuk.

een beetje googlen levert de volgende tool op: http://www.guzu.net/linux/e2retrieve.php

e2retrieve:

* can recover data from a truncated or split ext2 filesystem (in the case of a LVM with a disk that has crashed, for example),
* will not write onto the ext2 filesystem it is analysing, therefore it will never increase damages previously caused,
* recovers directories, directories tree, files, symbolic links and special files with their access rights, owner and modification date,
* is fully written in C from scratch,
* does not need any library,
* can easily fit in a rescue floppy disk (in the case where you do not have enough IDE slots),
* is not an undeleting tool

ik heb het zelf nooit geprobeerd maar dit lijkt me de moeite waard om te proberen. e2fsck kan je vergeten

[deadinspace]

DusHmaniac schreef op zaterdag 24 mei 2008 @ 18:26:
je hebt met deze geweldig slimme actie ook je journals gesloopt [...] e2fsck gaat dus niet veel zinnigs meer kunnen doen

En waarom betekent het feit dat het journal pleite is dat e2fsck niks zinnigs meer kan doen?

[isama]

deadinspace schreef op zaterdag 24 mei 2008 @ 22:36:
[...]

En waarom betekent het feit dat het journal pleite is dat e2fsck niks zinnigs meer kan doen?

volgen mij klopt dat niet, want ext2 heeft geen journals.

suc6 TS!

[smokalot]

Ik heb met dit tooltje wel eens een hoop data terug kunnen halen: http://www.cgsecurity.org/wiki/PhotoRec

Dat tooltje kijkt niet naar het filesystem, maar gewoon naar de rauwe data, die ie probeert te parsen. Ik kan me voorstellen dat die aanpak ook zn nadelen heeft, zoals veel parsetijd, en problemen met gefragmenteerde bestanden. Je kunt m wel read-only draaien, dus dan maak je in ieder geval niet nog meer kapot.

[DusHmaniac]

deadinspace schreef op zaterdag 24 mei 2008 @ 22:36:
[...]

En waarom betekent het feit dat het journal pleite is dat e2fsck niks zinnigs meer kan doen?

het woordje "dus" was niet correct in mijn post want dat het journal weg is is inderdaad niet de reden. mijn excuses. neemt niet weg dat e2fsck niet veel zinnigs meer gaat doen, behalve een hele mooie grote lost+found met wat geluk, gevuld met fragmenten van files, waarbij hij dus in het al kapotte filesystem gaat schrijven en dat is nou niet bepaald het meest goede plan als je data recovery tools wil gaan gebruiken.

isama schreef op zaterdag 24 mei 2008 @ 22:44:
volgen mij klopt dat niet, want ext2 heeft geen journals.

maar ext3 wel en dat het om ext3 gaat staat in het gerecoverde superblock

[jant]

isama schreef op zaterdag 24 mei 2008 @ 22:44:
[...]

volgen mij klopt dat niet, want ext2 heeft geen journals.

suc6 TS!

Dan heb je niet goed opgelet, het gaat niet om ext2 maar ext3:

De melding die ik krijg is: Superblock has an invalid ext3 journal

[ Voor 12% gewijzigd door jant op 25-05-2008 12:14 ]

[Verwijderd]

Nou, je hebt het goed verkloot.
Het filesystem is in ieder geval kapot. Stel je je filesystem voor als een boom van inodes, dus allemaal vertakkingen die hun oorsprong aan het begin van het filesystem vinden. Je hebt de eerste 100000 blokken weggeknikkerd, dus heb je gewoon een collectie losse inodes die nergens meer aanhangen, en dus kan er geen zichtbare directory structuur op te bouwen. (zonder superblock kun je zelfs niet eens proberen te mounten).

Wat je kunt doen, is het tooltje foremost gebruiken (op /dev/<bla>). Je directory structuur blijft kwijt, maar de resterende data die hopelijk aaneengesloten op de nog intacte partities staan worden eruit getrokken en in een dir structuur gegooid die gesorteerd staan op basis van filetype. Let wel, bestandsnamen zijn onderdeel van het filesystem en niet van de data, dus bestandsnamen ben je dan ook kwijt.
Dit tooltje werkt op basis van structuren van bekende bestanden en zal die eruit trekken. Onbekende formaten en plain text zal ie niets mee doen. Als je je plain text terug wilt, kun je een cat /dev/<bla> | strings > text.out doen, en dan maar een beetje spitten om iets terug te krijgen.

Maar de vraag:
Hoe kom je in godsnaam aan die commando's? Waarom leek het je een goed plan om je partities te 'zeroen'? Wie raadt je dat soort dingen aan en schiet die persoon af aub.
Tip: maak backups.

Laat me raden: je wilde weten hoe je je filesystem moest defragmenteren, vroeg dit op IRC en dit was je antwoord?

Edit: gebruik de tools niet op /dev/<bla> maar op je getrokken image.

[ Voor 11% gewijzigd door Verwijderd op 26-05-2008 11:54 ]

[deadinspace]

Verwijderd schreef op maandag 26 mei 2008 @ 11:31:
Stel je je filesystem voor als een boom van inodes, dus allemaal vertakkingen die hun oorsprong aan het begin van het filesystem vinden. Je hebt de eerste 100000 blokken weggeknikkerd, dus heb je gewoon een collectie losse inodes die nergens meer aanhangen, en dus kan er geen zichtbare directory structuur op te bouwen.

Dat klopt niet.

De inodes en data-blocks liggen vrij regelmatig verspreid over het filesystem. Door de eerste ±800MB te overschrijven heeft hij dus een deel van de inodes en een deel van de data vernaggeld, maar van alles wat verderop ligt is nog zowel de data als de metadata intact.

Neem als voorbeeld ~/.ssh:

code:

.ssh
|-- config
|-- id_dsa
|-- id_dsa.keystore
|-- id_dsa.pub
`-- known_hosts

Als alle inodes en alle data-blocks van al deze files (inclusief .ssh) voorbij die eerste ±800 MB liggen, dan zijn deze files allemaal volledig terug te halen, inclusief hun namen en hun onderlinge hierarchie.

Die metadata (de hierarchie en de filenames) liggen dus niet allemaal vooraan het filesystem zoals jij beweert.

[cheazers]

[b][message=30130635,noline]
Wat je kunt doen, is het tooltje foremost gebruiken (op /dev/<bla>).

Inmiddels heb ik e2retrieve al 27 uur aan het draaien. Het lijkt er op dat hij vastloopt. Ik heb inmiddels de maker gemaild.

Verder naar photorec gekeken, maar dat kan niet met raid partities overweg.

Als laatste zal ik foremost proberen, in de hoop dat dat nog iets zinnings oplevert. Ik heb echter ook veel:

1) raw photos. Met cr2 extensie
2) openoffices files
3) latex files
4) matlab files

Deze kan ik helaas niet terug vinden in de howto.

[smokalot]

Heb je nou niet opgelet? je moet geen van die tools draaien op je raid-partities, je moet eerst een image maken!

oh, en photorec kan prima overweg met cr2 bestanden, en ik neem aan dat latex bestanden en openoffice bestanden ook wel lukken.

[ Voor 36% gewijzigd door smokalot op 26-05-2008 22:58 ]

[Bergen]

Als hij nog meer partities heeft kan hij de output van die tools wel naar een niet-verklote partitie schrijven toch?

En inderdaad, ik ben ook wel benieuwd wat je tot dit lumineuze idee gebracht heeft. Stonden die commando's in een handleiding ofzo? Of moest je dat voor de grap intoetsen van iemand?

[DieterVDW]

Laat ik het zo stellen: als ik deze commando's per ongeluk zou intikken en ze worden helemaal uitgevoerd, en dan herlees ik ze en besef wat ik gedaan heb, dan zou ik er zelfs niet meer aan beginnen om te proberen recoveren denk ik ...

Mijn medeleven, hopelijk heb je backups ...

[deadinspace]

En de aanpak in mijn eerste post in dit topic?

[jant]

Bergen schreef op maandag 26 mei 2008 @ 23:16:
En inderdaad, ik ben ook wel benieuwd wat je tot dit lumineuze idee gebracht heeft. Stonden die commando's in een handleiding ofzo? Of moest je dat voor de grap intoetsen van iemand?

Ik begin langzaam het vermoeden te krijgen dat cheazers deze vragen probeert te ontwijken.

[Verwijderd]

deadinspace schreef op maandag 26 mei 2008 @ 17:43:
[...]

Dat klopt niet.

De inodes en data-blocks liggen vrij regelmatig verspreid over het filesystem. Door de eerste ±800MB te overschrijven heeft hij dus een deel van de inodes en een deel van de data vernaggeld, maar van alles wat verderop ligt is nog zowel de data als de metadata intact.

Neem als voorbeeld ~/.ssh:

code:

.ssh
|-- config
|-- id_dsa
|-- id_dsa.keystore
|-- id_dsa.pub
`-- known_hosts

Als alle inodes en alle data-blocks van al deze files (inclusief .ssh) voorbij die eerste ±800 MB liggen, dan zijn deze files allemaal volledig terug te halen, inclusief hun namen en hun onderlinge hierarchie.

Die metadata (de hierarchie en de filenames) liggen dus niet allemaal vooraan het filesystem zoals jij beweert.

Ik stel niet alles daar ligt, maar wel het geen wat nodig is om te kunnen mounten. De 'root'-node ligt vooraan, de rest ligt in een boomstructuur verspreid over het hele filesystem.
Wat de metadata/bestandsnamen betreft, dat is wat ik heb begrepen onderdeel van de inode (of een verwijzing daaruit) waarmee een bestand begint, en zijn dus idd nog intact. Maar foremost kijkt enkel naar ruwe data en niet naar inodes en neemt dus geen bestandsnamen oid over.

Wat dat e2retrieve tooltje doet, dat weet ik niet, ik heb het nog nooit gebruikt.
Als dat er voor zorgt dat alle inodes die nog rondzwerven onder een root geplakt kunnen worden, dan zou dat ideaal zijn. Als er fragmentatie aanwezig is op het fs, dan zou zo'n ext2 tooltje een betere keuze zijn dan foremost omdat dat ding aaneengesloten data nodig heeft.

[cheazers]

- Ik heb eerst een image gemaakt van de partitie
- e2retrieve loopt na 3 dagen vast
- actie is ontstaan door het checken van de lees/schrijfsnelheid van de raidarray. Ik heb dd met de hdparm test door elkaar gehaald. Verder stonden de acties in een script, vandaar 3x. Dit is 's ochtends om 5 uur gebeurt, na een lange nacht....

Verder heb ik photorec al eventjes draaien. Resultaat is veelbelovend. Alleen jammer van de structuur+filenames.

Als de mke2fs -S niets oplevert, dan is photorec en evt foremost mijn enige oplossing

Mijn geluk is dat ik nog wel meta info van de cr2 files kan gebruiken. Verder bevatten de partitie 400+ GB aan avi/mkv materiaal en 100+ aan mp3. En verder wat virtuele omgevingen van vmware. Dit is nog geen grote ramp.

Allen bedankt voor de tips. Ik laat nog weten wat de procedure van deadinspace mij oplevert.