I momenti in cui si ha necessita` di un recupero ``disperato'' del
sistema, sono svariati: cancellazione di una partizione, errori fisici
di un disco da cui si devono salvare dei dati importanti,
cancellazione involontaria di file.
Naturalmente, a margine di quanto scritto qui, una politica di backup
seria ed oculata e` insostituibile per porsi al riparo da eventuali
danneggiamenti fisici ed errori manuali.
Inoltre, e` fondamentale, per avere qualche speranza di recuperare i
propri dati, smettere *subito* di scrivere sulla partizione o sul
disco danneggiati: altrimenti i dati da recuperare potrebbero essere
sovrascritti e dunque perduti per sempre.
Undelete
========
Puo` succedere di effettuare un ``rm'' di troppo, e solitamente ci se
ne accorge subito dopo aver premuto Enter...
L'eliminazione in Linux e` definitiva: non esiste un'area tampone in
cui vengono parcheggiati i dati ``cancellati'' (il Cestino di Windows,
per intendersi), ma vengono effettivamente rimossi, deallocando gli
inode.
Per aver anche la minima possibilita` di recuperare qualche file, e
necessario smontare _quanto prima_ la partizione dove sono stati
cancellati i file: i filesystem Linux, infatti, tendono a
auto-deframmentarsi e quindi potrebbero utilizzare parte dei blocchi
di un file cancellato per scriverne uno nuovo.
Il principio su cui si basano le tecniche di recupero di file
erroneamente cancellati e` il seguente: un filesystem non cancella
fisicamente i dati (sia quelli di gestione, come inode e tabelle di
allocazione, che quelli effettivamente contenuti nel file) quando un
file viene cancellato, ma *marca* i blocchi e le strutture dati come
liberi.
Si tratta di avere alcune zone del filesystem marcate come
utilizzabili, in quanto libere, ma che in realta` contengono ancora i
precedenti dati.
La rapida interruzione dell'utilizzo del filesystem consente di non
sovrascrivere quelle aree di memorizzazione che prima contenevano i
nostri dati.
Per ext2 esiste l'Ext2fs-Undeletion HOWTO, che indica le operazioni da
svolgere per cercare di recuperare file erroneamente cancellati;
inoltre e` stato creato un programma, ``recover'' (di cui esiste la
versione con interfaccia grafica, ``gtkrecover''), che cerca di
automatizzare alcuni dei passi indicati nell'HOWTO. Si parta comunque
con lo spirito d'animo che quel che e` stato e` stato...
Il noto Midnight Commander, ``mc'', supporta l'undelete per ext2. Nel
caso si usi questo filesystem, si ha cosi` un metodo pratico per
recuperare i file cancellati.
Dal momento che ext3 e` un filesystem journaling (sebbene molto simile
ad ext2), e dunque per come vengono gestite le operazioni su disco,
non e` possibile utilizzare ``recover'' su partizioni di quel tipo.
Con ReiserFS si puo` utilizzare il comando
# fsck.reiserfs --rebuild-tree
per cercare di recuperare i file cancellati.
Per gli altri filesystem non sono a conoscenza di alcun metodo per
cercare il recupero di file cancellati. E` bene pensarci due volte
prima di eseguire un ``rm''...
Un trucchetto per evitare di effettuare un ``rm'' in una directory
sbagliata e` quello di creare un file ``-i'' nelle directory piu`
importanti.
/etc/fstab sbagliato
====================
Puo` capitare di commettere degli errori modificando /etc/fstab (...),
magari proprio sul filesystem / (!!); questo comporta l'impossibilita`
di effettuare il boot al successivo riavvio.
Basta non farsi prendere dal panico, in quanto la soluzione e`
semplice: si prenda una distribuzione live, o anche un cd di
installazione di Woody, e si esegua il boot della macchina. Fatto
cio`, si apra una console (nel caso di Woody si utilizzi l'immagine
``bf24'' e poi la console in Alt+F2) e si digiti:
# mount <device_di_/> /mnt
# $EDITOR /mnt/etc/fstab
- correzione di fstab
# umount /mnt
# reboot
Sara` ora possibile riutilizzare il proprio sistema come prima (il cd
deve essere tolto prima del reboot).
Filesystem di / non ext2/3
==========================
Utilizzare il proprio filesystem preferito (non ext2/3) anche sulla /
non e` un grosso problema. Potrebbe esserlo quando si ha necessita` di
interventi straordinari, in quanto il filesystem di / potrebbe non
essere supportato dal disco di recupero utilizzato.
E` dunque consigliabile creare un rescue disk che contenga tutti gli
strumenti a supporto del proprio filesystem, oppure sincerarsi che sia
gia` presente nella propria distribuzione live di recupero.
Un buon punto di partenza e` http://lbt.linuxcare.com , una
distribuzione minimale con gli strumenti necessari alla gestione di
XFS.
Recupero di partizioni
======================
Nel caso si sia cancellata la partition table, e` possibile recuperare
la situazione ricreando *esattamente* le stesse partizioni senza
formattare. In ogni caso, conviene crearsi una copia di backup della
partition table con
# sfdisk -d [device] > [partition_table_backup]
per essere restorata con
# sfdisk [device] < [partition_table_backup]
Se il disco presenta degli errori fisici nei primi settori, lo si puo`
considerare come completamente inutilizzabile ed irrecuperabile:
conviene allora effettuare una copia con ``dd'' su un altro disco per
poi utilizzare ``testdisk'' e recuperare le partizioni.
Un altro utile strumento per recuperare la tabella delle partizioni e`
``gpart'': e` in grado di scandire l'hard disk e di identificare, se
le partizioni sono formattate, dove iniziano i vari filesystem. Se il
partizionamento e` stato effettuato con strumenti ``seri'' (*fdisk
Unix) il recupero e` quasi garantito. Si esegua:
# gpart -l <log_file> <device>
e con fdisk di riscrivano esattamente nello stesso ordine e dimensioni
di come viene indicato.
Esiste anche una distribuzione live apposta per il recupero dei danni
gravi ai filesystem: SysRescCd, disponibile al sito
http://www.sysresccd.org . Contiene ``gpart'', ``dd_rescue''
(un'interfaccia ad esso e` ``dd_rhelp'', che ne facilita l'utilizzo),
``testdisk'' e molti altri tool utili
Alcuni software di recupero, noti su Windows, sono stati portati anche
su Linux: OnTrack, per esempio, dispone del pieno supporto a tutti i
filesystem piu` noti disponibili su Linux. Ovviamente, questo tipo di
programmi si pagano.
Un filesystem contiene al suo interno alcuni blocchi riservati, ed uno
di questi e` il superblock, il primo settore della partizione,
fondamentale per l'utilizzo del sistema. Nel caso si rovini proprio
quel blocco, non sara` nemmeno possibile effettuare il mount della
partizione.
Sarebbe buona prassi segnarsi i numeri dei superblock di backup quando
si crea un filesystem; (praticamente) nessuno lo fa. Per ext2/3 dal
man di e2fsck (alla descrizione del flag ``-b'') si leggono queste
indicazioni:
| The location of the backup superblock is dependent on the
| filesystem's blocksize. For filesystems with 1k blocksizes, a
| backup superblock can be found at block 8193; for filesystems with
| 2k blocksizes, at block 16384; and for 4k blocksizes, at block
| 32768.
|
| Additional backup superblocks can be determined by using the mke2fs
| program using the -n option to print out where the superblocks were
| created. The -b option to mke2fs, which specifies blocksize of the
| filesystem must be specified in order for the superblock locations
| that are printed out to be accurate.
che mostra anche un metodo (utilizzare mke2fs -n) per recuperare i
superblock di backup. Una volta ottenuto un superblock di backup, si
puo` cercare di recuperare la partizione con
# e2fsck -b <superblock_number>
Nel caso in cui tutti i superblock (anche di backup) siano corrotti si
puo` tentare un ultimo, disperato, tentativo:
# mke2fs -S <device>
# e2fsck <device>
che *potrebbe* consentire di salvare qualche file prezioso.
Un altro strumento molto interessante in casi veramente estremi e`
``debugfs''. Si tratta di un vero e proprio debugger per ext2/3 e
consente di esaminare e cambiare lo stato del filesystem. Non e` un
programma che tutti sono in grado di usare, ed anche le modalita` di
utilizzo non sono delle piu` semplici. Vista la potenza di questo
strumento, si sconsiglia anche solo di pensare ad utilizzarlo se non
si sa *esattamente* quello che si andra` a fare.
fsck
====
fsck.<fs> consente di controllare lo stato di un filesystem. Con
l'opzione ``-cc'' viene effettuato anche il controllo dei blocchi
tramite ``badblocks''.
A volte succede che dopo un riavvio forzato venga chiesto di inserire
la password di root ed eseguire fsck a mano: quando questo accade,
conviene seguire cio` che viene scritto a video ed, ogni tanto,
incrociare le dita...
Quando fsck non riesce a ricostruire esattamente l'albero di un
filesystem, sposta i rami ``staccati'' nella directory
/<mount_point>/lost+found utilizzando per nome l'inode number
preceduto dal carattere ``#''.
Non sempre e` facile capire cosa contengono i file creati in questa
directory, ma l'utilizzo di ``strings'' potrebbe aiutare questo
processo.
Inoltre, per i filesystem ``caldi'', e` buona pratica eseguire
periodicamente un
# find <mount_point> -ls
il primo numero e` l'inode number (non e` proprio comodissimo, ma chi
non vorrebbe averlo in caso di eventi come quello descritto prima?).
In caso si utilizzino filesystem journaled si tenga presente questo:
un filesystem journaled assicura la consistenza dei dati non il non
perdere file se il filesystem si danneggia; per questo esistono i
backup.
E` quindi buona norma mantenere il check periodico dei dischi al
riavvio (su base temporale o per numero di mount), ed anche in caso di
riavvio forzato del sistema.
Su ext3, per esempio, e2fsck riesegue automaticamente il journal, e
solo se il filesystem non risulta coerente, esegue un controllo
sull'intera partizione. Inoltre, se il filesystem non risulta pulito,
perche` il kernel aveva notato alcune inconsistenze, e2fsck esegue
automaticamente un controllo completo, se necessario.
Inoltre, in presenza di piu` dischi, il controllo viene eseguito in
parallelo, velocizzando la sequenza di boot, invece che lasciare che
il kernel riesegua il journal per ogni filesystem che tenta di
montare, in quanto in questo modo il replay del journal viene eseguito
in maniera sequenziale, anziche` in parallelo.
RAID software o hardware
========================
L'utilizzo del RAID consente di mettersi al riparo da molte situazioni
critiche, ma quando si rovina l'array, i risvolti possono anche essere
catastrofici.
Gli eventi di crisi sono molto vari: RAID-0 in cui uno dei dischi si
rompe; RAID-5 dove si corrompono in rapida successione 2 dei 3 dischi,
etc. Inoltre, la situazione si complica a seconda che il RAID sia
software o hardware.
Se il RAID e` implementato via software, il recovery e` relativamente
semplice: e` noto l'algoritmo con cui i dati sono memorizzati e si
puo` tentare un recupero, con opportuni strumenti, anche con relativi
margini di successo (le probabilita` sono grosso modo le stesse che si
avrebbero in assenza di RAID).
Se invece il RAID e` hardware i problemi possono essere anche
insormontabili: ogni firmware di ogni marca puo` implementare gli
algoritmi di replicazione dei dati sull'array come vuole, e nessuno
(tranne il produttore, ovviamente) e` in grado di indicare
_esattamente_ il metodo utilizzato e dunque come tentare il recupero
dei dati.
Per esempio, prendiamo il RAID-5 su 3 dischi: l'algoritmo utilizza 2/3
dello spazio per allocare i dati ed 1/3 per allocare valori di
parita`. Un metodo semplice per implementare il RAID-5 potrebbe essere
questo (dove D* rappresenta un blocco dati, e P** un blocco di
parita`, ottenuto tramite XOR):
disco 1) D1 D3 D5
disco 2) D2 D4 D6
disco 3) P12 P34 P56
ma potrebbe anche essere organizzato in questa maniera:
disco 1) D1 D3 P56
disco 2) D2 P34 D6
disco 3) P12 D4 D5
Si vede facilmente che il recupero in caso di RAID hardware e` quasi
impossibile.
LVM
===
La situazione e` addirittura peggiore del caso RAID, se possibile.
Una soluzione sembra essere la seguente: una versione demo di Stellar
Phoenix non porta a termine il recovery, ma indica cosa si dovrebbe
riuscire a recuperare.
Errori hard disk
================
In caso di errori fisici, nessun livello di logica (software) puo`
essere sufficiente: se un blocco e` corrotto a livello fisico (il
materiale magnetico e` rovinato a causa di un contatto con la testina,
per esempio) non esiste nessun software in grado di recuperare la
situazione.
Il consiglio che si puo` dare e` di smettere di utilizzare il disco, a
volte anche staccarlo fisicamente dal pc (nel caso non si abbia tempo
di effettuare un'analisi subito, anche se il bootstrap di un disco e`
la parte del suo utilizzo che lo stressa di piu`), ed effettuare
quanto prima una copia di backup dei dati contenuti, utilizzando
``dd'' alla peggio, per cercare di limitare i danni e recuperare il
recuperabile.
Esiste comunque un programma, ``badblocks'', che analizza un device
alla ricerca di blocchi danneggiati: un loro continuo aumento e` il
chiaro segno di un disco che sta rovinandosi sempre piu`. Per
controllare piu` a fondo il disco, conviene pero` utilizzare le
routine del produttore, che solitamente rilascia un dischetto di boot
con all'interno gli strumenti necessari a controllare lo stato del
disco.
Un eccellente tutorial su come identificare un file associato ad un
settore corrotto e come forzare il ricollocamento di questo settore sul
disco e` disponibile a questo indirizzo
http://smartmontools.sourceforge.net/BadBlockHowTo.txt
In tutto questo, il kernel avvisa della situazione critica scrivendo
nei log messaggi che devono mettere in allarme: ``DriveStatusError'',
``DriverStatusError BadCRC'', ``DriveSeekError'', ``DriveReady
SeekComplete DataRequest Error'', e molti altri simili.
Controllare i log del kernel consente di prevenire danni ulteriori e
di salvare la situazione al piu` presto.
Naturalmente, esistono servizi che, dietro un lauto pagamento,
consentono di recuperare i dati da hard disk che sembrano solo da
buttare. Dato pero` l'elevata cifra richiesta, e` una soluzione
applicabile solo a dati _veramente_ critici (ma non si utilizzavano i
backup per questo tipo di dati...?).