In un precedente post ho spiegato come recuperare dati da un supporto danneggiato utilizzando il programma GNU ddrescue. Sfortunatamente se il recupero non è completo ci possono essere dei file danneggiati all’interno del materiale recuperato. In questo post utilizzeremo nuovamente il programma ddrescue per verificare quanto e quale del materiale sia stato effettivamente recuperato.
Ho appena perso un disco da 500 GB con al suo interno una partizione piena circa al 50%, il disco ha cominciato improvvisamente a manifestare chiari problemi sia in lettura sia in scrittura, per cui prima che si rompesse del tutto ho voluto eseguire una copia dei dati al suo interno. Chiaramente la copia dal filesystem risultava impossibile per via degli errori restituiti dal dispositivo, per cui ho preso un nuovo disco della stessa capacità ed ho avviato il fido ddrescue.
Dopo circa 1 giorno il contenuto del disco era stato copiato quasi del tutto poco meno dei 500GB totali (ddrescue copia tutti i settori del dispositivo, indipendentemente dal filesystem, per cui sono stati copiati anche i blocchi vuoti) , ma mancavano circa 70MB che restituivano errori in lettura. Ho avviato la seconda passata di ddrescue con le opzioni -d e -r 2 per tentare il recupero di questi ulteriori 70 MB ed ho lasciato andare per circa 3 giorni. Quando mancavano solamente 11MB (ma purtroppo sparsi in 12000 settori differenti) anche ddrescue si è arreso e rimanevano questi dati non copiati. Una volta montato il filesystem recuperato il problema a questo punto era capire quali file erano integri e quali no, infatti leggendo il log prodotto da ddrescue si poteva leggere quanto segue
# Rescue Logfile. Created by GNU ddrescue version 1.11 # current_pos current_status 0x14E248400 - # pos size status 0x00000000 0x0FD49800 + 0x0FD49800 0x00000400 - 0x0FD49C00 0x0000FA00 + 0x0FD59600 0x00000600 - 0x0FD59C00 0x000B4E00 + 0x0FE0EA00 0x00000200 - 0x0FE0EC00 0x0000F200 + 0x0FE1DE00 0x00000200 - 0x0FE1E000 0x00000200 + 0x0FE1E200 0x00000400 - 0x0FE1E600 0x000B4E00 + 0x0FED3400 0x00000400 - 0x0FED3800 0x0000F000 + 0x0FEE2800 0x00000600 - 0x0FEE2E00 0x000C4000 +
In questo log ad ogni – sulla terza colonna corrisponde una parte di disco non recuperata che inizia all’indirizzo nella prima colonna e la cui lunghezza in bytes è espressa nella seconda colonna. Praticamente nel disco mancavano blocchetti di pochi bytes (in media 400) in 11000 indirizzi diversi il che indica che è, da un punto di vista probabilistico, impossibile che tutti i file siano stati recuperati correttamente.
Per stabilire con certezza quali file siano corrotti ho utilizzato la modalità fill di ddrescue. La prima cosa da fare è quella di montare il filesystem recuperato (se si ha la possibilità meglio eseguire tutte le operazioni su un’ulteriore copia) in modalità readonly e calcolare i checksum dei file presenti nel dispositivo. Nel mio caso il disco recuperato era sdc per cui ho eseguito questi comandi allo scopo
# mount-o ro /dev/sdc1 /mnt/rescued # find /mnt/rescued/ -type f -print0 | xargs -0 -n 1 md5sum >> rescued.md5.txt
In questo modo ho salvato tutti i checksum dei file presenti nella partizione /dev/sdc1 nel file rescued.md5.txt. Questo comando a seconda della dimensione totale dei files può richiedere parecchio, nel mio caso circa 2 ore e mezza. A questo punto ho invocato nuovamente ddrescue in modalità fill in modo da riempire tutti i buchi presenti nell’hard disk con una stringa fissa, in modo da cambiare l’md5 dei file coinvolti. La funzione md5 ci garantisce che anche cambiando un solo bit in un file l’hash generato cambia radicalmente per cui il rischio che un file mantenesse lo stesso hash era praticamente zero (è molto più probabile vincere al superenalotto…). Per riempire i blocchi danneggiati ho eseguito i seguenti comandi
# umount /dev/sdc1 # echo -n "BAD SECTOR " > tmpfile # ddrescue --fill=- tmpfile /dev/sdc rescued.log
Questa operazione è molto veloce in quanto avviene su un disco funzionante, per cui in meno di un minuto ddrescue ha completato il suo lavoro. A questo punto non resta che rimontare il filesystem e verificare quali file sono cambiati su disco, per fare ciò sono sufficiente questi comandi.
# mount -o ro /dev/sdc1 /mnt/rescued # md5sum -c rescued.md5.txt > checklist.txt
Passate altre 2 ore e mezza circa la lista è pronta, basta leggere il file checklist.txt per capire quali file sono integri e quali no, infatti il contenuto del file è all’incirca questo
/mnt/rescued/IMG_0096.JPG: OK /mnt/rescued/IMG_0247.jpg: OK /mnt/rescued/IMG_0249.jpg: FAILED /mnt/rescued/IMG_0253.jpg: OK /mnt/rescued/IMG_0256.jpg: OK /mnt/rescued/IMG_0482.JPG: OK /mnt/rescued/IMG_0485.JPG: OK /mnt/rescued/IMG_0486.JPG: OK /mnt/rescued/IMG_0487.JPG: OK /mnt/rescued/IMG_0489.JPG: OK /mnt/rescued/IMG_0490.JPG: FAILED /mnt/rescued/IMG_0491.JPG: FAILED /mnt/rescued/IMG_0492.JPG: FAILED /mnt/rescued/IMG_0493.JPG: FAILED
In alternativa si possono costruire le liste dei file integri e di quelli rovinati utilizzando grep in questo modo
# grep OK$ checklist.txt > files.ok.txt # grep FAILED$ checklist.txt > files.bad.txt
