Re: [LA-discussions] big pb d'accès disque dur |
[ Thread Index | Date Index | More linuxarverne.org/discussions Archives ]
On Sun, Jul 07, 2013 at 08:02:20AM +0200, Daniel Cartron wrote: > 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 ? ddrescue(1) ne fait que récupérer une image du disque. Il le fait plus efficacement que dd(1) c'est tout. > 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 ? Ça tu ne le sais pas encore: ddrescue(1) à rencontré 73 erreurs en essayant de lire le disque, visiblement cela représente un peu plus de 3 Mo de données qui peuvent être dans: 1. de l'espace non utilisé (cas idéal); 2. des fichiers (mais rien ne dit que les données inaccessibles sont contigües dans un fichier dont les blocs le sont également); 3. dans les zones utilisées par le système de fichier pour lire où sont les fichiers et les zones non utilisées. Vue que tu as eu des problèmes pour utiliser ton disque, il y a des chances que tu ai un peu du 3 (et sans doute un peu du 1 et du 2). Une fois que ddrescue aura terminé, tu pourra tenter de monter le système de fichier (option "mount -o loop" avec un offset, voir des détails en fin de mon mail). Peut-être que le système réclamera un fsck(8) avant, mais dans ce cas, comme tu va modifier ton image disque, il vaudrait mieux travailler sur une copie ! > 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 ? Oui, d'après la doc: `-n' `--no-split' Skip the splitting pass. Avoids spending a lot of time trying to rescue the most difficult parts of the file. `-r N' `--max-retries=N' Exit after given number of retry passes. Defaults to 0. -1 means infinity. Every bad sector is tried only one time per pass. To retry bad sectors detected on a previous run, you must specify a non-zero number of retries. ddrescue(1) essayera du coup de voir s'il peut lire une partie des informations dans les blocs auxquels il n'a pas eu accès (par défaut il lit des blocs de 128k) > 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é ? Ce lien ne parle que de récupération de table de partition, je pense pas que ça soit ton problème. Si tu es tenté pour l'option "montage", quelques mots clés pour Google: "mount loop offset", et un exemple ici: http://madduck.net/blog/2006.10.20:loop-mounting-partitions-from-a-disk-image/ (selon comment ton disque AF est utilisé il faudra multiplier par 512 ou 4096). Il me semble que testdisk(1) est assez fourni donc il y a peut être une autre fonctionnalité plus adaptée à ton cas, à voir. Sinon, photorec(1) (même paquet que testdisk(1) il me semble), est pas trop mauvais en fonction du type de contenus de ton disque. Romain -- Romain Tartière <romain@xxxxxxxxxxxx> http://romain.blogreen.org/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
Attachment:
pgptbxLoiLY9S.pgp
Description: PGP signature
Mail converted by MHonArc 2.6.19+ | http://listengine.tuxfamily.org/ |