Manutenzione dei dischi

In fase di sviluppo Leggere le avvertenze In fase di sviluppo

Prima che sia troppo tardi

Prima (PRIMA) di avere problemi, è bene procurarsi una chiavetta con installato un sistema operativa adatto a lavorare con  sistemi che hanno subito danni (per esempio non partono, danno continuamente errori di I/O, si bloccano con segment fault inspiegabili...). Personalmente uso http://www.sysresccd.org, ma volendo anche Ubuntu live va bene.

I dati sono estremamente preziosi. Prima (PRIMA) di avere problemi, fatevi regolarmente backup, almeno due, sicuramente su due supporti fisici diversi e possibilmente in due luoghi diversi.

Recupero di file da chiavetta USB

A tutti sarà capitato di dover recuperare file importantissimi da una chiavetta USB. A me lo chiedono spesso amici e parenti. Ovviamente inizio sempre con il pistolotto sull'importanza dei dati personali e di un backup regolare; e ovviamente risultati zero.

 Esistono un sacco di strumenti per windows, gratuiti per il recupero di 1 o due MB, a pagamento per un numero illimitato di file: i 100 € in genere richiesti sono comunque enormemente meno del valore dei dati che recuperano... Sulla capacità di recupero non mi esprimo.

Due avvertenze preliminari:

  1. non è possibile recuperare dati da una chiavetta guasta a livello hardware, perlomeno senza strumenti hardware specifici o un tentativi di saldadura del connettore, se è questo il problema
  2. evitate l'errore di recuperare con strumenti tipo fdisk, proposto in automatico di Windows e suggerito a volte anche da Linux: è il modo sicuro per fare danni!

Innanzitutto provate ad inserire semplicemente la chiavetta: più di una volta ho visto chiavette illeggibile da Windows leggibili da Linux, almeno in parte.

La prima operazione da fare è la copia fisica della chiavetta, errori inclusi. Questo eviterà di fare modifiche alla chiavetta, lasciandola intatta per eventuali ulteriori analisi e/o tentativi. Il tempo necessario è tanto e dipende dalla velocità, dalla dimensione e dal numero di errori. Spesso mettete in conto una notte.

root@vv-i7:~# aptitude install gddrescue  # Se non installato in precedenza

root@vv-i7:~# ddrescue -f -n /dev/sdb1 /home/vv/immagine.img /home/vv/immagine.log

Il file immagine.img avrà le stesse dimensioni della chiavetta, anche se vuota. Il log non è strettamente necessario, ma utile se vi capita di interrompere il processo.

Quindi si procede al recupero vero e proprio. Consiglio vivamente di lavorare sull'immagine ottenuta al punto precedente, sia per ragioni di prestazioni che per evitare di stressare una chiavetta già non in ottime condizini:

vv@vv-i7:~$ foremost -v -i ./immagine.img -o immagine.RECOVER

All'interno della directory immagine.RECOVER ci saranno i file recuperati, ordinati per tipo. Viene in genere persa la struttura originale delle directory e spesso i file sono rinominati.

Aumentare lo spazio disponibile

In genere un sistema linux riserva parte del disco all'utente root (oppure ad un altro utente), spesso il 5%. Peccato che su una partizione grande sono una marea di spazio. Per sapere quanto spazio è stato riservato:

root@vv-15rse:/home/vv# tune2fs -l /dev/sdb1
[...]
Reserved block count: 78161
[...]

Per modificare tale valore, in percentuale:

root@vv-15rse:/home/vv# tune2fs -m 1 /dev/sdb1
tune2fs 1.42.5 (29-Jul-2012)
Setting reserved blocks percentage to 1% (78161 blocks)

Controllare gli errori

In genere i problemi nascono dopo uno spegnimento improvviso (poco male) o un guasto hardware. Al riavvio il test viene fatto automaticamente e gli errori recuperati (viene chiesta conferma)

E' possibile forzare il controllo dei dischi, anche se appare pulito. Il comando è eseguibile solo su dischi non montati, quindi va prima smontato:

root@vv-15rse:/home/vv# umount /dev/sda6
root@vv-15rse:/home/vv# e2fsck -f /dev/sda6

Per forzare il controllo sulla partizione root, che evidentemente non può essere smontata, occorre partire da un disco diverso (per esempio il già citato sysresccd) oppure digitare il seguente comando e quindi riavviare

