Il recupero dati dai file system di Linux

Transcript

1 Il recupero dati dai file system di Linux Bartosz Przybylski Artykuł opublikowany w numerze 3/2005 magazynu hakin9. Zapraszamy do lektury całego magazynu. Wszystkie prawa zastrzeżone. Bezpłatne kopiowanie i rozpowszechnianie artykułu dozwolone pod warunkiem zachowania jego obecnej formy i treści. Magazyn hakin9, Software-Wydawnictwo, ul. Piaskowa 3, Warszawa, pl@hakin9.org

2 Il recupero dati dai file system di Linux Bartosz Przybylski Quando, per esempio in seguito ad un attacco al sistema, ci capiterà di perdere in Linux file importanti, non dovremo disperare. Esistono molti metodi per recuperare i dati. Anche se spesso è un lavoro impegnativo, un buon assortimento di strumenti ci permetterà di recuperare anche contenuto completo di un file system danneggiato. Difesa Il nostro server è stato vittima di pirata informatico. L'intruso è stato così malvagio da cancellare dal nostro disco parecchi file importanti, tra questi il programma sul quale abbiamo lavorato un paio di mesi. Prima di fare una reinstallazione del sistema (per assicurarci che non rimanga in esso nessun codice maligno lasciato dall intruso) bisogna cercare di recuperare i dati. Per farlo, dobbiamo servirci di alcuni strumenti che ogni distribuzione di Linux contiene. Strumenti utili Il primo elemento indispensabile è un insieme di strumenti per poter operare sui file system ext2 e ext3 si tratta del pacchetto e2fsprogs. Per noi il più importante sarà debugfs che, come indica il nome, serve per fare il debug dei file system. Di default (per la piattaforma x86) tutto il pacchetto viene installato insieme al sistema. Il successivo strumento indispensabile è reiserfsck che fa parte del pacchetto reiserfsprogs e che serve per editare il file system ReiserFS. Anche questo pacchetto dovrebbe essere allegato al sistema. Invece il programma dd ci servirà per recuperare tutta la partizione con il file system ReiserFS e come alternativa per recuperare dati dai vari tipi dei file system. La preparazione di una partizione per recuperare dati Indipendentemente dal file system dal quale recupereremo i dati, la prima operazione da eseguire sarà quella di smontare la partizione sulla quale lavoreremo. Per avere almeno una parziale certezza che i nostri dati non sono stati in alcun modo danneggiati, dovremo fare questo passo al più presto dopo l'eliminazione dei file. Dall'articolo imparerai... come recuperare dati dai file system di tipo ext2 e ext3, in che modo salvare file dalla partizione Reiser- FS. Cosa dovresti sapere... dovresti saperti servire della linea di comando in Linux, dovresti conoscere le basi della struttura dei file system. 60

