[reiserfs] journal kapot, data nog terug te krijgen?

[Berik]

Mijn HD begon errors te geven, hier een paar voorbeelden uit mn syslog:

code:

Jan 22 17:12:16 localhost kernel: hdc: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Jan 22 17:12:16 localhost kernel: hdc: task_in_intr: error=0x40 { UncorrectableError }, LBAsect=213458695, high=12, low=12132103, sector=213458695
Jan 22 17:12:16 localhost kernel: end_request: I/O error, dev hdc, sector 213458695
Jan 22 17:12:16 localhost kernel: ReiserFS: hdc1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [11966 16812 0x0 SD]
Jan 22 17:12:17 localhost kernel: hdc: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Jan 22 17:12:17 localhost kernel: hdc: task_in_intr: error=0x40 { UncorrectableError }, LBAsect=267451823, high=15, low=15793583, sector=267451823
Jan 22 17:12:17 localhost kernel: end_request: I/O error, dev hdc, sector 267451823
Jan 22 17:12:17 localhost kernel: ReiserFS: hdc1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [11966 64297 0x0 SD]
Jan 22 17:12:19 localhost kernel: hdc: task_in_intr: status=0x59 { DriveReady SeekComplete DataRequest Error }
Jan 22 17:12:19 localhost kernel: hdc: task_in_intr: error=0x40 { UncorrectableError }, LBAsect=267451823, high=15, low=15793583, sector=267451823
Jan 22 17:12:19 localhost kernel: end_request: I/O error, dev hdc, sector 267451823
Jan 22 17:12:19 localhost kernel: ReiserFS: hdc1: warning: vs-13070: reiserfs_read_locked_inode: i/o failure occurred trying to find stat data of [11966 70672 0x0 SD]

ik toen de partitie ge-unmount en

code:

reiserfsck --check /dev/hdc1

gedaan. Deze kon niet voltooien door hardware-error's en suggerreerde om het nog een keer met de -B optie te doen, vervolgens dus

code:

reiserfsck --rebuild-tree -B badblock.log /dev/hdc1

gedaan ook deze opdracht kon niet voltooid worden.

Nu wil de partitie alleen niet meer gemount worden, omdat de journal kapot is.
Ik heb de schijf dus maar opgegeven, maar dit was mijn /home dus ik wil mijn data wel terug.
Ik heb natuurlijk in mijn haast niks geback-upped

Nu dus mijn vraag of ik nog bij mijn data kan en zoja, hoe?

Ik heb natuurlijk wel gezocht op het grote boze web, maar kon geen goede antwoorden vinden hierover.

[Verwijderd]

Je hebt wel badblocks gedraaid?

[ Voor 9% gewijzigd door Verwijderd op 22-01-2006 21:06 . Reden: typo ]

[Berik]

ik ben nu:

code:

badblocks -o bad.log /dev/hdc1

aan het draaien

[it0]

kan je die partitie niet dd'en naar een bestand op een gezonde hd en die vervolgens bewerken?
Of misschien daar weer een kopie van dan is het niet zo erg als je iets verkloot.

[Berik]

badblocks was heel lang bezig en heeft een lijstje met ruim 25 badblocks gegeven

Nu heb ik een andere (identieke) HD erbij gezet en ben ik met dd alles aan het copieren
ik denk dat dat wel even gaat duren, maar in ieder geval bedankt voor de hulp tot nu toe.

Als ik journal van de partitie dan kan fixen op de gezonde schijf, zou ik eindelijk van mn problemen af zijn

Edit:
Heel raar, de 2 HD's zijn identiek (zelfde type enzo) maar de gezonde schijf is een paar MB kleiner als de kapotte.
Hierdoor zegt hij nu alleen maar dat de partitie tot voorbij het einde van de disk gaat en er dus niks mee kan.

reiserfsck kan nu gelukkig wel een --rebuild-tree doen, maar dat duurd nog een hele tijd. Ik ga daarom maar naar bed en kijk morgen wel verder.

[ Voor 35% gewijzigd door Berik op 23-01-2006 00:37 ]

[Berik]

