Recupero dati con TestDisk

Storia di un recupero dati..

Problema

MI è stato chiesto di recente di recuperare dei dati da un disco rigido sata da 500G; per windnows il disco risultava vuoto e chiedeva, come prevedibile di formattarlo.




Prima analisi

Da linux ho cercato di ricavare qualche info con il comando "fdisk -l", scoprendo che il disco conteneva una partizione estesa al cui interno si trovava una FAT16 da 500G!!

Alla fonte

Inquisendo il proprietario si è scoperto che un amico dell'amico aveva messo questo disco su un pc di provenienza XYZ e che il PC lo aveva accettato solo configurando il controller RAID in modo da tenere il disco come unico componente di un volume jbod. JBOD!
Naturalmente il PC in questione è sparito in una voragine, nulla si sa di lui e non esiste più.

Il manufatto atlantideo svelato

Avevo quindi a che fare con un "hardware jbod" di un pool costituito da un solo disco, ma ero ottimista; il raid1 hardware spesso non crea problemi e il singolo disco inserito in un PC anche in configurazione non raid risulta generalmente accessibile ed usabile, essendo il JBOD una mera concatenazione di dischi speravo che la partizione NTFS fosse li, integra, liscia, intonsa, al massimo preceduta da immondizia lasciata dal controller.

Fase 0

Essendo un malfidente e un pessimista cronico ho prima effettuato da Linux una copia dell'MBR e quanto di vitale, quotando http://www.partimage.org/Partimage-manual_Backup-partition-table (riporto esempio, differisce dal mio caso dove il discpositivo è /dev/sdc):

dd if=/dev/hda of=backup-hda.mbr count=1 bs=512
It will produce a very small, but very important file: 512 bytes of data. Now, we will save entries of the extended partitions:
sfdisk -d /dev/hda > backup-hda.sf

questi files sono necessari per ripristinare la struttura delle partizioni in caso di errori

Tentativo 1, montare il JBOD su Linux

Il primo tentativo era verificare (più per curiosità) se il formato in qualche modo coincideva con il --linear del mdadm di Linux (che da quanto sapevo dovrebbe corrispondere al jbod).
Naturalmente Mdadm (mdadm -Q /dev/sdc) dice che non c'è nulla, ma ero pessimista pure io.

Tentativo 2

Vari tentativi con utility Windows(falliti)

Tentativo 3 (che invero sapevo che doveva essere il primo) l'utility TestDisk

Questa prodigiosa utility, sommo taumaturgo, ineguagliabile panacea, è sicuramente l'implementazione informatica di sciamanici riti di guarigione.
Dopo aver scaricato da http://www.cgsecurity.org/wiki/TestDisk_Download la versione 6.13 sulla mia fedele OpenSuse 11.2 e eseguito testdisk come root, mi è bastato selezionare il device (nel mio caso /dev/sdc) e lanciare la "Quick Analisys".

Figura di esempio, non legata al caso specifico

TestDisk ha subito identificato un unica partizione NTFS da 500G!!
Certo di lavorare in sicurezza, grazie al backup già fatto nella Fase0 dell'MBR, ho fatto scrivere la nuova tabella a TestDisk sul disco con il comando "Write" (Oh dolce Semplicità, a volte uno dimentica quanto sei bella!)
Finito bisogna dire a linux di caricare la nuova tabella delle partizioni, con il seguente comando (/dev/sdc nel mio caso è il nome del device che stavo recuperando):
partprobe /dev/sdc
A questo punto resta da verificare il successo!
Il resto è discesa, riavviare in windows ed effettuare un chkdsk (readonly, ovvero senza l'opzione /F) per verificare che tutto sia a posto.
Anche il comando smartctl utilizzato da linux conferma che il disco è vetusto ma non imploso.
Windows è in grado di montare la nuova partizione e di accedere ai files, perfettamente integri.
Finito in 10 minuti.

Conclusioni

TestDisk è una grande applicazione per il recupero delle partizioni e fa molto, molto di più di quanto vi ho raccontato. Tenetevela sempre a portata di mano(e mi pare sia anche inclusa in systemrescuecd).


Note per i posteri

Il recupero dati non si fa così , non ci si accontenta mai del semplice backup dell'MBR e poi lavorando direttamente sul disco originale ma si deve sempre fare una copia raw con ddrescue e creare un file immagine del disco.

Tutte le operazioni successive dovrebbero essere fatte su questa copia perché le operazioni di recupero sono operazioni di lettura/seek/scrittura molto intense ed è possibile che il disco decida di mollarvi durante l'operazione; ddrescue in questo caso è un tool grandioso e gestisce in modo intelligente i bad sector.

Nel mio caso ho deciso di lavorare a cuore aperto per più motivi:

1. non avevo un posto dove mettere 500G di immagine
2. sapevo dalle info Smart e dal racconto che il disco non era fisicamente danneggiato(la causa del malfunzionamento era l'estrazione dal PC atlantideo)
3. non avevo molto tempo a disposizione
4. c'erano foto ma il valore dei dati non era altissimo (alias non erano dati miei :-) )