Clonare hard disk USB o da terminale

[_BlackTornado_]

Allora, ho da parecchio tempo una Sheevaplug che funziona da server con il sistema operativo installato in un hard disk esterno eSata/USB.

L'hard disk mi sta lasciando, quindi voglio clonare il sistema operativo in modo da trasferirlo sul nuovo hard disk.

Ho provato ad attaccare l'hard disk come esterno USB sul PC e ad usare clonezilla, ma mi permette di clonare solo hard disk interni.

Credo di avere due alternative:
1- Riattaccare l'hard disk al server e dirgli di "clonarsi" da qualche parte da terminale. Solo, come?
2- Trovare un tool qualsiasi che mi permetta di clonare anche partizioni USB.

PS: Nella partizione /home ho dei files danneggiati. Non mi interessano granchè, però vorrei comunque clonare la partizione. Posso farlo o i files danneggiati mi bloccheranno?

PPS: Esiste il modo di clonare l'intero hard disk e non partizione per partizione? Far fare il boot via eSata alla Sheevaplug non è stato proprio semplice, non vorrei fare qualche errore in fase di ripristino (l'hard disk ha una partizione che contiene /boot, un altra che contiene / e un altra ancora che monta /home) e rischiare che il sistema non parta più. Preferirei ripristinare le partizioni "in blocco" e poi eventualmente espandere solo /home.

[Gimli[2BV!2B]]