reiserfsck --rebuild-tree heeft weinig opgelost. Omdat de gezonde HD dus kleiner wordt aangegeven als de kapotte (zo'n 3GB) kan die nogsteeds niks doen.
Ik heb nu wel met:

code:

dd if=/dev/zero of=/dev/hdc bs=512 count=1

de partitie tabel eraf kunnen halen, waardoor ik weer in cfdisk kan komen.

Weet iemand waarom mijn 2 HD's die een identiek type-nummer hebben en de zelfde specs geven in de bios een verschil van 3GB geven?
Of misschien een andere manier waarop ik mijn data naar de gezonde schijf kan krijgen?
Het gaat om Maxtor DiamondMax9 160GB schijven (type: 6Y160P0)

[freggy]

Is dat één grote partitie van 160 GB misschien?

Wat ik altijd doe in zo'n geval, is met dd de getroffen partitie kopiëren naar een image bestand op een andere partitie of schijf die groot genoeg is, en rechtstreeks die image proberen mounten via het loop device, en/of daarop fsck toepassen. Moet je natuurlijk wel ergens een schijfpartitie hebben die groot genoeg is voor de image...

[Berik]

Ik heb dus nog een tweede identieke HD die net uit een windows pc komt en als doel had om naast de andere 160GB partitie te zetten in mij debian server.
Maar mijn huidige 160GB HD in de server bleek dus fouten te hebben.
Hierop stond inderdaad 1 partitie die op /home gemount is
Ik wil nu dus de data van de oude schijf naar de nieuwe schijf krijgen, zodat ik weer bij (zoveel mogelijk van) mijn data kan.

Ik heb net dit artikel gevonden en ben nu met:

code:

dd if=/dev/hdd skip=1 of=/dev/hdc seek=1 bs=4k conv=noerror

een nieuwe poging aan het doen. (hdd is de oude schijf, hdc de nieuwe)

Ik hoop echt dat ik mijn data terug kan krijgen, want er stond dus heel veel belangrijke dingen op (paar websites, back-ups, school-dingen, prive spul, al mijn install-files) die ik natuurlijk niet ergens anders had ge-backupped (server was daarvoor)

Ik weet in ieder geval wel, dat als ik mn data terug kan krijgen, ik eerst een flinke back-up ga draaien, zodat ik de volgende keer minder in de problemen kom!

[freggy]

Voor data recovery moet je ook eens kijken naar ddrescue kijken (er bestaan verschilllende versies van, ik geloof GNU ddrescue en dd_rescue enzo). Die gaan in tegenstelling tot dd foute sectoren overslaan. Die tooltjes vind je ook op de rescue cd RIP (Recovery Is Possible).

[Berik]

Bedankt voor de tip, ik ben nu echter al over de helft van mijn dd actie, dus ik laat die eerst even uit ratelen.
Als dit niet werkt, ga ik ddrescue eens proberen. De info die ik ff heb gegoogle'd zag er goed uit.

[Berik]

dd is net klaar, maar stopte helaas vlak voor het einde met de melding "no space left on disk"
De oude HD had nog zo'n 60GB vrij, en met het gebruikte commando zou die de lege ruimte niet copieren, waardoor je target ook iets kleiner als de source kon zijn. Dit vind ik dus maar bizar.

Ik heb even in cfdisk de gegevens van de twee schijven vergeleken en bleek dat cfdisk een verschillend aantal cylinders leest, terwijl de BIOS voor beide schijven dezelfde info geeft.

Weet iemand hoe dit kan komen?

Freggy heeft mij ddrescue aangeraden om te gebruiken, maar ik kan alleen nergens een man-page ervan vinden, dus ik weet niet zeker wat voor commando ik die mee moet geven, iemand suggesties?

[ Voor 17% gewijzigd door Berik op 23-01-2006 14:50 ]

[Berik]

Mijn poging met ddrescue is helaas ook mislukt.
Nu heb ik de schijf in mn workstation gezet en een partitie van 161GB vrij gemaakt. Op deze pc staat Kubuntu 5.10 en ik heb dus ddrescue geinstalleerd.

Het enige rare nu is dat hij de volgende melding geeft:

code:

berik:~$ sudo apt-get install ddrescue
Reading package lists... Done
Building dependency tree... Done
ddrescue is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

berik:~$ sudo ddrescue /dev/hdb1 /dev/sda4
sudo: ddrescue: command not found

Weet iemand waar dit aan ligt? Ik heb al de pc opnieuw opgestart, maar dat geeft hetzelfde resultaat.

[JeroenE]

Weet iemand waar dit aan ligt? Ik heb al de pc opnieuw opgestart, maar dat geeft hetzelfde resultaat.

Dat komt omdat het commando "dd_rescue" moet zijn. Dat heb ik overigens 5 seconden geleden ontdekt door "dpkg -L ddrescue" in te tikken

[Verwijderd]

Je moet ook dd_rescue aanroepen ipv ddrescue. De volgende keer, probeer eerst de eerste paar letters van het commando in te tikken, waarna je op tab drukt, eg:

code:

dd<tab> [shell vult dit aan tot dd_rescue]

Dit truukje kan je dit soort vragen besparen

[Berik]

Bedankt

Nu is hij bezig met uitvoeren van de actie
Ik wist niet dat Debian en KUbuntu andere commando's voor hetzelfde pakketje gebruikte, maar misschien is die van KUbuntu gewoon een nieuwere versie dan die van Debian.

Hij is nu in ieder geval bezig met copieren, ik zal wel laten weten of het is gelukt.

[Berik]

Uiteindelijk is het toch nog gelukt om alles terug te krijgen
(Voor zover ik door heb) ben ik alleen een paar spellen kwijt, die zal ik met de eerst volgende LAN dus opnieuw moeten fixen.
In ieder geval werken alle websites weer en is mijn (mysql) database nog intact.

Hierbij wil ik nog mijn dank uitroepen aan degenen die mij geholpen hebben met tips geven in dit topic

[it0]

Hoe is het nu uiteindelijk gelukt ? Heb je gewoon alles met dd_rescue kunnen doen?

[Verwijderd]

Ik weet niet hoeveel reiserfs verschilt tov ext2 of ext3, maar zelf gebruik ik ext3 en heb daar ook wel eens een rotte journal gehad na hardware errors.
Ik heb de schijf toen gemount als ext2 (dus negeert ie de journal-file) en kon toen nog ruim 94% veiligstellen door naar een andere disk over te zetten.

[Dutchess_Nicole]

Verwijderd schreef op woensdag 25 januari 2006 @ 09:48:
Ik weet niet hoeveel reiserfs verschilt tov ext2 of ext3, maar zelf gebruik ik ext3 en heb daar ook wel eens een rotte journal gehad na hardware errors.
Ik heb de schijf toen gemount als ext2 (dus negeert ie de journal-file) en kon toen nog ruim 94% veiligstellen door naar een andere disk over te zetten.

Helaas werkt dat niet voor ReiserFS, aangezien het niet gebaseerd is op een ander FS waar journalling aan vast geplakt is. Ik weet dat het probleem al opgelost is, maar ik heb onlangs ook iets dergelijks gehad, en ik heb het opgelost door

code:

reiserfsck --rebuild-tree -S /dev/hdx

te gebruiken. de -S flag staat voor scan-whole-partition, en dan gaat ie dus niet uit van de (verrotte) journal om bruikbare files te vinden. Met een gewone --rebuild-tree zou ik al mijn data kwijt geweest zijn, maar dankzij -S mis ik alleen mijn irssi config. (Die vast nog wel ergens in lost&found staat maar het boeit me niet echt.)

[Berik]

Eerst heb ik dus met:

code:

dd_rescue /dev/source /dev/target

alle data bit voor bit kunnen kopieren (op iets van 5MB na die op bad blocks zat)

Daarna heb ik op de target:

code:

reiserfsck --rebuild-tree /dev/target

uitgevoerd. Deze heeft (voor mijn idee erg snel, ongeveer 30min) de hele tree opnieuw opgebouwd. Ik zag tijdens het eerste deel maar een paar foutmeldingen. Daarna ging hij (denk ik) proberen om alle data te identificeren en in de journal/superblock (weet niet goed hoe het zit met die namen) te zetten. Hierbij stroomde er heel veel meldingen over mijn scherm, maar voor zover ik kon lezen, stond er vooral iets van een filename+path met de melding succesful of iets dergelijks.

De partitie was de /home van mijn server. Hierop stonden een aantal websites + mysql-database, een aantal home-directories voor ftp-accounts en mijn eigen home-directory. (Ik had via symlinks de /var/www en mysql directory's naar /home/www en /home/mysql gelinkt, zodat als ik een keer de server zou vern**ken, dat ik nog wel alle data zou hebben)
- Alle websites + de database zijn zover ik weet helemaal terug gekomen.
- Van de rest van de home-dir's zijn er slechts van 2 stuks bestanden en directory's in lost+found (wel zo'n 30GB) Een van deze home-dirs had een aantal spellen, maar die krijg ik op de volgende LAN-party wel weer. De andere home-dir, was een back-up en tegelijk ftp-account voor mijn muziek. Deze had echter al problemen en het betrof hier eigenlijk alleen spul dat ik niet kon weggooien door (waarschijnlijk) ergens een badblock, het was dus slechts een kopie van de muziek, dus ik ben niks kwijt.

Ik ben nu dus erg gelukkig met dit resultaat en de server is weer volledig online.

Ik weet alleen nog niet wat ik met de oude schijf ga doen, kan ik deze nog repareren (badblocks gewoon uitschakelen) of mag hij echt een enkeltje richting HD-hemel?

[Aapzak]

Heb je na je huidige avontuur nog zin in een experiment? Ik zou die schijf gewoon meteen weggooien.

[Verwijderd]

of als onderzetter gebruiken...