|
Loading
Home » Computer » Linux » Backup non riuscito con dd
| Backup non riuscito con dd [messaggio #34514] |
mar, 28 dicembre 2010 15:16  |
 JohnnyNewbie
Messaggi: 24
Registrato: novembre 2010 |
Junior Member |
|
|
Sto copiando le partizioni attualmente presenti sull'hd
del mio portatile:
hdc1 ---> Partizione di recovery predisposta da asus
hdc2 ---> Win XP preinstallato da asus
hdc3 ---> Win XP reinstallato fresco per test del CD
hdc6 ---> Slackware-12.1
Ecco l'output di fdisk:
____________________
# fdisk -l /dev/hdc
Disk /dev/hdc: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xa8d32665
Device Boot Start End Blocks Id System
/dev/hdc1 1 230 1847443+ 1b Hidden W95 FAT32
/dev/hdc2 * 231 3014 22362480 c W95 FAT32 (LBA)
/dev/hdc3 3015 3779 6144862+ 7 HPFS/NTFS
/dev/hdc4 3780 4864 8715262+ f W95 Ext'd (LBA)
/dev/hdc5 3780 3906 1020096 82 Linux swap
/dev/hdc6 3907 4864 7695103+ 83 Linux
------------------------------------------------------------ -
Ok, ho backuppato con dd le partizioni hdc1 hdc3 e
hdc6.
Invece durante la copia della hdc2 incorro in un errore
di lettura...:
_______________________________
# dd if=/dev/hdc2 of=winxp-hdc2
dd: reading `/dev/hdc2': Input/output error
3035360+0 records in
3035360+0 records out
1554104320 bytes (1,6 GB) copied, 157,416 s, 9,9 MB/s
------------------------------------------------------
La partizione è di circa 20 GB mentre la copia si ferma
ad 1.6GB e salta fuori l'errore soprariportato.
Ora possibilmente usando sempre "dd", dove sta il
problema e come risolverlo?
Grazie mille in anticipo.
|
|
| | | | | | | |
| Re: Backup non riuscito con dd [messaggio #34535 è una risposta a message #34534] |
mer, 29 dicembre 2010 10:29  |
Roberto
Messaggi: 892
Registrato: maggio 2009 |
Senior Member |
|
|
JohnnyNewbie ha scritto:
> roberto <rpoggiNOSPAM@softhome.net.invalid> wrote:
>>> Fermati, ma intendi a livello fisico?
>> Al 99% si'.
>
> Maledizione...
> Ipotesi ottimistiche?
Ottimistiche?
Ti ho lasciato un 1%, cosa vuoi di piu'? ;-)
> Voglio dire, ci sono possibilità che i settori del disco
> non siano dannegiati e la causa dell'errore sia
> un'altra?
Ci sono, ma sono scarsissime.
La prova definitiva è ripetere l'operazione, se puoi, con
un altro pc/cavo/adattatore (non ricordo se era connesso
direttamente o conadattore USB).
Se si ferma nello stesso punto, hai poche speranze.
Puoi provare (dopo aver recuperato i dati!!) con una utility
che "rigenera" il disco, forzando la rimappatura dei settori
guasti, ma un disco che comincia a denunciare settori guasti
non e' affidabile per definizione.
>
> Presumo che ci sia qualche altro tool apposito per
> verificare lo stato del disco. Mi faccio una ricerca in
> google, nel frattempo se aveste suggerimenti in merito
> a tools del genere... dite pure eh.
Io ho usato hdrecover con discreti risultati.
Ma ho sempre dichiarato i dischi usciti da quel tool come non
affidabili, e li uso come contenitori di materiale poco importante
o in seconda copia.
>
>
>>> Ovvero disco da buttare?
>
> Come rispondete a questa brutta domanda?
Senza avere il disco sottomano?
Difficile.
--
|Save our planet!
Ciao |Save wildlife!
roberto |For your E-MAIL use ONLY recycled Bytes !!
|roberto poggi rpoggi@softhome.net
|
|
| | |
| Re: Backup non riuscito con dd [messaggio #34546 è una risposta a message #34542] |
mer, 29 dicembre 2010 15:36 |
Lem Novantotto
Messaggi: 166
Registrato: novembre 2010 |
Senior Member |
|
|
roberto ha scritto:
> Se si cominciano a vedere settori guasti, essi possono crescere col
> tempo, e condurti ad una possibile perdita dati.
Però non dispererei.
Da anni ho, su un portatile, un disco da 120GB con più di 10GB (sic!) di
bad sectors. Non aumentano, e il disco funziona ancora benone.
Il fattaccio avvenne quando, con full floppato, persi una vagonata di
euro in favore di un tizio che stava sotto a un treno ma chiuse quads
runner-runner al river.
Siccome in quella mano mi dimezzai il bankroll, ammetto che sbatacchiai
un po' il laptop sul tavolino, ecco... Ma non per più di un quarto d'ora
eh!
--
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________ _________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/ http://www.worldcommunitygrid.org/index.jsp
http://boinc.berkeley.edu/projects.php
|
|
| | | |
| Re: Backup non riuscito con dd [messaggio #34615 è una risposta a message #34594] |
ven, 31 dicembre 2010 20:54 |
Lem Novantotto
Messaggi: 166
Registrato: novembre 2010 |
Senior Member |
|
|
JohnnyNewbie ha scritto:
>>> 196 Reallocated_Event_Count - 2
>>> 197 Current_Pending_Sector - 3
>>> 198 Offline_Uncorrectable - 0
> ___________________________________
> 196 Reallocated_Event_Count 3
> 197 Current_Pending_Sector 2
> 198 Offline_Uncorrectable 0
> -----------------------------------
>
> Che cosa ne pensate?
A quanto capisco io, per avere un quadro corretto ti serve anche il
valore dell'ID 5.
ID 5: numero dei settori effettivamente rimappati
ID 196: numero dei tentativi di rimappatura, andati a buon fine o no
Insomma se sono stati rimappati 12 settori, l'ID 5 sarà 12 e l'ID 196
sarà *almeno* 12.
L'ID 197 ti dà il numero di settori che stanno dando problemi in lettura:
cioè normalmente non si riesce a leggerli (ma forse ci si riuscirebbe con
per esempio programmi come hdrecover, che provano molte volte a leggere
un settore, riposizionando le testine tra un tentativo e l'altro e yada
yada: per questo non vengono rimappati subito). Nota che il disco può
benissimo cambiare idea su un settore: adesso non riesce a leggerlo e
aumenta il valore di ID 197, domani ci riesce e diminuisce il valore di
ID 197.
Comunque quel che è successo è che è stato rimappato un settore: hdrecover
ha provato a leggerlo un fracco di volte, nisba[*], e allora il modo di
forzare la rimappatura di un settore che il disco ha già segnalato come
avente problemi in lettura è ordinare una scrittura: il disco non può
scrivere lì, perché ha tutte le ragioni di credere che poi non riuscirà a
leggere quanto avrà scritto[**], e allora prima di scrivere rialloca il
settore, o almeno ci prova (magari non ci sono più spare sectors, e
allora non ce la fa).
[*] Se invece ci fosse riuscito, il disco avrebbe automaticamente
rimappato il settore copiandoci i dati recuperati. Insomma se un disco
*ripetutamente* non riesce a leggere un settore, e poi invece ci riesce,
non si fa scappare l'occasione fortunata e rimappa salvando i dati. O
almeno dovrebbe far così.
[**] Tale previsione non si avvererebbe per forza: magari il disco non
riesce a leggere quel che c'è scritto *adesso* perché il settore non era
stato scritto bene (magari per uno scossone, che ne so). Per questo in
certe situazioni credo possa venire in aiuto badblocks (di hdrecover non
so, non mi pare mica molto documentato e io il codice non lo so leggere).
AFAICT badblocks può fare tre test: uno solo read, uno read-write
(teoricamente non distruttivo: credo che legga e poi provi a scriverci
sopra la stessa cosa) e un write-read distruttivo: scrive dei pattern e
poi prova a leggerli. Ma una cosa così ti brucia via tutta la partizione.
Alla fine ti restano ancora due settori, che pare dessero problemi in
lettura già prima (erano 3, 1 forzosamente rimappato, son diventati 2).
Se hdrecover fosse riuscito a leggerli, avrebbero dovuto essere rimappati
automaticamente, come abbiamo visto. Se non fosse riuscito a leggerli,
avrebbe dovuto proporti la rimappatura forzata tramite sovrascrittura.
Prima di porci ulteriori domande, mi confermi che hai eseguito uno:
smartctl -t offline /dev/quelcheè
dopo hdrecover?
--
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________ _________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/ http://www.worldcommunitygrid.org/index.jsp
http://boinc.berkeley.edu/projects.php
|
|
|
| Re: Backup non riuscito con dd [messaggio #34723 è una risposta a message #34615] |
mer, 05 gennaio 2011 16:53 |
JohnnyNewbie
Messaggi: 24
Registrato: novembre 2010 |
Junior Member |
|
|
Lem Novantotto <Lem98@hotmail.com> wrote:
> JohnnyNewbie ha scritto:
>
>>>> 196 Reallocated_Event_Count - 2
>>>> 197 Current_Pending_Sector - 3
>>>> 198 Offline_Uncorrectable - 0
>
>> ___________________________________
>> 196 Reallocated_Event_Count 3
>> 197 Current_Pending_Sector 2
>> 198 Offline_Uncorrectable 0
>> -----------------------------------
>>
>
> A quanto capisco io, per avere un quadro corretto ti serve anche il
> valore dell'ID 5.
ID 5 risulta pari a 0
> ID 5: numero dei settori effettivamente rimappati
> ID 196: numero dei tentativi di rimappatura, andati a buon fine o no
> Alla fine ti restano ancora due settori, che pare dessero problemi in
> lettura già prima (erano 3, 1 forzosamente rimappato, son diventati 2).
> Se hdrecover fosse riuscito a leggerli, avrebbero dovuto essere rimappati
> automaticamente, come abbiamo visto. Se non fosse riuscito a leggerli,
> avrebbe dovuto proporti la rimappatura forzata tramite sovrascrittura.
>
> Prima di porci ulteriori domande, mi confermi che hai eseguito uno:
>
> smartctl -t offline /dev/quelcheè
>
> dopo hdrecover?
Non ricordo se l'avevo dato subito sinceramente.
Provo a darlo adesso e poi a rivedere cosa dice
smarctl -A /dev/hdc
Oppure faccio girare ancora hdrecover e do
"smartclt -t" subito dopo?
|
|
| |
| Re: Backup non riuscito con dd [messaggio #34725 è una risposta a message #34724] |
mer, 05 gennaio 2011 23:58 |
Lem Novantotto
Messaggi: 166
Registrato: novembre 2010 |
Senior Member |
|
|
JohnnyNewbie ha scritto:
> Ok. A voi il responso.
Per quanto mi riguarda, non sai in che mani ti metti. ;)
Il mio responso è "Mah!".
Bello che hdrecover non trovi più nulla che non va, però non capisco quei
valori forniti da smartctl. Non sono certo un esperto, però mi paiono
incoerenti. Magari non è niente, magari dipende anche dal disco, cioè da
come lui gestisce i dati smart... Non so se c'è uno standard poi così
rispettato, insomma.
Visto che stai per brasare tutto il disco, io procederei con un bel test
*distruttivo* di badblocks, da live dopo aver smontato tutto. Qualcosa
come:
# badblocks -b512 -c128 -wst /dev/quelcheè
Occhio che credo sia 'na cosa lunga. Vedi tu il man pei dettagli.
Se va a buon fine, mi metterei l'animo in pace. :)
--
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________ _________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/ http://www.worldcommunitygrid.org/index.jsp
http://boinc.berkeley.edu/projects.php
|
|
| |
| Re: Backup non riuscito con dd [messaggio #34727 è una risposta a message #34726] |
gio, 06 gennaio 2011 01:30 |
JohnnyNewbie
Messaggi: 24
Registrato: novembre 2010 |
Junior Member |
|
|
Lem Novantotto <Lem98@hotmail.com> wrote:
> Lem Novantotto ha scritto:
>
>> # badblocks -b512 -c128 -wst /dev/quelcheè
>
> Errata corrige:
>
> # badblocks -b512 -c128 -wsv /dev/quelcheè
Ok proverò però prima ho lanciato nuovamente la copia
della partizione hdc2 che dava l'errore dovuto ai
settori corrotti.
Sempre con dd ho lanciato:
dd if=/dev/hdc2 of=/mnt/sdb2/system-backup/winxp-hdc2-fixed bs=512
Per ora non ha dato il solito errore ad 1.6GB di dati
copiati come dava prima (la copia è in corso...):
$ ls -lh winxp-hdc2-fixed
-rw-r--r-- 1 root root 20G 2011-01-06 01:02 winxp-hdc2-fixed
Ha quasi completato in effetti...
Sembra proprio che hdrecover abbia funzionato. O
comunque ha modificato la situazione e dd sta volta non
si lamenta.
Ah ecco, nel frattempo, copia finita:
_____________________
44724960+0 records in
44724960+0 records out
22899179520 bytes (23 GB) copied, 1389,78 s, 16,5 MB/s
-------------------------------------------------------
Nessun errore: dd non s'è bloccato come faceva prima.
Prima di usare badblocks voglio provare a riavviare xp
che sta sulla hdc2 rivista con hdrecover e smartctl.
Ancora prima però faccio l'md5sum di
1) /dev/hdc2
2) winxp-hdc2
3) winxp-hdc2-fixed
La prima è l'originale dopo laggiustamento con
hdrecover.
La seconda è la copia dell'originale prima del fix.
La terza è la copia dell'originale dopo il fix.
Già un confronto dei tre sum dovrebbe dire qualcosa.
Ho spulciato un po' in rete.
A questo link parlano di smartmontools e, anche se
superficialmente di badblocks.
http://tinyurl.com/4tm3yu
Va bè poi per il resto c'è google...
Grazie dei consigli. farò senz'altro sapere se xp si
riavvia normalmente... voglio fare in modo che faccia
uno scandisk all'avvio, non ricordo bene come si fà,
googlerò.
Grazie ancora a presto!
|
|
| |
| Re: Backup non riuscito con dd [messaggio #34798 è una risposta a message #34795] |
dom, 09 gennaio 2011 20:20 |
Lem Novantotto
Messaggi: 166
Registrato: novembre 2010 |
Senior Member |
|
|
JohnnyNewbie ha scritto:
>Pass completed, 0 bad blocks found.
Meglio di così, con badblocks, non poteva andare. :)
Io considererei il disco ragionevolmente affidabile. Non affidabile al
punto di stivarci sopra dei backup, ma insomma...
> Alla fine ho pensato di testarla con badblocks: un test distruttivo come
> ho fatto per l'hd e l'esito e' stato il seguente:
> ________________________________________ Pass completed, 897033 bad
> blocks found. ----------------------------------------
Ecco, qui emerge un possibile problemino relativo all'uso di badblocks su
SSD, chiavette flash e simili, sul quale mi sono già interrogato in
passato. Mi cito:
| usandolo in modalità read-write, distruttiva o meno, deve cancellare
| e riscrivere ogni blocco. Ma sappiamo che il processo di cancellazione,
| sugli SSD, è una cosa tutta particolare: non si cancella veramente, si
| scrive altrove fino a necessità o fino al trim, e l'unità minima di
| cancellazione è un multiplo del settore (che invece è l'unità minima di
| scrittura)... Il che mi pare creare qualche problema a badblocks
Insomma, a parte il fatto che provoca numerose scritture e riscritture,
che non sono proprio un toccasana per quel tipo di celle, io sono molto
dubbioso circa il fatto che badblocks possa dare risultati sensati su
quel tipo di device (SSD, chiavette usb...). Ma non ho alcuna esperienza
in merito: il mio è un solo un dubbio.
--
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________ _________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/ http://www.worldcommunitygrid.org/index.jsp
http://boinc.berkeley.edu/projects.php
|
|
|
| Re: Backup non riuscito con dd [messaggio #34800 è una risposta a message #34798] |
dom, 09 gennaio 2011 23:10 |
JohnnyNewbie
Messaggi: 24
Registrato: novembre 2010 |
Junior Member |
|
|
Lem Novantotto <Lem98@hotmail.com> wrote:
> JohnnyNewbie ha scritto:
>
>>Pass completed, 0 bad blocks found.
>
> Meglio di così, con badblocks, non poteva andare. :)
> Io considererei il disco ragionevolmente affidabile. Non affidabile al
> punto di stivarci sopra dei backup, ma insomma...
Bene, allora posso procedere alla riorganizzazione
del disco e installazione dei sistemi operativi
win e linux in dual boot.
>> Alla fine ho pensato di testarla con badblocks: un test distruttivo come
>> ho fatto per l'hd e l'esito e' stato il seguente:
>> ________________________________________ Pass completed, 897033 bad
>> blocks found. ----------------------------------------
>
> Insomma, a parte il fatto che provoca numerose scritture e riscritture,
> che non sono proprio un toccasana per quel tipo di celle, io sono molto
> dubbioso circa il fatto che badblocks possa dare risultati sensati su
> quel tipo di device (SSD, chiavette usb...). Ma non ho alcuna esperienza
> in merito: il mio è un solo un dubbio.
Capisco...
Devo anche aggiungere che quella chiavetta fa parte di una serie di
chiavette ordinate in "stock" insieme ad altri amici. E ho saputo
che anche altri avevano avuto problemi con quegli aggeggi, probabilmente
badblocks non sbaglia cosìtanto pur restando valido il tuo discorso.
Ho usato quella chiavetta perchè ho avuto qualche problema con
un'ulteriore chiavetta su cui avevo messo slax (www.slax.org).
Volevo escludere il mal funzionamento dovuto a quest'altra chiavetta,
bè non sono stato fortunato.
Anzi oer scrupolo ho fatt girare badblocks anche sulla prima chiavetta,
quella che uso da tempo e che alloggia slax. Bene per questa dice come
per l'hd: "0 bad blocks found".
Quindi i problemi che ho riscontrato con slax non sono dovuti probabilmente
alla chiavetta, ma ad altro..indaghero', comunque questa è un'altra storia.
In ogni caso grazie del supporto, ho imparato qualcosa che non sapevo
da questa discussione.
Un saluto e grazie ancora! :)
|
|
| | |
Vai al forum:
Ora corrente: dom mag 26 20:13:17 CEST 2024
Tempo totale richiesto per generare la pagina: 0.00993 secondi
|
My forum, my way! Il forum dei newsgroup
Utenti
F.A.Q.
Registrati
Login
Home
E-mail ad un amico 
