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.
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_]

Originariamente inviato da 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.
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 è:

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

Personalmente l'ho fatto varie volte.

Tornando agli errori del disco, magari si tratta giusto di un settore da riallocare (Pending sectors).
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]

Originariamente inviato da 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.
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_]

Originariamente inviato da Gimli[2BV!2B]

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

La soluzione intermedia che ti posso proporre è:

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

Personalmente l'ho fatto varie volte.

Tornando agli errori del disco, magari si tratta giusto di un settore da riallocare (Pending sectors).
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.
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_]

Originariamente inviato da 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...

Insomma molto probabilmente il disco è andato
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:

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_]

Originariamente inviato da 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:

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_]

Originariamente inviato da 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.

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

[eaman]

Originariamente inviato da 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.

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]

Originariamente inviato da _BlackTornado_

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

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_]

Originariamente inviato da eaman

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

È 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