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.
|