Spesso mi capita di sentirmi chiedere di recuperare importantissimi dati (fare i backup no, eh?) da dischi usb maltrattati, portatili caduti e situazioni simili. A volte i supporti sono talmente mal conciati da rendere impossibile qualunque tentativo di recupero a livello hobbystico, ma spesso si riesce a salvare buona parte dei dati.
In questo articolo voglio presentarvi una carrellata degli strumenti che uso in questi casi.
dd_rescue
E’ fondamentalmente una versione della classica utility unix dd con la caratteristica di possedere una maggiore tolleranza agli errori in lettura. Lo scopo è quello di estrarre i dati dal supporto per trasferire il leggibile su un file, creando una sorta di immagine del supporto, o su un altro device a blocchi, creando in effetti un clone. Gli eventuali blocchi danneggiati vengono sostituiti nella destinazione da blocchi completamente azzerati.
Devo segnalare che esistono due differenti versioni di questo software: uno sviluppato da Kurt Garloff e l’altro da Antonio Diaz Diaz. I pacchetti debian sono rispettivamente ddrescue e gddrescue. I confronti che ho potuto effettuare personalmente confermano le opinioni di altri utenti che ho letto in rete: gddrescue è decisamente più veloce di ddrescue (nell’ultima prova è stato all’incirca il 50% più veloce) e sembra dare risultati migliori in termini di numero di settori recuperati.
per gli utenti debian/ubuntu : ddresque
fsck
fsck non ha certo bisogno di una mia presentazione: è lo strumento principale di unix per la manutenzione dei filesystem. E’ in realtà composto da una suite di programmi, ciascuno dei quali lavora su uno specifico filesystem: per esempio fsck.ext3 lavora su filesystem ext3, fsck.vfat su FAT16/FAT32, ecc: Il suo compito è quello verificare la consistenza della struttura del filesystem e risolvere gli eventuali problemi. Può lavorare sia su device a blocchi che su file immagine. E’ da notare che tuttora non ne esiste una versione per NTFS.
Essendo i filesystem molto differenti tra loro anche le opzioni utilizzabili col programma variano notevolmente e per tanto vi rimando alla pagina di manuale per ciascuno di essi.
testdisk (sito)
Questo potente tool interattivo a tutto schermo permette di ricostruire in modo semi-automatico una tavola di partizione danneggiata. Analizza i settori iniziali di ciascun cilindro del disco alla ricerca di quelli che potrebbero essere l’inizio di una partizione rilevando in automatico il tipo di filesystem e le dimensioni. Supporta moltissimi filesystem e su alcuni è anche in grado di correggere problemi di consistenza.
photorec (sito)
Ha una interfaccia interattiva simile a testdisk. Consente di recuperare file senza fare alcun affidamento sul filesystem. E’ utile quando il filesystem è pesantemente danneggiato e/o non è supportato dagli altri strumenti. Sarebbe da impiegare come ultima alternativa dato che è in grado di recuperare solo alcuni tipi di file e non ne mantiene i nomi originali.
smartctl (sito)
Non è impiegabile direttamente per il recupero dei dati ma è utile per valutare le condizioni fisiche di un disco. E’ lo strumento che consente di interagire con il sistema SMART ormai integrato in tutti gli hard disk recenti avviando i test interni ed interrogando i registri che tengono traccia di errori, tempo di vita del disco, temperatura, statistiche sulle prestazioni ecc:. E’ da notare che spesso gli adattatori USB-IDE non supportano SMART e quindi è consigliabile l’uso di un normale controller IDE.
La procedura
La prima operazione da compiere consiste nel preparare l’ambiente di lavoro: individuo un pc con un hardware affidabile che abbia un lettore cd da cui avviare, un disco fisso di appoggio di dimensioni superiori a quelle del supporto da recuperare, almeno un altro connettore IDE libero (cerco sempre di evitare gli adattatori USB-IDE) e possibilmente una scheda di rete per scaricare eventuali strumenti necessari.
Avvio una qualunque distro live (io mi trovo bene con finnix, anche se alcuni degli strumenti che ho citato non sono inclusi ma si possono installare al volo con apt) e preparo il supporto di appoggio formattandolo in ext3 per non avere problemi con le dimensioni dei file immagine che potremmo aver bisogno di creare.
Nel caso di un hard disk o un pendrive usb controllo il partizionamento del supporto per individuare la partizione che contiene i dati che mi interessa recuperare: ad esempio, se il device è /dev/hdd:
fdisk -l /dev/hdd
Se questa operazione fallisce o se il risultato non è ragionevole significa che il MBR è corrotto e quindi non posso tentare il mount in sola lettura, altrimenti provo a montare in read-only la partizione in esame: supponendo che sia la prima:
mkdir -p /mnt/speriamo
mount -o ro /dev/hdd1 /mnt/speriamo
Se il mount va a buon fine non serve andare oltre: basta copiare tutti i file che ci servono sul disco di appoggio, altrimenti bisogna procedere con l’estrazione di una immagine del supporto su cui poter lavorare anche in scrittura: supponendo che il disco di appoggio sia montato su /mnt/spazio, se fdisk -l non ha creato problemi posso creare una immagine della sola partizione interessata:
ddrescue /dev/hdd1 /mnt/spazio/immagine.img
se invece il MBR è corrotto o non leggibile devo clonare l’intero disco:
ddrescue /dev/hdd /mnt/spazio/immagine.img
Se ho estratto l’intero disco, devo ripristinare una tavola di partizione corretta, altrimenti posso saltare questo passo:
testdisk /mnt/spazio/immagine.img
Faccio fare una scansione dell’immagine alla ricerca dei possibili punti di inizio delle partizioni e, una volta verificato che i valori individuati sono ragionevoli, salvo il nuovo MBR. Può essere necessario impostare a mano la geometria del disco quando si lavora con testdisk: sui dischi meno recenti è riportata sull’etichetta, mentre su quelli più attuali è riportata solo la dimensione in blocchi: in questo caso il firmware del disco usa una geometria fittizia per mappare l’indirizzo LBA dei blocchi: i settori per traccia sono sempre 63 e le testine 255: il numero di cilindri si calcola dividendo la dimensione in blocchi per 16065.
Ricostruita la tavola di partizione posso estrarre l’immagine della partizione che mi interessa: per fare questo devo sapere dove inizia e dove finisce:
sfdisk -d /mnt/spazio/immagine.img
Annoto start e size della mia partizione: supponendo che i valori siano rispettivamente 63 e 156296322 posso estrarre l’immagine sovrascrivendo quella completa ottenuta in precedenza:
rm -f /mnt/spazio/immagine.img
ddrescue -i 63b -s 156296322b /dev/hdd /mnt/spazio/immagine.img
A questo punto mi trovo con il file /mnt/spazio/immagine.img contenete l’immagine della partizione che mi serve recuperare. Posso tentare un fsck: supponendo che il filesystem sia FAT:
fsck -t vfat /mnt/spazio/immagine.img
Se fsck ha successo è possibile montare in loopback l’immagine:
mkdir -p /mnt/speriamo
mount -o loop,ro /mnt/spazio/immagine.img /mnt/speriamo
Se l’immagine può essere montata, il lavoro è terminato, altrimenti l’ultima possibilità consiste nell’uso di photorec:
mkdir -p /mnt/spazio/files
cd /mnt/spazio/files ; photorec /mnt/spazio/immagine.img
Una volta trasferiti i dati su un supporto sicuro, se il problema era causato da blocchi danneggiati si può tentare di rimettere in condizioni utilizzabili il disco forzando la rimappatura dei blocchi guasti usando i tool specifici del produttore del disco per eseguire una formattazione a basso livello. In alternativa ai tool specifici possiamo tentare con un semplice:
dd if=/dev/zero of=/dev/hdd bs=512
quando il disco in una operazione di scrittura individua un blocco danneggiato tenta in automatico di rimapparlo su un altro blocco. Terminata la formattazione o il dd possiamo (preferibilmente dopo un riavvio) verificare se il firmware ha effettivamente rimappato dei blocchi:
smartctl -A /dev/hdd
e controllare il valore del parametro Reallocated_Sector_Ct che rappresenta il numero di settori che sono stati giudicati non utilizzabili e quindi rimappati. In ogni caso sarebbe preferibile non riutilizzare un disco con settori danneggiati per mantenere dati importanti.
Anche se spesso questi strumenti danno buoni risultati è sempre importante adottare una politica di backup commisurata all’importanza dei dati che dobbiamo gestire: un buon backup ci può far risparmiare molte ore di lavoro e molti grattacapi.
[ad]