Se il disco di destinazione soddisfa la condizione di essere esattamente uguale o almeno un bit più grande di quello di origine, si può semplicemente usare dd. (http://serverfault.com/questions/4906/using-dd-for-disk-cloning)
Tra l'altro non è difficile suddividere l'operazione in più passaggi, creando un'immagine intermedia compressa per poterla poi spostare sulla macchina di destinazione.

Altra condizione fondamentale: il sistema sul disco da clonare non deve essere avviato, ancora meglio se tutte le partizioni coinvolte nella copia non saranno nemmeno montate durante l'elaborazione.

Riguardo i file danneggiati, mi sembra di ricordare che dd cerchi di recuperare il più possibile, ma ad un certo punto dovrebbe arrendersi e proseguire.

Il problema di fondo potrebbe essere il fatto che dd copierà ogni singolo byte del disco di origine, anche tutti i file cancellati ma non azzerati sul disco, ed accederà ad ogni singolo settore, quindi analizzerà *tutti* i settori danneggiati per vari secondi.

[_BlackTornado_]

;37160110']Se il disco di destinazione soddisfa la condizione di essere esattamente uguale o almeno un bit più grande di quello di origine, si può semplicemente usare dd. (http://serverfault.com/questions/4906/using-dd-for-disk-cloning)
Tra l'altro non è difficile suddividere l'operazione in più passaggi, creando un'immagine intermedia compressa per poterla poi spostare sulla macchina di destinazione.

Altra condizione fondamentale: il sistema sul disco da clonare non deve essere avviato, ancora meglio se tutte le partizioni coinvolte nella copia non saranno nemmeno montate durante l'elaborazione.

Riguardo i file danneggiati, mi sembra di ricordare che dd cerchi di recuperare il più possibile, ma ad un certo punto dovrebbe arrendersi e proseguire.

Il problema di fondo potrebbe essere il fatto che dd copierà ogni singolo byte del disco di origine, anche tutti i file cancellati ma non azzerati sul disco, ed accederà ad ogni singolo settore, quindi analizzerà *tutti* i settori danneggiati per vari secondi.

Ecco, questo è proprio quello che mi servirebbe..

Il problema di fondo credo che nel mio caso sia abbastanza relativo... I files che mi servono sembrano tutti a posto: si presentano errori di I/O su alcuni files grandi creati di recente, quindi credo che per qualche motivo il problema sia in scrittura più che in lettura, almeno per ora, o quantomeno su settori che per ora sono occupati da files della partizione /home.

Il problema è che, trattandosi di un hard disk da 1,5 TB, mi serve un hard disk da almeno 1,5-2 TB (che avrei pure, ma che dovrei svuotare completamente).

Hmmm... Magari aspetto direttamente di comprare il "ricambio" per il disco rotto e poi mi trasferisco tutto.
Sto aspettando che scendano di prezzo gli hd da 3 TB. Il problema è che la cosa non sembra aver intenzione di avvenire a breve, quindi intanto mi volevo salvare il salvabile, nel caso di morte repentina del vecchio hd.

In ogni caso, per ora il vecchio hard disk lo sto tenendo spento e smartmontools mi segna anche "Tutto OK" ai controlli del disco, quindi, errori di I/O a parte, non mi sembra di essere arrivati al punto di "rottura imminente".

[Gimli[2BV!2B]]

Purtroppo se il disco da clonare è grande occorre un disco nuovo più capiente...

La soluzione intermedia che ti posso proporre è:

predisporre un disco con uno schema di partizioni identico a quelo di origine (a meno delle dimensioni)
copiare il contenuto delle partizioni dal vecchio disco al nuovo usando il comando cp -ax in un sistema live o altro
aggiornare l'fstab nel nuovo disco (solo in caso di utilizzo di UUID)
reinstallare grub
Personalmente l'ho fatto varie volte.

Tornando agli errori del disco, magari si tratta giusto di un settore da riallocare (Pending sectors (http://www.ariolic.com/activesmart/smart-attributes/current-pending-sector-count.html)).
M'è capitato di recente sul mio portatile, ormai piuttosto vecchio. Sembra essersi assestato dopo che ho forzato la riallocazione del settore scrivendoci sopra (cioè sovrascivendo il file danneggiato con degli zeri, scatenando le attività di remapping).

Ah, visto che non hai specificato, ipotizzerei anche la possibilità che ci sia un contatto sporco/ballerino nel cavo. In fondo non credo che un disco da un tera e mezzo possa avere tantissime ore operative sul groppone...

Output di smartctl -a /dev/sdX ? (rimuovi il Serial Number dall'output)

[Erundur]

;37160110']Se il disco di destinazione soddisfa la condizione di essere esattamente uguale o almeno un bit più grande di quello di origine, si può semplicemente usare dd. (http://serverfault.com/questions/4906/using-dd-for-disk-cloning)
Tra l'altro non è difficile suddividere l'operazione in più passaggi, creando un'immagine intermedia compressa per poterla poi spostare sulla macchina di destinazione.

Altra condizione fondamentale: il sistema sul disco da clonare non deve essere avviato, ancora meglio se tutte le partizioni coinvolte nella copia non saranno nemmeno montate durante l'elaborazione.

Riguardo i file danneggiati, mi sembra di ricordare che dd cerchi di recuperare il più possibile, ma ad un certo punto dovrebbe arrendersi e proseguire.

Il problema di fondo potrebbe essere il fatto che dd copierà ogni singolo byte del disco di origine, anche tutti i file cancellati ma non azzerati sul disco, ed accederà ad ogni singolo settore, quindi analizzerà *tutti* i settori danneggiati per vari secondi.

Confermo

[_BlackTornado_]

;37160563']Purtroppo se il disco da clonare è grande occorre un disco nuovo più capiente...

La soluzione intermedia che ti posso proporre è:

predisporre un disco con uno schema di partizioni identico a quelo di origine (a meno delle dimensioni)
copiare il contenuto delle partizioni dal vecchio disco al nuovo usando il comando cp -ax in un sistema live o altro
aggiornare l'fstab nel nuovo disco (solo in caso di utilizzo di UUID)
reinstallare grub
Personalmente l'ho fatto varie volte.

Tornando agli errori del disco, magari si tratta giusto di un settore da riallocare (Pending sectors (http://www.ariolic.com/activesmart/smart-attributes/current-pending-sector-count.html)).
M'è capitato di recente sul mio portatile, ormai piuttosto vecchio. Sembra essersi assestato dopo che ho forzato la riallocazione del settore scrivendoci sopra (cioè sovrascivendo il file danneggiato con degli zeri, scatenando le attività di remapping).

Ah, visto che non hai specificato, ipotizzerei anche la possibilità che ci sia un contatto sporco/ballerino nel cavo. In fondo non credo che un disco da un tera e mezzo possa avere tantissime ore operative sul groppone...

Output di smartctl -a /dev/sdX ? (rimuovi il Serial Number dall'output)

La soluzione intermedia forse nel mio caso è la più interessante...
Intanto mi salvo le partizioni così, poi se il disco è ancora vivo quando arriva quello nuovo, tanto meglio.

Mi sto facendo tutti questi problemi perchè la Sheevaplug avvia l'OS non tramite Grub, bensì tramite U-Boot: quando ho configurato tutto il sistema, ricordo che ho passato parecchie giornate a cercare di capire come fargli fare il boot come dicevo io.
Mi sono appuntato qualcosa, ma mi risparmierei volentieri di dover rifare tutta la trafila... Copiare anche la partition table e poi "ingrandire" solo la partizione /home DOVREBBE (al momento non mi ricordo nulla della logica di U-Boot) mettermi al riparo da quest'eventualità.

Per i cavi, ho controllato l'eSata ed è apposto, tantè che il problema si presenta (con gli stessi files) anche se attacco l'hard disk via USB.
Quindi, o si è rotto il box esterno (anche se, trattandosi sempre degli stessi files, escluderei) oppure è l'hard disk.

Per il settore da riallocare, non ho controllato prima perchè ho preferito spegnerlo in attesa di avere il tempo di "mettere al sicuro" tutto quanto, considerando anche che l'hard disk ha 12500 ore di funzionamento.

Adesso comunque ho riacceso tutto... Aspetto che si avvia e ti dico (ci sta mettendo tanto... Credo che Debian stia proprio facendo il controllo di routine dell'hard disk).

PS: 12000 ore sono tante per un hard disk (Samsung EcoGreen 5400rpm)?

[_BlackTornado_]

Ecco lo smartctl:

sudo smartctl -a /dev/sda
smartctl 5.40 2010-07-12 r3124 [armv5tel-unknown-linux-gnueabi] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Model Family: SAMSUNG SpinPoint F2 EG series
Device Model: SAMSUNG HD154UI
Serial Number: cut
Firmware Version: 1AG01118
User Capacity: 1,500,301,910,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 3b
Local Time is: Sat Mar 24 16:24:37 2012 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 121) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: (19121) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 255) minutes.
Conveyance self-test routine
recommended polling time: ( 33) minutes.
SCT capabilities: (0x003f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

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 0x000f 099 085 051 Pre-fail Always - 3434
3 Spin_Up_Time 0x0007 071 071 011 Pre-fail Always - 9610
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 118
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12436
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 12621
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 101
13 Read_Soft_Error_Rate 0x000e 099 085 000 Old_age Always - 3434
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 6857
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 073 053 000 Old_age Always - 27 (Lifetime Min/Max 16/27)
194 Temperature_Celsius 0x0022 065 052 000 Old_age Always - 35 (Lifetime Min/Max 16/35)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 65834666
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 099 099 000 Old_age Always - 39
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 1
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0

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 Extended offline Completed: read failure 90% 12406 832770969
# 2 Extended offline Interrupted (host reset) 90% 12405 -
# 3 Short offline Completed without error 00% 12366 -
# 4 Short offline Completed without error 00% 12198 -
# 5 Short offline Completed without error 00% 12031 -
# 6 Short offline Completed without error 00% 11862 -
# 7 Short offline Completed without error 00% 11695 -
# 8 Short offline Completed without error 00% 11530 -
# 9 Short offline Completed without error 00% 11362 -
#10 Short offline Completed without error 00% 11193 -
#11 Short offline Completed without error 00% 11076 -
#12 Short offline Completed without error 00% 11037 -
#13 Short offline Completed without error 00% 11037 -
#14 Short offline Aborted by host 90% 11037 -
#15 Short offline Completed without error 00% 10899 -
#16 Short offline Completed without error 00% 10898 -
#17 Short offline Completed without error 00% 10898 -
#18 Short offline Completed without error 00% 10896 -
#19 Short offline Completed without error 00% 10895 -
#20 Short offline Completed without error 00% 10895 -
#21 Short offline Aborted by host 00% 10895 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.


Ecco qui...
Dal "39" sui pending sector mi pare di capire che ci siano effettivamente settori da riallocare, però mi pare di capire anche che non ce ne sono di riallocati, tantè che lo "Overall check" mi darebbe "passed", e anche il test "short" non mi trovava errori.
Però gli errori ci sono, e li rilevo sia io (su alcuni files) sia il test extended.

Dite che basta forzare il riallocamento dei settori e magari si stabilizza?

[Gimli[2BV!2B]]

Eh, hai ben 39 Pending Sector:197 Current_Pending_Sector 0x0012 099 099 000 Old_age Always - 39

Interessante studio made in Google che evidenzia quali valori S.M.A.R.T. indicano più probabilmente che il disco è sulla via del tramonto. (http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/it//archive/disk_failures.pdf)
Riguardo ai Pending Sector, definiti on probation (cioè sotto osservazione perché hanno mostrato errori in lettura):
after the first event, drives are 16 times more likely to fail within 60 days than drives with zero probational counts.


Esempi di vita operativa:

nel mio "server" casalingo c'è un solo disco 2.5'' Seagate Momentus 5400.2 che ha superato le 26000 ore e circa 1500 avvii. Ogni tanto ha un colpo di tosse ma tira avanti. Niente di brutto nei valori S.M.A.R.T.
nel mio desktop il sistema è in un vecchio Maxtor DiamondMax Plus 9 che ha superato le 23000 ore e circa 3000 avvii. Dava problemi in un'altro pc, probabilmente a causa di un cassetto difettoso, anche qui S.M.A.R.T. nella norma e comportamento impeccabile da quando ha cambiato casa
il portatile dovrebbe avere discretamente meno ore, l'ho sempre trattato con cura, ed è l'unico che ha settori riallocati...


Molto dipende dal caso, da eventuali colpi subiti (magari durante il trasporto), da eventuali sbalzi di tensione, componenti con minimi difetti, temperature operative estremamente alte (> 45 C°) o troppo basse (< 25 C°), ecc...

[Gimli[2BV!2B]]

Ho letto dopo la tua modifica.

39 sono tanti, ho visto dischi con valori di riallocazione inferiori a dieci continuare a funzionare per tempi discreti.
Occorrerebbe andare a caccia di ognuno e scriverci sopra per permettere al disco di capire se non funziona più, in tal caso passando nei Reallocated, oppure di considerarlo ancora sano togliendolo dall'osservazione.
Il metodo più veloce dovrebbe essere una bella sovrascrittura completa e distruttiva di tutto il contenuto del disco...

[_BlackTornado_]

;37161154']Ho letto dopo la tua modifica.

39 sono tanti, ho visto dischi con valori di riallocazione inferiori a dieci continuare a funzionare per tempi discreti.
Occorrerebbe andare a caccia di ognuno e scriverci sopra per permettere al disco di capire se non funziona più, in tal caso passando nei Reallocated, oppure di considerarlo ancora sano togliendolo dall'osservazione.
Il metodo più veloce dovrebbe essere una bella sovrascrittura completa e distruttiva di tutto il contenuto del disco...

Insomma molto probabilmente il disco è andato :D
Per evitare la sovrascrittura completa e distruttiva (anzi, principalmente perchè sono curioso di capire un pò come funziona sta roba) sto seguendo questa guida:
http://smartmontools.sourceforge.net/badblockhowto.html

Purtroppo, il bad block della prima LBA mi risulta "in uso", solo che poi quando arriva il momento di usare debugfs sembra che non mi trovi l'inode (si blocca). Magari ripetendo l'operazione 39 volte e agendo solo sui files nel blocco incriminato riuscivo a evitarmi la sovrascrittura completa.

Grazie per le info comunque.

[eaman]

I consigli per un uso normale di dd (smontare i filesystem, da altro sistema operativo) sono generalmente validi, ma non vanno bene per il tuo caso.

1. Il back-up va' fatto prima di danneggiare i dati. Ora copi delle robe che poi magari quando ti serviranno si riveleranno compromesse.

1.1 Se il supporto ti sta lasciando: mai spegnere o smontare il filesystem. Copia immediatamente il piu' possibile con rsync o cp su un altro supporto con un filesystem nuovo.
Non spegnere un sistema con hd danneggiati: potresti non riuscire piu' a leggere un'altra volta le tabelle delle partizioni o quelle di allocazione dei files, riavviare i raid o gli LVM.
Per altro spegnimento e riavvio sono tra gli eventi piu' devstanti per un supporto di storaggio danneggiato.

Non vorrei sembrare scontroso o poco rispettoso dei precedenti posts, ma se hai un filesystem danneggiato per via di un hard disk che sta tirando gli ultimi non ti metti a fare una copia del contenuto raw con dd, usi un tool a livello piu' alto che sia capace di 'interpretare' anche i metadati del filesystem.

[Gimli[2BV!2B]]

Non ho mai avuto necessità di recuperare il contenuto di un disco seriamente danneggiato.
So che nel caso si presentino errori gravi sia meglio evitare di spegnere, però mi verrebbe in mente solo nei casi che riguardano la testina (i classici clunk che ho sentito solo in hard disk altrui già defunti), sarei più rilassato in casi di errori di lettura per settori danneggiati.
Questo caso inizia già ad essere un po' border line per il numero di settori coinvolti, però non sarei assolutamente pessimista.

Per quale motivo dd è da evitare e quali strumenti alternativi occorrerebbe utilizzare?
Sarei dell'idea che usando il lineare dd si stressi il meno possibile l'hardware danneggiato, per poi poter eventualmente utilizzare strumenti software più sofisticati per estrarre i dati dall'immagine recuperata.

[_BlackTornado_]

Allora... Questa cosa è curiosa...

Ero quasi certo che i settori danneggiati fossero nella partizione /home (sia perchè i files in cui mi dava l'errore erano tutti li, sia per una questione statistica: i primi 1063 blocchi erano per l'OS, il restante miliardo e mezzo era home o swap.

Non avendo files importanti nella home (a parte qualche file di configurazione, la home veniva backuppata periodicamente) ho provato a svuotare la partizione (banalmente cancellando i files da windows, visto che la partizione era condivisa).

Come ho svuotato la prima cartella, però, mi è sparito tutto il resto: in pratica, la mia /home risultava vuota.
Ho provato un reboot, e infatti mi ha dato una marea di errori di I/O e mi ha fatto aprire la console di ripristino. Io non ho ripristinato un cavolo e mi sono limitato a dirgli di avviare il sistema comunque.

Con mia sorpresa, il sistema si è avviato, pur protestando che non aveva più la /home. A quel punto, perso per perso, mi sono detto "perchè non proviamo a scriverci qualche zero sopra?" ed ho dato questo comando:

dd if=/dev/zero of=/dev/sda3 bs=4096

Che (se non ho capito male) mi dovrebbe riempire di zeri la partizione sda3 (ovvero la home).

L'ho lasciato un paio d'ore, poi visto che non finiva l'ho interrotto. Aveva riempito 450 giga (quindi il comando stava funzionando, dovevo solo lasciarlo stare).

Per curiosità ho provato a dare uno:

smartctl -A /dev/sda

ed ecco il risultato:

smartctl 5.40 2010-07-12 r3124 [armv5tel-unknown-linux-gnueabi] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
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 0x000f 099 085 051 Pre-fail Always - 3434
3 Spin_Up_Time 0x0007 091 091 011 Pre-fail Always - 3750
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 119
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12436
9 Power_On_Hours 0x0032 098 098 000 Old_age Always - 12625
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 102
13 Read_Soft_Error_Rate 0x000e 099 085 000 Old_age Always - 3434
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 6857
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 063 053 000 Old_age Always - 37 (Lifetime Min/Max 36/37)
194 Temperature_Celsius 0x0022 064 052 000 Old_age Always - 36 (Lifetime Min/Max 35/39)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1317324
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 100 099 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 1
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 253 253 000 Old_age Always - 0


In pratica, i 39 pending sectors sono tutti spariti, ma i reallocated sectors sono rimasti a 0.
Riavviando, il sistema continua a protestare e a trovarmi mille IO error, ma se poi lo faccio avviare per forza, si avvia (anche se senza la /home).

Ora, il sistema credo che ormai sia compromesso, e vabbè... Ma l'hard disk che ha fatto? Possibile che di 39 settori "pending" nessuno fosse effettivamente da riallocare?

Ora ho lanciato un selftest lungo... Vediamo che mi tira fuori.

[Gimli[2BV!2B]]

Il sistema non è compromesso se si rimuove la home, prova a riformattare la /home nel tipo di file system che era prima (probabilmente ext4) e controlla che sia impostata correttamente in /etc/fstab (come ho accennato è probabile che sia impostata tramite UUID e questo ID dovrebbe essere cambiato in seguito alle tue operazioni).

I valori sono molto meno sospetti, resta un Offline_Uncorrectable che non ricordavo appartenesse alla stessa categoria dei precedenti.
Per intervenire anche su questo settore è necessario un offline test (http://daemon-notes.com/articles/other/smartmontools/offline-uncorrectable):smartctl -t offline /dev/sda

Ciò che non capisco chiaramente è quando scrivi di IO error, io l'ho interpretato come errori dovuti ai tentativi del sistema di montare ed accedere ad una partizione che si aspetta formattata in un certo modo ma che non esiste più, mentre se sono reali errori di lettura/scrittura resta il forte sospetto che i problemi al disco non siano svaniti.

[_BlackTornado_]

;37162865']Il sistema non è compromesso se si rimuove la home, prova a riformattare la /home nel tipo di file system che era prima (probabilmente ext4) e controlla che sia impostata correttamente in /etc/fstab (come ho accennato è probabile che sia impostata tramite UUID e questo ID dovrebbe essere cambiato in seguito alle tue operazioni).

I valori sono molto meno sospetti, resta un Offline_Uncorrectable che non ricordavo appartenesse alla stessa categoria dei precedenti.
Per intervenire anche su questo settore è necessario un offline test (http://daemon-notes.com/articles/other/smartmontools/offline-uncorrectable):smartctl -t offline /dev/sda

Ciò che non capisco chiaramente è quando scrivi di IO error, io l'ho interpretato come errori dovuti ai tentativi del sistema di montare ed accedere ad una partizione che si aspetta formattata in un certo modo ma che non esiste più, mentre se sono reali errori di lettura/scrittura resta il forte sospetto che i problemi al disco non siano svaniti.

Offline test lungo eseguito e portato a termine senza errori (mentre prima denunciava dei read error), anche l'Offline_Uncorrectable è sparito... Ora lo smartctl -A mi da questo:

smartctl 5.40 2010-07-12 r3124 [armv5tel-unknown-linux-gnueabi] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
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 0x000f 099 085 051 Pre-fail Always - 1717
3 Spin_Up_Time 0x0007 091 091 011 Pre-fail Always - 3750
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 119
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000f 100 100 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0025 100 100 015 Pre-fail Offline - 12008
9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 12642
10 Spin_Retry_Count 0x0033 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0012 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 102
13 Read_Soft_Error_Rate 0x000e 099 085 000 Old_age Always - 1717
183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0
184 End-to-End_Error 0x0033 100 100 000 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 6857
188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0022 067 053 000 Old_age Always - 33 (Lifetime Min/Max 33/39)
194 Temperature_Celsius 0x0022 067 052 000 Old_age Always - 33 (Lifetime Min/Max 33/40)
195 Hardware_ECC_Recovered 0x001a 100 100 000 Old_age Always - 1635528
196 Reallocated_Event_Count 0x0032 100 100 000 Old_age Always - 0
197 Current_Pending_Sector 0x0012 100 099 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 100 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 1
200 Multi_Zone_Error_Rate 0x000a 100 100 000 Old_age Always - 0
201 Soft_Read_Error_Rate 0x000a 100 100 000 Old_age Always - 0


Praticamente, a parte il CRC error count a 1, il disco ora sembra perfettamente sano.

Purtroppo però in fase di avvio gli IO error sono VERAMENTE IO errors... Anche se forse in effetti sono solo legati al fatto che non trova più la home. Adesso provo a formattare e ad aggiornare fstab, poi vi dico.

[Gimli[2BV!2B]]

Gli UDMA CRC error sono errori di trasmissione tra il disco e la scheda madre ed è normale che se possano accumulare nell'ordine delle decine durante la vita di un disco integro.
Sono solitamente dovuti a picchi di rumore che scambiano almeno un bit durante il transito sul cavo. Se crescono velocemente sono sintomo di cavi rovinati, troppo lunghi o eccessivamente vicini a componenti che ne disturbano i segnali, oppure cassetti esterni di scarsa qualità che non trasmettono bene il segnale.

Ora i valori sono praticamente normali, vediamo come si comporta dopo il ripristino della partizione.

[_BlackTornado_]

;37164774']Gli UDMA CRC error sono errori di trasmissione tra il disco e la scheda madre ed è normale che se possano accumulare nell'ordine delle decine durante la vita di un disco integro.
Sono solitamente dovuti a picchi di rumore che scambiano almeno un bit durante il transito sul cavo. Se crescono velocemente sono sintomo di cavi rovinati, troppo lunghi o eccessivamente vicini a componenti che ne disturbano i segnali, oppure cassetti esterni di scarsa qualità che non trasmettono bene il segnale.

Ora i valori sono praticamente normali, vediamo come si comporta dopo il ripristino della partizione.

I CRC ci stanno... Anzi, sono anche pochi, considerando che l'hard disk è in un box esterno collegato in eSata che spesso e volentieri viene spostato mentre sta funzionando.

Ebbene, apparentemente... Funziona tutto.
Ho riformattato la partizione, aggiornato l'fstab e fatto ripartire tutto... Niente più errori.
Al primo login non trovava la home, ma è bastato creare una cartella con il nome del mio utente e ora quella è diventata la mia home.

Ovviamente, ho perso qualche configurazione, ma apparentemente tutto sta funzionando come dovrebbe.
Adesso ho messo a scaricare qualche torrent, ma diciamo che la situazione lascia ben sperare.

Che dire... Recuperare hard disk e sistema formattando solo la home sarebbe una gran soddisfazione :D

[eaman]

;37162023']Non ho mai avuto necessità di recuperare il contenuto di un disco seriamente danneggiato.
So che nel caso si presentino errori gravi sia meglio evitare di spegnere, però mi verrebbe in mente solo nei casi che riguardano la testina (i classici clunk che ho sentito solo in hard disk altrui già defunti), sarei più rilassato in casi di errori di lettura per settori danneggiati.
In genere quando emerge un 'cluster' di errori per via di una rottura il supporto inizia a degenerare rapidamente.
Se e' acceso da molto c'e' caso che parte dei dati danneggiati vengano letti da RAM e si noti meno, poi vai a sapere cosa effettivamente c'e' scritto su quei blocchi.

ES. una volta era stato sovrascritto 'un po'' del il primo hd di un raid con un lvm sopra: fin tanto che il sistema era acceso si poteva leggere la vecchia tabella delle partizioni, struttura del raid e dell'LVM. Se fosse stato spento c'era da tirare a caso con le partizioni e sperare di beccare dei blocchi ridondanti con i metadati di RAID, LVM, FS.

Questo caso inizia già ad essere un po' border line per il numero di settori coinvolti, però non sarei assolutamente pessimista.Il back up deve farlo comunque.
Per altro non so bene se dipenda da come sono alimentati (o probabilmente dal ciclo di stan-up suspend standby che fanno) ma noto una moralita' superiore dei supporti esterni rispetto a quelli interni da 3.5.

Per quale motivo dd è da evitare e quali strumenti alternativi occorrerebbe utilizzare?
DD legge tutto senza esclusioni, se il supporto e' gia deteriorato meno lo si fa muovere meglio e'. Per altro se e' acceso da molto molti dati possono essere in RAM senza biosogno di accedere fisicamente ad essi. poi nei metadati, a secondo del filesystem, ci possono essere informazioni utili per verificarne i contenuti o la correttezza (lunghezza, date, magari un CRC).

DD non e' selettivo: in una situazione normale mi aspetto di avere un backup (incrementale) di una certa data affidabile, posso vedere quali files sono cambiati nel frattempo e copiare solo quelli evitando di copiare roba scassato su raba buona.

Sarei dell'idea che usando il lineare dd si stressi il meno possibile l'hardware danneggiato, per poi poter eventualmente utilizzare strumenti software più sofisticati per estrarre i dati dall'immagine recuperata.
Sicuramente con dd non fai tanti spostamenti di testina che possono essere debilitanti (he sopratutto se hai le testine che cioccano) pero' mi viene da pensare che debba leggere tutto e quindi molto di piu'. Magari anche il fatto che non peschi da RAM, finisca per vuotare la RAM dai file in cache che poi andranno ricaricati (magari deteriorati), puo' essere un ulteriore stress.

Copiando ad alto livello si ha un riscontro immediato su quali file danno dei problemi, che e' piu' significativo di eventuali riferimenti a singoli blocchi.
E relativamente piu' consistente fare una copia con cp / rsync se non si vuole smontare il filesystem (cosa che eviterei se questo e' danneggiato per paura di non riuscire piu' a montarlo).

Ripeto: questo da sistema live che presenta errori gravi che fanno pensare di non riusciure a riprenderlo: se il sistema e' stato spento in genere anche io faccio un dd. Se e' un intervento 'professionale' io non mi azzardo a lavorare sui supporti danneggiati (che poi andranno in mano a un recupera dati e meno girano meglio e'): faccio un dd o partimage di tutto e provo a scasinare sulle immagini.

BTW: da un po' per i backup al volo mi piace fsarchiver [1]: tiene un checksum dei singoli files.

YMMV

1. http://www.fsarchiver.org/Main_Page

[eaman]

[CUT]
Che dire... Recuperare hard disk e sistema formattando solo la home sarebbe una gran soddisfazione :D

Io ti faccio gli auguri, e ti consiglio di fare un backup.
Magari controlla che il disco non venga mandato in standby (che ad andare su e giu' si stressa), e tienilo d'occhio dmesg:
dmseg | tail -n 20
E con gli smart tools.
Ogni tanto smontalo e fagli fare un fsck.

E' sicuro che prima o poi gli hd si schiantano, piuttosto che il contrario.

[_BlackTornado_]

Io ti faccio gli auguri, e ti consiglio di fare un backup.
Magari controlla che il disco non venga mandato in standby (che ad andare su e giu' si stressa), e tienilo d'occhio dmesg:
dmseg | tail -n 20
E con gli smart tools.
Ogni tanto smontalo e fagli fare un fsck.

E' sicuro che prima o poi gli hd si schiantano, piuttosto che il contrario.

Oh parliamoci chiaro, il backup dei dati veramente importanti c'è già, ed è anche doppio :D

È solo che settare e configurare il sistema non è stato proprio semplicissimo per me, quindi salvare anche quello mi risparmierebbe qualche ora di smanettamenti.
In ogni caso, anche perdendo tutto ora, si tratta comunque solo di reinstallare una debian su ARM, niente di irrecuperabile...

In ogni caso, mi ero preoccupato all'epoca di non mandare in standby l'hard disk (e infatti, lo start-stop count è 119 e il power cycle è 102, il che se non mi sbaglio dovrebbe significare che l'hard disk è andato in standby solo 17 volte in 12600 ore di funzionamento H24, oltre al fatto che l'ho spento solo 100 volte in un anno e mezzo).
Anche la temperatura è sempre stata sotto controllo (non supera mai i 42 gradi nemmeno d'estate, pur essendo in un box esterno non ventilato).

Rimane da spiegare come mai si siano creati quei 39 pending sectors.. Alla fine non erano da riallocare, ma qualcosa dev'essere successo, quindi è bene non dare più la piena fiducia all'hard disk :D

[Gimli[2BV!2B]]

Grazie dei chiarimenti, eaman.
Il caso del RAID + LVM con i dati fondamentali cancellati necessita davvero sangue freddo, oltre al primo passo fondamentale: rendersi conto di quel che è successo.

Anch'io son convinto che i dischi esterni siano davvero più a rischio. A naso darei buona colpa all'alimentazione, ricordando soprattutto i versi che fanno se si scollegano pochi secondi dopo l'umount, poi le botte che si prendono durante il trasporto o, peggio, durante l'uso e, per finire, la frequenza di avvii in relazione al tempo medio di utilizzo.

Riguardo ai dati presenti in RAM, direi che le tue osservazioni sono molto valide se il disastro avviene in macchine con alti uptime, io sono abituato a ragionare in ambito meno professionale e non l'ho proprio considerato.

FSArchiver sembra molto interessante, soprattutto il fatto che in caso di backup parzialmente corrotto sia in grado di riconoscere i file danneggiati grazie ai checksum, ma possa ripristinare tutto ciò che gli risulta essere integro.

Tornando a _BlackTornado_, il disco sembra essere tornato in ordine.
Come già consigliato continua a far backup e tieni sotto osservazione la salute.

Per esempio questa è la mia impostazione smartd (http://smartmontools.sourceforge.net/man/smartd.8.html) in /etc/smartd.conf (però non mi sono ancora arrivati messaggi oltre a quelli di test, quindi non sono realmente certo che sia corretta):/dev/sda -d sat -n standby -H -I 194 -C 197 -U 198 -W 3,40,45 -m [email protected]
Questo è invece il parametro di hdparm (http://unixhelp.ed.ac.uk/CGI/man-cgi?hdparm) che ho impostato in /etc/hdparm.conf per impedire al disco da 2.5'' di parcheggiare le testine di continuo (potrebbe non servire/essere possibile nel tuo caso):/dev/sda {
apm = 254
}

Il motivo dei 39 pending non credo sia possibile individuarlo con certezza... come hai scritto non fidarti ad occhi chiusi di quel disco, ma potrebbe davvero non aver subito danni permanenti.

[_BlackTornado_]

;37166219']Per esempio questa è la mia impostazione smartd (http://smartmontools.sourceforge.net/man/smartd.8.html) in /etc/smartd.conf (però non mi sono ancora arrivati messaggi oltre a quelli di test, quindi non sono realmente certo che sia corretta):/dev/sda -d sat -n standby -H -I 194 -C 197 -U 198 -W 3,40,45 -m [email protected]
Questo è invece il parametro di hdparm (http://unixhelp.ed.ac.uk/CGI/man-cgi?hdparm) che ho impostato in /etc/hdparm.conf per impedire al disco da 2.5'' di parcheggiare le testine di continuo (potrebbe non servire/essere possibile nel tuo caso):/dev/sda {
apm = 254
}

Perfetto...
In realtà l'hard disk già lo controllavo tramite uno script da lanciare con cron che prima faceva il backup e poi mi controllava l'hard disk con un selftest corto...
Solo che il selftest corto non mi rilevava alcun errore nemmeno con i pending sectors, e quindi mi sono accorto che c'era qualcosa che non andava solo quando sono cominciati ad apparire errori nell'utilizzo comune.
Magari adesso modifico lo script per inserire anche dei warning in caso di variazioni dei parametri smart più importanti (settori pending e riallocati, CRC).

In ogni caso ringrazio tutti. Oltre ad aver probabilmente recuperato un hard disk, questo post è stato decisamente istruttivo ben oltre le mie aspettative (mi aspettavo una risposta tipo "usa questo tool" e invece mi sono fatto un idea di come intervenire in situazioni "di emergenza" tipo questa).

[eaman]

[cut]
In ogni caso, anche perdendo tutto ora, si tratta comunque solo di reinstallare una debian su ARM, niente di irrecuperabile...
Ma anche meno: basta che ti fai un backup della cartella /etc e ti salvi la lista dei pacchetti installati: tanto i pacchetti per l'installazione sono gia' backuppati sui mirror :)

Rimane da spiegare come mai si siano creati quei 39 pending sectors.. Alla fine non erano da riallocare, ma qualcosa dev'essere successo, quindi è bene non dare più la piena fiducia all'hard disk :D

Che ti posso dire: io ho tentuto 5/6 servizi su un nslu2 per piu' di un anno con debian ed e' sempre andato bene, lo ho re -installato poco tempo fa' e ci sono andate un paio d'ore, ma e' un baracchino debole: ha 28mb di ram.

L'importante e' avere una copia dei _tuoi_ dati, il back up dell'OS e', diciamo, una comodita'.

[nightborn]

Confermo (da bravo testardo dei backups) la validità delle affermazioni di eaman, specie su sistemi accesi tutto il giorno e con raid,lvm, etc.
Noto anche da parte mia una certa predisposizione alla moria degli hard disk
esterni 2.5" (i 3.5" sembrano comportarsi meglio).
Se i tuoi crucci sono le configurazioni, come già segnalato, una copia di /etc/passwd e un colpo di dd:

dd if =/dev/device_usb of=/directory_che_voglio/mbr.dd bs=152 count=1

per portarsi via mbr e tavola delle partizioni dovrebbero bastarti.
Se vuoi anche un file di promemoria delle tue partizioni, un bel fdisk -l > /directory_che_voglio/partitions.txt potrebbe tornarti utile.

Se vuoi combattere con gli errori disco e usare dd, l'opzione conv=noerror ti aiuterà per non farlo fermare in caso di errori "tosti".

[nightborn]

non mi riesce la modifica post...

errata corrige:
bs=512

[eaman]

;37166219']Grazie dei chiarimenti, eaman.
Il caso del RAID + LVM con i dati fondamentali cancellati necessita davvero sangue freddo, oltre al primo passo fondamentale: rendersi conto di quel che è successo.

Mi ricordo una volta da un cliente: io dopo un'oretta mi ero gia' fatto un'idea del (totale disastro irrimediabile) capitato. Ma ci sono voluti due giorni perche' il cliente piano piano potesse entrare nell'ordine di idee adatto ad accettare la cosa... Brrr!

[Gimli[2BV!2B]]

@nightborn, vero, conv=noerror
Anch'io per il backup della mia macchinetta casalinga mi limito ad un mega di roba molto utile per poter ripristinare in tempi ragionevoli (tutte /etc, crontab, lista pacchetti installati, lista partizioni, una manciata di script in /usr/local/sbin), il resto lo considero sacrificabile.

@eaman, devono essere stati proprio bei momenti... :eek:
Non invidio i sistemisti. Quando va tutto bene, perché hanno fatto bene il loro lavoro, sono ignorati. Spesso vengono avvisati di lavori da fare in ritardo o con tempi strettissimi. Un minimo errore può avere conseguenze mostruose.
Io son programmatore ed ho spesso necessità di molestarli. Spero di non stargli troppo sulle balle, anche se mi è capitato più volte di costringerli a lavoro extra...

[nightborn]

;37172767']
@eaman, devono essere stati proprio bei momenti... :eek:
Non invidio i sistemisti. Quando va tutto bene, perché hanno fatto bene il loro lavoro, sono ignorati. Spesso vengono avvisati di lavori da fare in ritardo o con tempi strettissimi. Un minimo errore può avere conseguenze mostruose.
Io son programmatore ed ho spesso necessità di molestarli. Spero di non stargli troppo sulle balle, anche se mi è capitato più volte di costringerli a lavoro extra...

Da quando in qua esistono programmatori il cui kernel carica correttamente i moduli empatia, rispetto e correttezza ? ;) E' anche vero che da parte nostra dovremmo spesso liberare risorse rilasciando i moduli disprezzo e scortesia....

[Gimli[2BV!2B]]

@nightborn, se non si mantiene un buon rapporto e non si cerca di avere un minimo di sovrapposizione, confronto e scambio sulle competenze si ottengono disastri su disastri... invece di solo qualche disastro ogni tanto :stordita: