Linux: Alla ricerca del file perduto

Linux ha un sacco di pregi, il più evidente dei quali è certamente la sua affidabilità: fa esattamente ciò che gli viene detto di fare e nel migliore dei modi. Un po' meno affidabile, invece, è l'utente inesperto, o solamente distratto, che senza pensarci troppo infarcisce i comandi Unix di opzioni pericolose, spesso irreversibili: pensate, ad esempio, a quanti nel tentativo di cancellare un file hanno dato il fatidico rm -fr, cancellando di tutto, da intere directory alla root del disco. Quante ore di lavoro sprecate! Quanti file andati persi irrimediabilmente... o forse no?

A tutto c'è rimedio

Purtroppo, la cancellazione di un file rientra in quelle operazioni "sicure" in cui Linux è implacabile: una volta distrutti, infatti, i dati diventano pressoché irrecuperabili. Per riuscire a riavere ciò che la nostra imperizia ha rimosso, dovremo lavorare parecchio, imparando per prima cosa come sono dislocati i byte di un singolo archivio su un file system ext2. Prendiamo come riferimento un qualsiasi file di dimensioni maggiori a 12kb, disposto in blocchi da 1024 byte (1kb ciascuno, che poi è la grandezza standard), e partiamo dal presupposto che questo non sia frammentato. Vediamo cosa troviamo nei vari blocchi nei quali sono registrati i dati:

I primi 12 blocchi (1 inode): i numeri dei blocchi occupati dal file vengono descritti nell'inode. I blocchi sono detti "diretti"

Da 13 a 268: dopo i blocchi diretti, ce n'è un altro che registra i blocchi indiretti, dopodiché seguono altri 256 blocchi di dati.

Da 269 a 65804: come in precedenza, ci sono 12 blocchi diretti, un blocco indiretto assolutamente inutile, e 256 blocchi di dati. Questi sono seguiti da un blocco indiretto secondario (inutile), 256 ripetizioni di un (inutile) blocco indiretto e 256 blocchi di dati.

Da 65805 in poi: la disposizione dei primi 65804 blocchi ripete lo schema precedente, con l'aggiunta di un (inutile) blocco indiretto terziario, 256 ripetizioni della "sequenza indiretta secondaria": ognuna di queste consiste in un (inutile) blocco indiretto secondario, seguito da 256 ripetizioni di un (inutile) blocco indiretto e 256 blocchi di dati.

Chi di voi fosse giunto alla conclusione che si tratti di un solenne guazzabuglio, ha perfettamente ragione. Tuttavia, questa organizzazione dei file è complice del bassissimo tasso di frammentazione che caratterizza il filesystem ext2, per cui possiamo tranquillamente trascurare la sua complessità e lavorare ignari dei vari inode. In compenso, vanno fatte due debite considerazioni:

1) Linux è un sistema operativo multiutente

2) la tipica macchina Linux è soggetta ad una continua riscrittura dello spazio su disco (basti pensare, ad esempio, al lavoro dei daemon), per cui spesso vengono cancellati e ricreati file,. Questo significa che molte volte lo spazio occupato da un file viene liberato per poi essere reimpiegato per contenere altre informazioni. In questo caso, la cui probabilità aumenta con le dimensioni del file da salvare, il ripristino totale dei file cancellati diventa impossibile: sarebbe come cercare di recuperare una vecchia canzone sopra una cassetta che è stata incisa più volte.

Il discorso cambia se ci siamo accorti immediatamente di avere cancellato qualcosa per sbaglio: se agiamo in fretta è meno probabile che lo spazio occupato dai file cancellati sia stato occupato da altre informazioni. Per prima cosa, smontiamo immediatamente il file system dal quale abbiamo rimosso i file che vogliamo recuperare. Se, ad esempio, l'utente Giovanni ha eliminato il file contenente il suo curriculum vitae dalla propria home directory, dovrà essere smontata la partizione contenente

/home/giovanni

Le cose si fanno più complicate se le home sono sulla stessa partizione della root, dato che diventa un lavoro particolarmente delicato smontare la partizione, modificarla e poi rimontarla in sola lettura. Per questo, al momento dell'installazione è più prudente dedicare una partizione separata per le home, che in questo modo possono essere smontate e rimontate senza dare troppi problemi all'intero sistema operativo.
Ora che abbiamo preservato gli inode da modifiche accidentali, possiamo seguire due strade: possiamo studiare la "Linux Ext2fs Undeletion mini-HOWTO" di Aaron Crane (aaronc@pobox.com) e seguire le sue spiegazioni, oppure affidarci a recover, una piccola utilità a linea di comando che automatizza in parte le operazioni illustrate nell'how-to che abbiamo appena citato.
In pratica, scaricato l'archivio contenente il programma, basta lanciare la compilazione utilizzando make e quindi caricare il programma dando il comando:

./recover

A questo punto bisogna inserire alcune informazioni utili per il recupero dei dati, dalla partizione sulla quale operare, la data di cancellazione del file, e la dimensione approssimativa che questo dovrebbe avere, e infine la directory di destinazione nella quale riportare il dump degli inode. In pratica, ipotizzando di avere specificato la directory recuperati come cartella di dump, alla fine delle operazioni di recupero è qui che troverete i file (dal nome dumpxx, dove xx è un numero) che recover è riuscito a ripristinare. Ora, basta rinominarli e il gioco è fatto. Il tutto non è così difficile, anche se l'interfaccia a carattere certo non aiuta molto. Per facilitarvi le operazioni, potete vedere in tabella una sessione di recover grazie alla quale siamo riusciti a recuperare due file, "primofile" e "secondofile", che avevamo cancellato nella directory di boot, montata in /dev/hda1. Abbiamo per prima cosa smontato la directory, lanciato recover, e passato dei valori di massima relativi a data e ora di cancellamento dei file. Come vedete, le operazioni sono andate a buon fine e nella cartella recuperati abbiamo trovato i file dump22 (primofile) e dupm23 (secondofile)

Ma non potevano mettere il cestino?

Purtroppo, le metodologie descritte finora non garantiscono dei risultati certi e sistemi alternativi non aumentano di molto le probabilità di successo pur essendo sconsigliabili agli utenti meno esperti, data la loro pericolosità. Aaron Crane, nel suo mini how-to, si lascia scappare una battuta piuttosto infelice: "se volete qualcosa di più colorato potete usare un altro sistema operativo, dotato di cestino". A dire il vero, il cestino dovrebbe averlo anche Linux, dato che è previsto dal file system ext2 ed esiste persino un comando (chattr), che permette di dare ai file un attributo speciale del tipo "safe delete": in teoria il comando mk2fs dovrebbe creare una directory speciale legata all'inode 6, correntemente riservato e inutilizzato, e tutti i file interessati dall'attributo +u di chattr dovrebbero essere spostati li dal comando rm, invece di essere cancellati direttamente. Il problema è che chi ha sviluppato il Kernel sembra essersi totalmente dimenticato della cosa, rendendo di fatto inutile questa comoda caratteristica del file system. A dire il vero, c'è già chi ha posto rimedio alla cosa, fornendo un comodissimo comando undelete, ma si tratta di un esperimento che non ha avuto seguito e che purtroppo è valido per i soli kernel di tipo 2.0.x (all'url amadeus.upr.clu.edu, è possibile documentarsi a riguardo).

Conclusioni

Qual'è, dunque, il metodo più sicuro per mantenere vivi e vegeti i file più importanti? Allo stato attuale, la prudenza. E questo non vale solo per Linux: un bel backup ogni tanto e soprattutto tanta, tantissima, attenzione quando si usano comandi come rm e i suoi pericolosissimi switch.