3 Il recupero dei dati I termini legati alla gestione dello spazio su disco Gli inode L'inode è una struttura di dati utilizzata nei file system di Linux per descrivere un file. Di essa fanno parte: il tipo di file file ordinario, directory o file di dispositivo, l'identificativo UID di un proprietario, la lista dei blocchi del disco e i loro frammenti che compongono un file. Possiamo considerare l'inode come un particolare identificatore di un file su disco, di cui il sistema si serve per trovare un file richiesto. Ogni file su una data partizione ha un solo inode subordinato. Il blocco del disco Il blocco del disco è una parte di spazio su una partizione, che conserva informazioni. La dimensione di un blocco è definita da un utente durante la divisione del disco in partizioni. Può però essere cambiata usando i programmi per la modifica di un dato file system. Contrariamente agli inode, molti blocchi possono appartenere ad un solo file. Il journaling Il journaling (ingl. journaling, registrazione dei cambiamenti) è uno dei metodi per conservare dati su disco. Il principio è semplice ma particolarmente efficace. Lo schema di funzionamento, un po' semplificato, è visibile nella Fig. 1. Come si vede, File1 dopo la modifica non cambierà i dati compresi nella sua vecchia posizione (contrariamente ai file system senza il journaling), ma i dati saranno registrati in una nuova posizione. Questa è una grande cosa, infatti quando giungeremo alla conclusione che la versione precedente era migliore, anche dopo notevoli modifiche, saremo in grado di recuperare la forma originale di un file. Per smontare una partizione basta umount /dev/hdax (dove X è il numero della partizione dalla quale sono stati cancellati i dati, nel nostro caso essa avrà il valore 10). Se però durante quest'operazione otterremo il messaggio: # umount /dev/hda10 umount: /tmp: device is busy questo significa che qualche processo utilizza questa partizione. Ci sono due le vie d'uscita da una tale situazione. Una di queste è uccidere il processo che utilizza una data partizione. Prima però bisogna controllare quali processi bloccano la partizione. Utilizzeremo il programma fuser, che serve per identificare utenti e processi che adoperano determinati file o socket: di ottenere in output dati più dettagliati, con ciò, invece dei soli numeri PID, vedremo anche gli argomenti null dei programmi. Se constateremo che i processi ci sono inutili, basterà eliminarli con il comando: # fuser -k -v -m /dev/hda10 Se invece preferiamo terminare i processi normalmente, dovremo eseguire: # fuser -TERM -v -m /dev/hda10 Un modo alternativo per smontare un file system è quello di metterlo in modalità RO (read only). In questo modo i nostri file non potranno essere sovrascritti. Per eseguire quest'azione, dovremo impartire il seguente comando: # mount -o ro, remount /dev/hda10 Attenzione: il comando non funzionerà, se la partizione è la root directory, ossia il file system principale. Se in effetti è così, dovremo informare di questo il programma mount, affinché non registri i cambiamenti nel file /etc/mtab. A questo scopo aggiungiamo il parametro -n. Il recupero dati in Ext2fs Il primo tipo di file system del quale ci occuperemo è ext2fs (per saperne di più su questo e su altri file system, conviene dare un'occhiata al Riquadro I file system di Linux). Cominciamo trovando gli inode cancellati. La ricerca degli inode cancellati Per fare questo passo utilizzeremo il programma debugfs dal pacchetto e2fsprogs. Avviamo l'applicazione aprendo la partizione richiesta: # debugfs /dev/hda10 Quando apparirà un messaggio di prompt, dovremo eseguire il comando lsdel, che ci farà vedere tutti i file cancellati dal momento della creazione di questa partizione (nel caso di sistemi pubblici questa lista può avere migliaia di righe e la sua compilazione esige a volte un po' di tempo). Adesso esclusivamente in base alla data della cancellazione, # fuser -v -m /dev/hda10 L'opzione -m /dev/hda10 imporrà al programma di verificare quali servizi utilizzano la partizione hda10. Invece l'opzione -v (verbose) ci permetterà Fig. 1: Lo schema di funzionamento del journaling 61

