Re: [LA-discussions] big pb d'accès disque dur

[ Thread Index | Date Index | More linuxarverne.org/discussions Archives ]


Le samedi 6 juillet 2013 22:03:27 Romain Tartière a écrit :
> Ça doit tourner autour de 2h et quelques pour un disque de 2To à 80Mo/s,
> vois ce que ça te dis quand c'est fini.

ça continue à tourner, nettement moins vite que ce que tu annonces :

rescued:    1490 GiB,  errsize:  3214 KiB,  current rate:  31936 KiB/s
   ipos:    1490 GiB,   errors:      73,    average rate:  37441 KiB/s
   opos:    1490 GiB,     time since last successful read:       0 s

ce qui m'étonne c'est que pour moi il n'y a pas autant de données, mais si ça 
se trouve il a quasiment fini. Ha non en fait il récupère aussi les partitions 
inutilisées qui étaient avant celle où sont mes données ?

en tout cas ça fait un bon moment que je n'ai pas décollé de 73 erreurs, puis-
je en déduire que j'aurai au pire 73 fichiers corrompus ?

D'autre part sur 
http://www.cgsecurity.org/wiki/Disque_Dur_Endommagé;
il est écrit :

#récupérer en priorité le plus de zones mémoires saines:
ddrescue -B -n /dev/old_disk /dev/new_disk rescued.log

ce qui est en train de se faire, et ensuite :

#puis essayez de récupérer le plus de zones mémoires endommagées possible:
ddrescue -B -r 1 /dev/old_disk /dev/new_disk rescued.log

je relance une deuxième passe avec la mm syntaxe sauf les options ?

première passe :
sudo ddrescue -B -n /dev/sdc /mnt/rescue/sdc.bin rescued.log

deuxième passe :
sudo ddrescue -B -r 1 /dev/sdc /mnt/rescue/sdc.bin rescued.log

c'est correct ??? si j'ai bien compris la doc ça remplira les trous restant, 
au cas où c'est possible ?

ensuite je présume que c'est testdisk qui prend le relais, j'ai trouvé
http://www.cgsecurity.org/wiki/TestDisk_Etape_par_Etape#Sympt.C3.B4mes
qui me semble bien expliquer la procédure, je fais comme indiqué ?

--
Liste de discussions de LinuxArverne
http://wiki.linuxarverne.org/listes_de_diffusion


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/