Rescatant un disc espenyat

Arrel del que contava s’altre dia que em va passar amb un disc espenyat, vaig decidir intentar rescatar-ne la informació.

Contaré el procés seguit amb la intenció d’evitar que algú que hagi de fer una operació similar perdi el temps de la manera que el vaig perdre jo :) .

El primer que et diu qualsevol manual d’anàlisi forènsica bàsica és que has de fer una imatge del disc espenyat a un disc bò per a començar la feina.

No vaig pensar-m’ho massa i vaig tirar de dd. Primer error. dd avortava en trobar el primer error de lectura (per sort ¿?, els primers i únics errors eren just al principi del disc). Soŀlució: dd conv=noerror.

Aquest va esser el segon error: intrigat per saber que faria dd amb els blocs que no pogués llegir vaig buscar un poc i vaig llegir (ja no recordo on) que simplement ignora els blocs defectuosos i no els escriu a l’arxiu de destinació. Si estàs intentant salvar una imatge d’un filesystem, això és una de les pitjors coses que pots fer (te deixarà una imatge totalment destroçada).

Per diversos llocs parlaven de dd_rescue; aptitude install ddrescue (després d’un apt-cache search dd_rescue) i cap endavant.

Primer de tot, dd_rescue no avorta en trobar errors de lectura, i, segons he llegit, escriu zeros al lloc dels blocs que no ha pogut llegir. Utilitza dd amb un tamany de bloc gran i en trobar errors de lectura re-intenta llegir aquests blocs amb un tamany de bloc més petit (per a intentar recuperar el màxim d’informació dels blocs que han fallat inicialment).

Un petit problema que me vaig trobar va esser el següent: mentres dd_rescue treballava el meu fillol, que estava jugant al supertux, va tancar-me la finestra del xfce4-terminal (despres d’un parell d’hores de treball, ja n’havia llegit la meitat dels 80GBytes).

Nooooooooo :D (nota mental: usar sempre screen per a aquestes operacions tant llargues; inmensament útil també per quan ho fas remotament via ssh i la sessió s’interromp o es talla la connexió).

Aleshores vaig buscar un poc més d’informació i va esser quan vaig trobar el dd_rhelp que és un shell script que utilitza dd_rescue però que, mitjançant un arxiu de log, permet interrompre la feina i continuar-la més endavant.

Vaig posar-lo a treballar mentres investigava un poc més. La següent troballa va esser GNU ddrescue (aptitude install gddrescue). Sí, els noms dels paquets de Debian són totalment confosos.

Aleshores, investigant quin dels dos era millor vaig arribar a aquesta pàgina.

La conclussió és ben clara: GNU ddrescue. Toooooorna a començar.

Si hagués buscat un poc més abans de començar potser l’hagués trobada al principi i m’hagués estalviat perdre les hores que vaig perdre i, sobre tot, fer treballar intensament a un disc al que no li convé fer esforços inútils degut al seu estat de salut.

D’aquesta pàgina que comentava que vaig trobar, me va cridar moltíssim l’atenció el truc d’utilitzar l’arxiu de log amb els sectors defectuosos generat en llegir el disc per a escriure-hi zeros i fer que el firmware del disc (que comentava en Paco a l’altre apunt) els reubiqui a una altra part i així poder seguir utilitzant-lo.

Independentment de que sigui arriscar-se a que el disc acabi de fallar del tot més endavant, me va parèixer molt enginyós.

En actualitzacions posteriors d’aquest mateix apunt ja contaré si he aconseguit l’objectiu final de recuperar la informació o no:

  • 31-12-2009 18:00 El ddrescue ha aconseguit treure la imatge del filesystem, només tenia defectuosos un total de 12 blocks d’un KByte (repartits en 3 grups iguals de 4KB al principi del disc). Ara se suposa que n’hauria de fer una còpia per a poder manipular-la sense por de rompre-la i intentar recuperar-ne el contingut. El problema és que ara mateix aquí no tenc espai en disc disponible per a copiar-la. Anyway, això ja ho deixaré per a un altre dia…
  • 01-01-2010 09:15 Ha reviscolat!. Tenia 2 discs de 80GB seagate just un poquet més petits que la imatge a tractar. Fent un raid0 amb mdadm vaig poder-ne fer la còpia i passar-li el fsck.ext3 sense risc: aquesta vegada s’ha portat bé!! :P . Ara ja puc montar el filesystem. Com deia aquell: «prueba superada, 1000 Km.».

Ha estat divertit! :)

This entry was posted in Programari Lliure, Tècnics. Bookmark the permalink.

4 Responses to Rescatant un disc espenyat

  1. Paco Ros says:

    Ostres, molt interessant. Quan ho vaig haver de fer jo, vaig tenir sort i amb un “dd” normal m’en vaig sortir. Clar, amb la imatge va ser tot més fàcil: montar en loop i copiar.

    Molt bo el truc dels zeros, no m’el sabia :-)

  2. Kiko Piris says:

    # Rescue Logfile. Created by GNU ddrescue version 1.11
    # current_pos current_status
    0x08A8AE00 +
    # pos size status
    0×00000000 0×00008000 +
    0×00008000 0×00001000 -
    0×00009000 0×00008000 +
    0×00011000 0×00001000 -
    0×00012000 0x08A78000 +
    0x08A8A000 0×00001000 -
    0x08A8B000 0x130CCB4E00 +

    Les línies acabades en – són els sectors defectuosos.

  3. Kiko Piris says:

    # fsck.ext3 /dev/loop0
    e2fsck 1.41.9 (22-Aug-2009)
    Superblock has an invalid journal (inode 8).
    Clear? yes

    *** ext3 journal has been deleted – filesystem is now ext2 only ***

    Superblock has_journal flag is clear, but a journal inode is present.
    Clear? yes

    /dev/loop0 contains a file system with errors, check forced.
    Pass 1: Checking inodes, blocks, and sizes
    Root inode is not a directory. Clear? yes

    Journal inode is not in use, but contains data. Clear? yes

    Pass 2: Checking directory structure
    Entry ‘..’ in ??? (40065) has deleted/unused inode 2. Clear? yes

    Pass 3: Checking directory connectivity
    Root inode not allocated. Allocate? yes

    Unconnected directory inode 40065 (…)
    Connect to /lost+found? yes

    /lost+found not found. Create? yes

    Pass 4: Checking reference counts
    Inode 40065 ref count is 10, should be 9. Fix? yes

    Pass 5: Checking group summary information
    Block bitmap differences: -(14–8218) -(1837592–1837593)
    Fix? yes

    Free blocks count wrong for group #0 (65535, counted=8205).
    Fix? yes

    Free blocks count wrong for group #56 (0, counted=2).
    Fix? yes

    Free blocks count wrong (5169907, counted=5178115).
    Fix? yes

    Inode bitmap differences: -(12–13)
    Fix? yes

    Free inodes count wrong for group #0 (114, counted=117).
    Fix? yes

    Directories count wrong for group #0 (3, counted=2).
    Fix? yes

    Free inodes count wrong (77995, counted=77998).
    Fix? yes

    Recreate journal? yes

    Creating journal (32768 blocks): Done.

    *** journal has been re-created – filesystem is now ext3 again ***

    /dev/loop0: ***** FILE SYSTEM WAS MODIFIED *****
    /dev/loop0: 210/78208 files (9.5% non-contiguous), 14865501/20010815 blocks

  4. paurullan says:

    Aquest tipus de tasques són de les coses divertides de la branca de sistemes que són molt mal de practicar :D

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>