Contact me sending an e-mail (antispam defense activated)
Title: Come tentare di recuperare file, filesystem e partizioni Author: Sandro Tosi Last modified: 2004-11-14 (2004-11-09) (2004-11-07) (2004-11-03) 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...?).