root@vv-15rse:/home/vv# touch /forcefsck

Per verificare tutti i settori, sempre a disco smontato, occorre usare l'opzione -c una sola volta (controllo in sola lettura):

root@vv-15rse:/home/vv# e2fsck -c /dev/sdb1

Oppure due volte (controllo in lettura scrittura non distruttivo)

root@vv-15rse:/home/vv# e2fsck -c -c /dev/sdb1

Entrambe queste operazioni impiegano un tempo molto elevato per essere completate (ore, su dischi molto grandi e non particolarmente veloci)

Per vedere gli eventuali bad-block:

root@vv-15rse:/home/vv# dumpe2fs -b /dev/sdb1

Dischi SMART

(non voglio entrare nel merito della sua effettiva utilità...) Se il disco supporta tale tecnologia, sono disponibili alcuni comandi di autodiagnosi dei dischi:

Visualizzazione delle caratteristiche e di altre informazioni:

root@atomo3:~# smartctl -a /dev/sda

Ricerca di settori danneggiati

root@atomo3:~# smartctl -t long /dev/sda

root@atomo3:~# smartctl -t short /dev/sda

La diagnosi viene mostrata dal comando:

root@atomo3:~# smartctl -a /dev/sda

Occorre cercare in una delle tabelle simile alle seguenti. Il primo esempio è relativo ad un dico integro e sono mostrati gli output di una scansione breve, una scansione interrotta manualmente, una scansione estesa

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%       3756            -
# 2 Extended offline  Aborted by host          90%       3756            -
# 3 Extended offline  Completed without error  00%       2027            -

Il secondo esempio è relativo ad un disco con (almeno) un settore danneggiato:

SMART Self-test log structure revision number 1
Num Test_Description  Status                   Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure   70%       4210            846721144

Disattivare NCQ

Alcuni dischi hanno NCQ (Native Command Queuing) mal implementato. Questo causa errori di I/O di vario tipo anche se il disco è integro. Il mio server casalingo monta dischi WD Caviar Green da 1.5 TB che sembrano soffrire di questo problema. La soluzione è disattivare NCQ (non mi sembra di notare cali di prestazioni significativi)

Verificare se NCD è attivo/supportato:

root@atomo3:~# dmesg | grep -i ncq
[ 1.807400] ata1.00: 2930277168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

Se NCQ è attivo trovate una stringa simile alla precedente. Il punto significativo è 31/32: numeri diversi da 1/32 (o simili) identificano la profondità della "coda".

Per disattivare NCD è possibile modificare /etc/default/grub aggiungendo:

GRUB_CMDLINE_LINUX="libata.force=noncq"

Occorre aggiornare grub (update-grub2) e riavviare. Dopo dovrebbe apparire:

root@atomo3:~# dmesg | grep -i ncq
[ 1.807400] ata1.00: 2930277168 sectors, multi 16: LBA48 NCQ (not used)

Analisi delle prestazioni

Per sapere quanti byte vengono letti o scritti, in tempo reale;

root@atomo3:~# aptitude install sysstat

vv@atomo3:~$ iostat -d 5 -m
Linux 3.2.0-4-amd64 (atomo3) 05/07/2013 _x86_64_ (4 CPU)
Device: tps     MB_read/s MB_wrtn/s MB_read MB_wrtn
sda     78,00   0,00      37,62     0       188
sdb     479,60  30,00     0,00      150     0

Cancellare i file duplicati

Se lo stesso file è presente in una delle DIRx, questo viene cancellato. E file vengono cancellati nell'ordine inverso in cui le cartelle sono elencate.

vv@BU:~$ rdfind -deleteduplicates true -checksum sha1 DIR1 DIR2 DIR3

Tre opzioni utili:

Il (criptico) messaggio Rdutil.cc: Failed to apply function f on it indica che non avete i diritti di cancellare i file duplicati.

Per cancellare le cartelle vuote:

vv@BU:~$ while [ -n "$(find . -depth -type d -empty -print -exec rmdir {} +)" ]; do :; done

Per chi proprio vuole usare l'interfaccia grafica: fslint

Pagina creata nel febbraio 2016
Ultima modifica di questa pagina: 12 gennaio 2019


Pagina principaleAccessibilitàNote legaliPosta elettronicaXHTML 1.0 StrictCSS 3

Vai in cima