4 Difesa Listing 1. L'effetto del comando lsdel del programma debugfs debugfs: lsdel Inode Owner Mode Size Blocks Time deleted /14 Tue Feb 15 19:13: /5 Tue Feb 15 19:13: deleted inodes found. debugfs: Listing 2. Il riversamento dei dati recuperati su di un file debugfs: dump <24> /home/aqu3l/recovered.000 debugfs: quit # cat /home/aqu3l/recovered.000 all'uid dell'utente e alla dimensione possiamo dedurre quali file appartenevano a noi e quali vogliamo recuperare. Una buona idea è scrivere o stampare i numeri degli inode. Guardiamo da vicino l'esito del comando lsdel (vedere Listing 1). Le colonne nei risultati del comando lsdel si presentano in questo ordine: il numero dell'inode (inode), il proprietario (owner), le opzioni d'accesso (mode), la dimensione in byte (size), il numero di blocchi occupati (blocks), il tempo di cancellazione (time deleted). Come si vede, i file cancellati hanno i numeri degli inode pari a 20 e 24. Cercheremo di recuperare proprio questi dati. Il recupero dei dati Adesso possiamo provare a recuperare l'inode 24 tramite il riversamento (ingl. dump) dei dati su un altro file. Come si vede nel Listing 1, occupa 5 blocchi. È un'informazione abbastanza importante questo metodo non sempre può essere efficace con file che occupano più di 12 blocchi. L'esempio di tale recupero si trova nel Listing 2. Tra le parentesi angolari indichiamo il nome del file o il numero dell'inode. Il secondo parametro è il nome del file di destinazione bisogna indicarlo con il percorso I file system di Linux d'accesso completo, quindi l'abbreviazione ~/ non avrà effetto. Una volta eseguito il comando digitiamo quit ed andiamo a leggere il contenuto del file recuperato. Spesso alla fine del file recuperato possono apparire diversi caratterispazzatura; sono i resti di altri file sovrascritti. Si possono eliminare con l'uso di un qualsiasi editor di testo. Questo metodo è ovviamente efficace soltanto nel caso di file di testo. C'è rimasto da recuperare un file dall'inode 20 (vedere Listing 1). Occupa 14 blocchi e, come abbiamo menzionato, il metodo del trasferimento dei dati da un inode che conta più di 12 blocchi non termina con successo (vedere Riquadro I blocchi e la loro gerarchia in ext2fs). Perciò per recuperare il 20º inode useremo il programma dd. Prima di recuperare il file verifichiamo i dati principali, cioè i numeri dei blocchi e la dimensione del blocco sulla partizione. Per verificare la dimensione del blocco utilizzeremo il comando: # dumpe2fs /dev/hda10 \ grep "Block size" Ext2fs Il file system, il cui principale creatore è Theodore Ts'o. Non ha il journaling. È stato progettato in modo tale che sia possibile recuperare dati da una partizione. È uno dei più popolari (proprio a causa della facilità di recupero) file system di UNIX. Ext3fs In teoria è la versione successiva di ext2. Nonostante non sia stato progettato così bene come il suo predecessore, offre la possibilità del journaling. Uno dei principali difetti è che gli sviluppatori non vi hanno previsto in ext3 la possibilità di recuperare un file cancellato. Questo succede perché il sistema dopo aver segnato il file come cancellato ne libera anche l'inode relativo, in questo modo rendendo impossibile leggere gli inode eliminati. ReiserFS Il file system creato dalla NameSys, più precisamente da Hans Reiser (da qui il nome). Fornisce anche il journaling; è stato sviluppato in base all'algoritmo dell'albero bilanciato (ingl. balanced tree). Maggiori informazioni sulla struttura specifica di reiserfs si trovano sul sito Web degli sviluppatori (vedere Riquadro In Rete). Jfs Jfs (IBM's Journaled File System for Linux) è il file system scritto dalla IBM per la piattaforma Linux. Ha lo scopo di rendere più efficiente la comunicazione con i prodotti IBM. È basato su un principio del journaling, similmente al resto dei sistemi che lo adoperano. Questo significa che i nuovi dati memorizzati vengono posti all'inizio del disco, invece le informazioni nel blocco principale, vengono aggiornate. Xfs Extended filesystem è stato progettato per i computer che hanno la necessità di conservare un grande numero di file in una sola directory e che devono averne un accesso immediato. Progettato principalmente per Irix, ha trovato anche impiego nei supercomputer funzionanti con il sistema GNU/Linux. Una curiosità è il fatto che il sistema è capace di mantenere in una sola directory persino 32 milioni di file. 62

