Gestire gli HD: stato di salute, badblocks e ripristino dati
 Versioni Compatibili Debian 8 "jessie" Debian 9 "stretch" Debian 10 "buster" |
Introduzione
Gli Hard Disk sono una delle parti più delicate degli odierni PC, ed infatti sono tra le periferiche che più facilmente sono soggette a rompersi.
Fortunatamente ci sono degli strumenti studiati per diagnosticare i malfunzionamenti prima ancora che possano creare danno (speriamo ;-)). Ma ricordate che un backup periodico dei dati importanti è sempre la scelta migliore.
In questa guida vedremo come usare alcuni strumenti come smartmontools e badblocks per monitorare lo stato di salute di un hard disk, vedremo come effettuare le basilari operazioni di backup di emergenza e come affrontare un eventuale ripristino dei dati.
|
Nota Questa guida raccoglie le mie (limitate) conoscenze in materia nella speranza che siano utili ad altri. Sentitevi liberi di contribuire con approfondimenti o link ad ulteriori documenti. |
DISCLAIMER
Per quanto abbia fatto del mio meglio per verificare l'attendibilità delle informazioni, non posso garantire in alcun modo che alcune delle tecniche illustrate di seguito non possano danneggiare i vostri dati, bruciare la vostra casa o uccidere il vostro gatto.
Faccio notare, inoltre, che il ripristino dei dati da una partizione corrotta è più una specie di magia nera che una scienza esatta, e richiede oltre che doti da chiromante anche una buona dose di fortuna. Quindi, e non lo ripeterò più, fate backup sistematici dei vostri dati o non lamentatevi se doveste perderli accidentalmente e non riuscire più a recuperarli!
Controllare lo stato di salute di un HD: smartmontools
Gli smartmontools permettono di usare la funzionalità SMART di tutti i moderni HD grazie alla quale è possibile prevedere con 24 ore di anticipo la rottura di un HD.
In Debian basta installare il pacchetto smartmontools. Con privilegi di amministrazione è sufficiente:
# apt install smartmontools
Analizzare lo stato dell'HD
Possiamo usare l'utility smartctl per analizzare lo stato dell'HD.
|
|
Hard disk SATA Se avete dei dischi SATA dovete ricordarvi di attivare l'opzione: -d ata utilizzando l'utility |
Innanzitutto vediamo alcune informazioni generiche sul nostro HD:
# smartctl -i /dev/hda smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen Home page is https://www.smartmontools.org/ === START OF INFORMATION SECTION === Model Family: Western Digital Caviar family Device Model: WDC WD600BB-00CAA1 Serial Number: WD-WMA8F1747570 Firmware Version: 17.07W17 User Capacity: 60,022,480,896 bytes Device is: In smartctl database [for details use: -P show] ATA Version is: 5 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Tue Jan 31 17:36:07 2006 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled
oltre alle informazioni generiche, dalle ultime due righe si capisce che l'HD supporta la tecnologia SMART e che il supporto è attivato. Se non fosse attivato basterebbe questo comando:
# smartctl -s on /dev/hda
per attivare il supporto SMART.
Per controllare lo stato di salute attuale:
# smartctl -H /dev/hda smartctl version 5.34 [i686-pc-linux-gnu] Copyright (C) 2002-5 Bruce Allen Home page is https://www.smartmontools.org/ === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED
L'ultima riga ci dice che la salute sembra buona e nessuno dei parametri interni controllati da SMART ha superato il livello di guardia.
|
ATTENZIONE Se il precedente comando non riporta PASSED smontate immediatamente tutte le partizioni presenti su quell'HD ed effettuate un backup dei dati: la rottura definitiva ed irreversibile del disco è prevista nelle successive 24 ore! |
Per avere tutte le informazioni possibili sul nostro HD diamo:
# smartctl -a /dev/hda
L'output, abbastanza lungo (-a sta per "all"), è diviso in quattro sezioni. Il primo blocco rappresenta le informazioni generiche sull'HD (le stesse ottenute prima con -i), la seconda sezione riporta le informazioni sul supporto SMART. La terza sezione elenca i parametri interni monitorati da SMART e se hanno mai superato il livello di guardia, nel mio caso:
SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0007 099 091 021 Pre-fail Always - 4108 4 Start_Stop_Count 0x0032 098 098 040 Old_age Always - 2590 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6494 10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 098 098 000 Old_age Always - 2435 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0 199 UDMA_CRC_Error_Count 0x000a 200 200 000 Old_age Always - 19 200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0
I parametri indicati come Pre-fail sono quelli che superano la soglia di guardia nelle 24 ore che precedono la rottura dell'HD, mentre quelli Old_age sono i parametri che superano la soglia di guardia quando ormai l'HD è vecchio e non è considerato più affidabile dal costruttore. Nel mio esempio si vede che nessun parametro ha mai superato la soglia di guardia.
L'ultima sezione del comando smartctl -a /dev/hda riguarda il log dei test manualmente effettuati sull'HD:
SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 952 - # 2 Conveyance offline Completed without error 00% 951 - # 3 Short offline Completed without error 00% 951 - # 4 Short offline Completed without error 00% 875 -
Nell'esempio si può vedere che sono stati effettuati 4 test, di cui tre di tipo short e uno di tipo conveyance. Nessuno di loro ha dato esito positivo (cioè non sono stati rilevati malfunzionamenti).
Effettuare manualmente i test
È possibile effettuare dei test più o meno approfonditi sul disco. Alcuni test si possono effettuare con l'HD montato e funzionante, ed il test stesso avrà un impatto minimo o nullo sulle prestazioni del sistema.
Per effettuare un test:
# smartctl -t tipo_test /dev/hda
dove tipo_test può essere:
short- effettua un test sul disco di durata inferiore a 10 minuti, può essere eseguito durante il normale funzionamento e non ha alcun impatto sulle prestazioni. Questo test controlla le performance meccaniche ed elettriche del disco, oltre che le performance in lettura;
long- effettua un test di durata da 40 minuti ad un ora (a seconda del disco). Può essere effettuato durante il normale funzionamento del disco e non ha impatto sulle prestazioni. Questo test è una versione più estesa dello
short test;
conveyance- effettua un test di alcuni minuti atto a scoprire difetti dovuti ad incurie nel trasporto dell'HD. Può essere eseguito durante il normale funzionamento dell'HD.
Esistono anche altri tipi di test per i quali si rimanda alla simpatica pagina di manuale: man smartctl.
I risultati di questi test vengono riportati nella parte finale dell'output di smartctl -a /dev/hda, come notato in precedenza.
Controllo automatizzato
È possibile attivare il demone smartd fornito dal pacchetto smartmontools per monitorare in continuazione lo stato di salute dell'HD e notificare ogni anomalia immediatamente tramite syslog.
Normalmente il demone è disabilitato. Per abilitarlo bisogna editare il file /etc/default/smartmontools e decommentare le righe:
start_smartd=yes smartd_opts="--interval=1800"
Dobbiamo inoltre configurare smartd per deciderne il suo comportamento. A tal scopo editiamo il file /etc/smartd.conf. Leggendo i commenti nel file e l'amichevole pagina di manuale (man smartd.conf) è possibile scegliere quali parametri smartd debba monitorare, programmare dei test automatici, e decidere quali azioni intraprendere in caso di errore.
Nel mio caso ho inserito solo le seguenti linee:
/dev/hda -a -o on -S on /dev/sda -a -d ata -m root
che attivano il monitoraggio di tutti (-a) i parametri, abilitano l'automatic online data collection (-o on), inviano una mail a root (-m root) in caso di errori e abilitano il salvataggio degli attributi (-S on) in modo che le informazioni di log di SMART vengano memorizzare nella FLASH del disco e siano disponibili anche dopo il riavvio.
Nel caso si stesse usando un server HP Proliant con controller RAID E200i è possibile monitorare lo stato dei dischi inserendo in /etc/smartd.conf le seguenti linee:
/dev/cciss/c0d0 -T permissive -f -M daily -m yourmail@somehost.com -d cciss,0 -a -s L/../../7/04 /dev/cciss/c0d0 -T permissive -f -M daily -m yourmail@somehost.com -d cciss,1 -a -s L/../../7/04
dove:
/dev/cciss/c0d0indica l'unità RAID logica creata dal controller-d cciss,0indica il primo disco fisico del set RAID-d cciss,1indica il secondo disco fisico del set RAID
Verifica di settori corrotti
L'utility badblocks permette di fare un controllo di basso livello per vedere se su una partizione sono presenti dei settori danneggiati.
I moderni HD IDE fanno un controllo automatico degli errori e sono in grado di segnare dei settori corrotti che di conseguenza non verranno più usati. Questo rende in parte inutile badblocks, ma se si effettua un controllo e dei settori risultano danneggiati vuol dire che probabilmente la superficie del disco contiene così tanti settori danneggiati che la circuiteria di controllo non è più in gradio di gestirli.
Per effettuare un controllo con badblocks smontiamo la partizione ed eseguiamo:
# badblocks -b dimensione_blocco /dev/sdaX
dove /dev/sdaX è la partizione da controllare. Il parametro dimensione_blocco è la dimensione del blocco usata dal filesytem espresso in byte. Di solito è 4096 (ovvero 4KB), per controllare potete usare:
# dumpe2fs -h /dev/sdaX | grep -i "block size"
Per le ulteriori opzioni di badblocks si rimanda all'amichevole pagina di manuale, ma attenzione: l'opzione -w distruggerà tutti i dati sulla vostra partizione. Non usatela se non volete che ciò accada.
Se trovate dei settori danneggiati conviene cambiare immediatamente HD. Sebbene ci sia una piccola probabilità che l'errore sia isolato (dovuto ad esempio ad uno sbalzo di tensione) è molto più probabile che l'HD si stia progressivamente danneggiando e presto ci saranno dei nuovi settori danneggiati. Comunque se volete giocare alla roulette russa con i vostri dati siete liberi di farlo :-P.
Backup di emergenza
Per effettuare un backup di emergenza di una partizione corrotta il tool più efficace è GNU ddrescue (da non confondere con il simile ma meno potente dd_rescue). Per installare GNU ddrescue in Debian basta installare il pacchetto gddrescue.
GNU ddrescue può effettuare backup di singoli file o di intere partizioni, riconoscendo ed aggirando i settori danneggiati. Può essere interrotto in qualsiasi momento, riprendere la copia da punto in cui è stato interrrotto e può fare il merge dei file se si hanno più copie degli stessi file corrotti.
Il suo uso è vagamente simile al classico dd:
# ddrescue [OPTIONS] INFILE OUTFILE [LOGFILE]
Per una lista completa delle opzioni si rimanda al manuale: info ddrescue.
Riporto un semplice esempio di utilizzo:
# ddrescue -r3 /dev/hda3 /dev/hdb2 logfile
Il precedente comando copierà la partizione hda3 in hdb2 (distruggendo gli eventuali dati ivi presenti) provando a leggere tre volte i settori danneggiati e usando logfile come file di log.
Ora possiamo eseguire sulla copia i normali tool di ripristino del nostro filesystem (fsck.*).
- Vedere anche:
Strumenti per il ripristino dei dati
|
|
Nota In questa sezione verrà accennato il problema del ripristino dati. Lo scopo è solo quello di dare una panoramica iniziale del problema che possa servire come orientamento per ulteriori approfondimenti. |
Prima di ogni operazione di ripristino dati è fortemente consigliato effettuare una copia della partizione (vedi sezione precedente) e operare sulla copia.
La metodologia per il ripristino dei dati può variare a seconda del filesytem utilizzato e del modo in cui si sono perduti i dati. Ad esempio se si vogliono recuperare dei file cancellati accidentalmente da una partizione ext2 ci sono delle buone possibilità di usare il tool recover (presente nei repository fino a Debian 7). Il tool recover non può essere usato su partizione ext3/ext4, dove invece si può usare il tool extundelete (disponibile anch'esso nei repository Debian).
In mancanza di strumenti automatici si usa la così detta Unix Way. Ovvero si usano i tradizionali strumenti Unix per accedere direttamente al device ed estrarre i dati utili. Ad esempio se si devono recuperare file di testo o documenti non binari (per intenderci non foto o musica o programmi compilati) si possono usare egrep e strings.
Se si vogliono recuperare foto in formato JPEG è possibile usare recoverjpeg (presente nell'omonimo pacchetto Debian) che cerca di identificare gli header JPEG in una immagine di file system.
È fortemente consigliata la lettura dei documenti elencati di seguito nella sezione Links->Articoli per degli esempi pratici sul recupero dati da filesystem ext2 e reiserfs (ma le informazioni possono servire da spunto per operare anche su altri file system).
Links
Sul wiki
Articoli
- ReiserFS Data Recovery Tips
- Linux Ext2fs Undeletion mini-HOWTO
- How a Corrupted USB Drive Was Saved by GNU/Linux
Strumenti Utili
| Guida scritta da: ~ The Noise 05:31, Feb 4, 2006 (EST) |  Debianized 40%
|
| Estesa da: | |
Verificata da:
| |
|
Verificare ed estendere la guida | Cos'è una guida Debianized | |