5 Il recupero dei dati I blocchi e la loro gerarchia in ext2fs I blocchi sul disco non sono una sola sequenza attribuita ad un file (inode). In certe parti (dipendenti dal file system, non dall'utente) sono presenti i cosidetti blocchi indiretti, di tre tipi: il blocco indiretto (ingl. indirect block) IND, il blocco doppiamente indiretto (ingl. double indirect block) DIND, il blocco triplamente indiretto (ingl. triple indirect block) TIND. Ogni blocco successivamente numerato dipende dal precedente, però anche ogni successivo può conservare un maggiore numero di blocchi: i numeri dei primi 12 blocchi sono conservati direttamente in un inode (proprio essi sono spesso chiamati blocchi indiretti), un inode contiene il numero di un blocco indiretto; il blocco indiretto contiene i numeri dei successivi 256 blocchi con dati, un inode contiene il numero di un blocco doppiamente indiretto. Il blocco doppiamente indiretto contiene i numeri dei 256 blocchi indiretti supplementari, un inode contiene il numero di un blocco triplamente indiretto; il blocco triplamente indiretto contiene i numeri dei 256 blocchi doppiamente indiretti supplementari. La struttura è presentata nella Fig. 2. Listing 3. La verifica dei blocchi da recuperare # debugfs /dev/hda10 debugfs: stat <20> Inode: 20 Type: regular Mode: 0644 Flags: 0x0 Generation: User: 0 Group: 0 Size: BLOCKS: (0-11): , (IND): 22027, (12):22028 TOTAL: 14 Listing 4. Il recupero dei file tramite la modifica diretta di un inode da recuperare. Quest'operazione, la vediamo nel Listing 3 prestiamo attenzione al fatto che il blocco è un blocco indiretto (IND). Ci interessa la penultima riga, proprio in essa sono indicati i blocchi che appartengono al dato inode. Utilizziamo il programma dd per recuperare i blocchi da 0 (bisogna cominciare sempre da questo numero a contare i blocchi) a 11: # dd bs=4k if=/dev/hda10 \ skip=22015 count=12 \ > ~/recovered.001 # dd bs=4k if=/dev/hda10 \ skip=22028 count=1 \ >> ~/recovered.001 Alcune spiegazioni: bs indica la dimensione del blocco (fornito in kilobyte), che avevamo prima, if indica il file di input (ingl. input file), skip impone al programma di saltare blocchi della dimensione bs data, count indica il numero dei blocchi da aggregare. Il blocco è doppiamente indiretto, ecco perché l'abbiamo omesso ed abbiamo subito aggregato il blocco # debugfs -w /dev/hda10 debugfs: mi <24> Mode [ ] User ID [0] Group ID [0] Deletion time [ ] 0 Link count [0] 1 debugfs: quit # e2fsck -f /dev/hda10 e2fsck 1.35 (28-Feb-2004) Unattached inode 14 Connect to /lost+found<y>? yes In risposta dovremmo ottenere: dumpe2fs 1.35 (28-Feb-2004) Block size: 4096 Proprio quest'ultimo numero (4096) è la dimensione del blocco. Adesso, quando abbiamo già la dimensione del blocco, verifichiamo i blocchi La modifica degli inode Adesso ci occuperemo di un altro modo per recuperare dati della modifica diretta degli inode. Essa consiste nel cambiamento di un inode, in modo tale che il file system tratti rispettivi dati come mai cancellati, e in occasione della prossima verifica del disco sposti il file cancellato nella cartella lost+found su una data partizione. Anche per la modifica utilizzeremo il programma debugfs. L'intera procedura è riportata nel Listing 4. Come si vede, sono state modificate soltanto due stringhe: il tempo di cancellazione (deletion time non è però del tutto vero, perché il sistema non è in grado di determinare la data di cancellazione di un file) e il numero dei collegamenti al file 63

6 (link count). Adesso, dopo avere terminato il lavoro da debugfs, basta eseguire il comando: # e2fsck -f /dev/hda10 Il programma, dopo aver incontrato l'inode modificato, riconoscerà che esso non ha nessun allegato (ingl. unattached) e chiederà se i dati descritti in questo inode sono da allegare alla cartella lost+found. Se ci teniamo al file ovviamente premiamo il tasto y. Però non c'è rosa senza spine avendo dato un'occhiata nella cartella non vedremo i nomi eleganti dei file, ma esclusivamente i nomi degli inode ricostruiti (p.es. 24). Bisogna allora esplorare il file e dal contenuto riconoscere il suo nome originale. Ext3fs Il recupero dati in questo file system è specifico, a volte persino molto impegnativo (vedi anche Riquadro I file system di Linux). In verità non c'è nessun modo di recupero consolidato per questo tipo di partizione. Esistono però metodi non ufficiali per salvare dati. Difesa Figura 2. La struttura dei blocchi nel file system ext2 Listing 5. La ricerca degli inode cancellati in ext3fs # debugfs /dev/hda10 debugfs: lsdel Inode Owner Mode Size Blocks Time deleted 0 deleted inodes found. debugfs: q Listing 6. Il recupero dati dalla partizione ext3 montata come ext2 debugfs: lsdel Inode Owner Mode Size Blocks Time deleted /14 Tue Feb 14 19:20: /5 Tue Feb 15 19:13: deleted inodes found. debugfs: È ext3 o ext2? Ext3 e ext2 sono file system molto simili (ad eccezione del journaling e del modo di cancellare file) utilizziamo allora questo fatto per recuperare i nostri dati. Cercheremo di usare debugfs; questo processo è stato presentato nel Listing 5. Guardiamo il Listing 5. I nostri inode sono stati cancellati dal file system. La via che abbiamo scelto sembra non condurre in nessun luogo. Possiamo però provare un trucco fare in modo che il sistema tratti il file system come ext2. Questa soluzione si suddivide in tre tappe: smontare il file system, montarlo nuovamente, però questa volta come ext2, recuperare i file. Smontiamo allora la partizione: # umount /dev/hda

7 Il recupero dei dati In seguito dobbiamo montarla di nuovo come ext2, per maggior sicurezza in modalità read only: # mount -o ro -t ext2 \ /dev/hda10 /tmp Adesso cerchiamo di lavorare con debugfs nel modo, che abbiamo presentato parlando del sistema ext2. Come trovare gli inode cancellati dalla partizione ext3 è illustrato nel Listing 6. L'inode 20 ha una falsa data di cancellazione. Succede così perché dopo la liberazione dell'inode da ext3, il sistema ext2 può avere dei problemi sulla lettura di dati corretti sui file. Dopo un'attenta analisi dell'intera lista dei file eliminati possiamo iniziare ad occuparci del recupero dei file di cui abbiamo bisogno. Il metodo è lo stesso come nel caso di ext2, però con ext3 si può incontrare qualche problema dopo la modifica diretta dell'inode. In alcuni casi può persino causare l'illeggibilità dell'intera partizione per il sistema. Il lavoro duro rende Il secondo metodo per recuperare dei file da ext2 è molto più difficile, però rende possibile recuperare un numero molto più grande di file di testo cancellati. Anche questo metodo, purtroppo, ha un serio difetto richiede l'esplorazione manuale del contenuto dei dischi, allora il salvataggio dei file binari è molto difficile. Una buona idea è quella di fare prima una copia di backup dell'intero disco. Facciamolo con il comando: $ dd if=/dev/hda10 \ >~/hda10.backup.img In Rete Listing 7. dsksplitter.pl un semplice script per dividere dischi #!/usr/bin/perl if ($ARGV[3] eq "") { print "Usage:\ndsksplitter.pl <dsk_parts> <part_size in Kb> <partition_to_split> <target_dir>"; } else { $parts = $ARGV[0]; $size = $ARGV[1]; $partition = $ARGV[2]; $tardir = $ARGV[3]; for ($i = 1; $i <= $parts; $i++) { system "dd bs=1k if=$partition of=$tardir/dks.$i count=$size skip=$ix$size"; } } Per facilitarci un po' il lavoro, possiamo suddividere la nostra partizione in parti più piccole. Se la partizione ha la capacità di 1 GB, sarà prudente dividerla in 10 parti da 100 MB. Un semplice script destinato a questo scopo è stato presentato nel Listing 7 il disco lo possiamo suddividere con il comando: $ dsksplitter.pl \ /dev/hda10 ~/dsk.split Utilizziamo ora il comando di sistema grep per trovare le sequenze di caratteri che ci interessano (per questa attività possiamo ovviamente usare il comando strings): $ grep -n -a -1 \ "int main" ~/dsk.split/* la pagina del pacchetto e2fsprogs, la homepage di ext2fs, la homepage degli sviluppatori di ReiserFS, il sito del file system jfs, la pagina del progetto xfs, il pacchetto unrm. Il parametro -n ci indicherà il numero della linea del file in cui si trova la sequenza. Il parametro -a impone di trattare i file binari come i file di testo, invece -1 visualizzerà una linea prima ed una linea dopo la sequenza trovata. Ovviamente possiamo cambiare la sequenza int main in una qualsiasi. Ecco i risultati ottenuti: ~/dsk.split/dsk.1:40210: #include <sys/socket.h> ~/dsk.split/dsk.1:40211: int main (int argc, char *argv[]) ~/dsk.split/dsk.1:40212: { Ext3 registra i nuovi file all'inizio del disco, possiamo allora supporre che la linea da noi trovata è proprio quella che cerchiamo. Proviamo, allora, ancora una volta, a dividere il file in parti più piccole e lì cercare i dati: $ mkdir ~/dsk1.split $ dsksplitter.pl \ ~/dsk.split/dsk.1 ~/dsk1.split Eseguiamo adesso il comando grep sul file dsk.1 diviso: $ grep -n -a -1 \ "int main" ~/dsk1.split/* Otterremo: ~/dsk1.split/dsk.3:143: #include <sys/socket.h> ~/dsk1.split/dsk.3:144: int main (int argc, char *argv[]) ~/dsk1.split/dsk.3:145: { Adesso abbiamo il file con il programma cancellato dall'intruso. In verità il file, in cui l'abbiamo trovato è di 10 MB, però, ad ogni modo, 65

8 Difesa è una prospettiva molto migliore che dover esplorare 1 GB di dati. Se però questa precisione non ci soddisfa, possiamo tentare di dividere il file di frammento di disco esaminato in parti ancora più piccole. Se la dimensione del file verrà diminuita abbastanza, non ci rimane che avviare un editor di testo ed occuparci della penosa eliminazione delle righe superflue. Questa tecnica è impegnativa, però efficace. È stata sottoposta ad un test con alcune distribuzioni di Linux, però non possiamo garantire che il metodo funzionerà su tutti i sistemi Linux. Il recupero in ReiserFS Per recuperare i file ci serviremo dei programmi standard di Linux. Cominciamo da dd lo useremo per creare l'immagine della partizione. È indispensabile, perché le azioni che eseguiremo potrebbero causare dei danni irreversibili. Eseguiamo allora il comando: $ dd bs=4k if=/dev/hda10 \ conv=noerror \ > ~/recovery/hda10.img dove /dev/hda10 è la partizione da recuperare, e bs (block size) lo abbiamo determinato con il comando: $ echo "Yes" reiserfstune \ -f /dev/hda10 grep "Blocksize" Il parametro conv=noerror causerà la conversione al file senza trasmettere errori, vuol dire che, anche se il programma incontrerà errori sul disco, continuerà a convertire dati al file. Dopo aver immesso il comando saremo costretti ad aspettare un determinato lasso di tempo, dipendente dalla dimensione della partizione. Adesso bisogna spostare il contenuto della nostra immagine della partizione sul dispositivo di loopback loop0, assicurandoci prima che sia libero: # losetup -d /dev/loop0 # losetup /dev/loop0 \ /home/aqu3l/recovery/hda10.img In seguito bisogna ricostruire l'albero l'intera partizione verrà verificata, invece qualsiasi resto dopo gli inode verrà aggiustato e ripristinato. Per fare ciò useremo il comando: # reiserfsck rebuild-tree -S \ -l /home/aqu3l/recovery/log /dev/loop0 Il parametro supplementare -S farà sì che venga verificato l'intero disco, e non soltanto la sua parte occupata. Il parametro -l con il parametro /home/user/recovery/log registra un file di log nella directory indicata. Adesso creiamo la directory per la nostra partizione e la montiamo: # mkdir /mnt/recover; \ mount /dev/loop0 /mnt/recover I file recuperati si possono trovare in uno dei seguenti tre luoghi. Il primo è la directory originale del file (trattiamo /mnt/recover/ come root directory). Il secondo è la directory lost+found nella nostra directory temporale principale (/mnt/recover). Il terzo è semplicemente la directory principale della partizione. Il file cercato quasi per certo si troverà in una di tre luoghi elencati. Se non lo troviamo lì, due possono essere le spiegazioni: o era il primo file sulla partizione ed è stato sovrascritto, oppure è stato erroneamente spostato in un'altra directory. Nel primo caso dovremo rinunciare ai nostri dati, invece nel secondo possiamo trovarlo in un altro luogo, utilizzando lo strumento find: $ find /mnt/recover \ -name nostri_dati Il recupero di un file recentemente modificato Concentriamoci adesso sul recupero di un solo file, recentemente modificato. Questo metodo si può adattare anche per i file più vecchi, però tale recupero dovrà essere basato su faticosi calcoli uniti ad un'ottima conoscenza del proprio file system e non ultimo ad una buona dose di fortuna. Come si vede nella Fig. 1, nei file system con journaling i nuovi file vengono registrati all'inizio stesso del disco. In teoria il nostro file si trova subito dietro al cosiddetto blocco principale (ingl. root block), ossia il blocco del disco che determina il luogo da dove cominciano i dati. Per localizzare il nostro root block bisogna eseguire il comando: # debugreiserfs /dev/hda10 \ grep "Root block" Otterremo qualcosa simile a: debugreiserfs ( Root block: 8221 Come è facile indovinare, 8221 è il numero del nostro blocco principale. Dobbiamo anche, almeno approssimativamente, stabilire la dimensione del nostro file diciamo che esso aveva 10 kb, quindi il triplo della dimensione dei blocchi dovrebbe essere sufficiente. A questo punto possiamo allora eseguire il comando: # dd bs=4k if=/dev/hda10 \ skip=8221 count=3 \ > ~/recovered.003 Dopo il recupero dei dati bisogna verificare la loro concordanza con il file cercato: # cat ~/recovered.003 Come nel caso di ext2fs alla fine del file possiamo incontrare spazzatura di ogni genere con facilità l'elimineremo. Facilitarsi la vita Esistono dei programmi, che automatizzano i modi presentati di recupero dati. Il maggior numero degli strumenti di questo tipo funziona con il file system ext2. Raccomandabile è il pacchetto unrm e la libreria e2undel scritta da Olivier Diedrich, funzionante con il pacchetto e2fsprogs. Ovviamente non dovremo sempre aspettarci di riuscire a recuperare il 100 per cento dei file cancellati (a volte è possibile) se riusciremo a salvare circa l'80 per cento di un file di grandi dimensioni, potremo considerarlo un successo. 66