Bonjour,
j'essaye de récupérer avec ddrescue les données d'un disque sata (formaté NTFS) de 600 Go plein comme un œuf. Ce disque a des problèmes puisque son propriétaire n'arrive plus à le lire avec windows 7 ni avec ubuntu et qu'il (le disque, pas son propriétaire) fait ponctuellement des bruits mécaniques déplaisants.
Je précise que c'est la première fois que je tente cette manip', j'ai bien lu ici ou là que la récupération pouvait être longue mais qu'elle se fait en deux étapes secteurs sains d'abord les autres ensuite. Et si j'ai bien compris, la deuxième étape peut être beaucoup plus longue que la première.
J'ai fait (avec un systemrecuecd sur clé usb) :
ddrescue -B -n -v /dev/sdc1 /mnt/sauvegarde/recup.iso rescue.log (point de montage sur un DD externe USB assez grand)
et je projette de continuer avec
ddrescue -B -n -v /dev/sdc1 /mnt/sauvegarde/recup.iso rescue.log
sauf que déjà la première partie et loooongue : à la louche - à ce rythme - il y en a pour plus de 20 jours :-(
La sortie à l'écran :
rescued 2814 MiB err size 7858 KiB current rate 13107 B/s
ipos 2820 MiB errors 20 average rate 290 KiB
opos 2820 MiB time sice last successfull read 0s
Une idée de ce qui se passe ?
Merci
# d'autres options peuvent etre utiles
Posté par NeoX . Évalué à 3.
quand je lis : http://doc.ubuntu-fr.org/ddrescue
ca parle de l'option -T
qui permet de reprendre une copie si le disque disparait
en cas de deconnexion il suffirait alors de reprendre avec la meme ligne.
et puis dd n'est pas reputé comme super rapide,
d'autant plus que tu envoie vers un disque dur USB externe.
tu es donc limité par le plus lent des elements.
j'imagine que la machine qui fait cette copie est une machine fiable, que tu maitrises parfaitement,
et pas la machine de l'utilisateur dont on n'est sur de rien ?
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . Évalué à 1. Dernière modification le 14 janvier 2013 à 19:33.
Euh, dd c'est très rapide, pourvu qu'on ne choisisse pas les longueurs de blocs et les offsets n'importe comment !
Un disque USB2, ça encaisse au moins 30Mo/s
[^] # Re: d'autres options peuvent etre utiles
Posté par NeoX . Évalué à 2.
tu as deja reussi à faire du 30Mo/s pendant de longue periode, sur des gros transferts ?
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . Évalué à 0.
Wii, sur des sauvegardes d'iso debian, bien sûr.
Avec des dd avec un bs important sur le macbook avec le quel je tapote ces lignes j'obtiens:
Hair:~ otta $ time dd if=/dev/zero of=/Volumes/Data/toto.bin bs=512k count=12001200+0 records in
1200+0 records out
629145600 bytes transferred in 23.536381 secs (26730771 bytes/sec)
real 0m23.845s
user 0m0.004s
sys 0m0.671s
Et le VFS de macos est comment, dire … voilà.
[^] # Re: d'autres options peuvent etre utiles
Posté par NeoX . Évalué à 1. Dernière modification le 14 janvier 2013 à 21:33.
ca ne fait que 26Mo/s pendant 23 secondes
je n'appelle pas ca un test dans le temps
en plus tu n'envoie que des /dev/zero
essaie avec du /dev/random
ou /dev/cdrom
ici sur mon macbook air de janvier 2012 en USB2
vers une cle USB
ca ne fait guere que 7Mo/s
vers une autre clé :
soit 16Mo/s
apres je suis d'accord que les quelques Ko/s qu'il obtient…
mais il ne faut pas oublier qu'il lui faut lire le disque dur defecteux
[^] # Re: d'autres options peuvent etre utiles
Posté par Berekine . Évalué à 1.
J'ignore pourquoi tu n'obtiens pas 30 Mo/s car de mon côté je n'ai jamais rien fait de spécial. Du coup tu m'as mis un doute. Je teste avec un disque-dur récupéré dans un portable, branché avec un truc comme ça :
Au final je plafonne à 30 Mo/s depuis des années, avec des bécanes diverses et des disques-durs SATA, ou des PATA pas trop vieux.
[^] # Re: d'autres options peuvent etre utiles
Posté par Appoplase . Évalué à 3.
Neox parle de clefs USB.
Elles ont généralement un débit entre 2 et 8 Mo/s en écriture.
Les modèles « haut de gamme » font aux alentours de 30 Mo/s. Je suppose qu'elles sont limitées par l'USB plutôt que par leur vitesse interne.
J'ai une Corsair GTR il me semble et elle fait 25 Mo/s.
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . Évalué à 3.
Après avoir parlé de disques dur dans son premier post.
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . Évalué à 1.
Je multiplie les chiffres par dix :
Très comparable.
Bref, mauvaise foi spotted :
1 - Tu parles de disque dur, je fais un test sur un disque dur. La, tu testes avec deux clefs USB. Ah wai, les clefs sont lentes.
2 - Tu me parles de disques trop lents, et tu demandes de tester avec autre chose que /dev/zero. Tu cherches à vérifier quoi ? Que ton disque est lent ou que la vitesse de génération de l'aléas est faible ? Tu penses qu'un disque est plus lent à écrire des zéros que de l'aléas ?
Faut savoir ce que tu veux benchmarker.
Oui, certes. Mais c'est pas moi qui ait dit que le disque USB était le maillon faible et que dd c'était tout lent.
[^] # Re: d'autres options peuvent etre utiles
Posté par oinkoink_daotter . Évalué à 1. Dernière modification le 14 janvier 2013 à 22:19.
Cela dit j'ai refait les tests avec /dev/urandom et /dev/random
Pas de lecteur CD sous la main, macbouc air, toussa.
On constate qu'effectivement c'est plus long et qu'un core du CPU est au taquet. Cela dit 10 Mo d'aléas "cryptographique" par seconde (/dev/random vs /dev/urandom) , c'est très (trop?) rapide. Je me demande si le bazard n'a pas un générateur de bruit matériel (avec un linux et sans générateur on serait tombé très rapidement à quelques octets par seconde voire moins sur /dev/random) ou si le générateur est tout pourri.
Fin du hors sujet.
# oui, c'est lent
Posté par steph1978 . Évalué à 5.
Comme le principe est de buter sur les erreurs de lectures, puis d'essayer de les circoncire au maximum (sauf avec "-n"), oui c'est lent.
Il faut du temps pour que le disque admette l'erreur de lecture, plusieurs secondes à chaque fois.
note: j'imagine qu'il y a un méchant copié collé dans la deuxième commande, tu voulais surement enlever le "-n" dans un deuxième temps.
La deuxième étape ne sera pas nécessairement plus longue car elle se concentrera sur le bloc de 64ko qui ont été marqué en erreur.
Bref, ça dépendra des séquelles qu'a le DD.
[^] # Re: oui, c'est lent
Posté par Yves Bourguignon . Évalué à 3.
Moi je suis plutôt inquiet pour son disque. Un débit aussi lent avec l'option
-n(qui évite d'insister sur les erreurs), ça ne restituera sans doute pas grand chose…J’essaierai ddrescue sur tout le disque sdc au lieu de la partition sdc1 (plus simple à restituer si ça abouti et il n'y a sans doute qu'une seule partition) et sans l'option
-v(moins de détails mais moins de temps perdu) :ddrescue -B -n /dev/sdc /mnt/sauvegarde/recup.iso rescue.logIl y a d'autres paramètres sur lesquels jouer pour optimiser le débit, par exemple
-c 32pour lire un bloc de secteurs plus petit que la valeur par défaut (64), ce qui est conseillé pour les disques lents.Mais si les données ont une valeur importante (je sais, c'est con comme question, c'est toujours important : soit affectif, soit commercial), voici l'adresse d'un spécialiste de la récupération qui travaille à prix libre : diskcard.fr
[^] # Re: oui, c'est lent
Posté par Professeur Méphisto . Évalué à 1.
le collègue qui a ce problème de disque pense avoir la quasi-totalité des données en sauvegarde, mais comme il reste un doute on a tenté la restauration quand même. De plus c'est un truc que je voulais tester depuis un moment sans en avoir d'occasion.
Merci néanmoins pour l'adresse, juste à côté de chez moi, en plus !
[^] # Re: oui, c'est lent
Posté par Professeur Méphisto . Évalué à 1.
suite de la manip : la première passe à finalement été plus rapide que prévue : moins de 4 heures au lieu des 20 jours calculés ;-)
Bilan : 590 GiO d'erreurs sur un disque de 600 !!
J'ai lancé la deuxième passe qui s'est arrêtée brutalement après 10 min (message du type fichier inaccessible ou un truc comme ça - désolé pas noté) puis relancée en retournant le disque.
Je l'ai laissé tourner une petite heure (3 GiO récupérées supplémentaires) avant de rentrer. La suite demain ou plus tard…
[^] # Re: oui, c'est lent
Posté par Professeur Méphisto . Évalué à 1.
ce matin, 100 GiO apparemment récupérés…
[^] # Re: oui, c'est lent
Posté par steph1978 . Évalué à 4.
Vu la tête qu'il va avoir en fin de récupération, il est peu probable que tu arrive à monter le filesystem. Dans ce cas, tu peux utiliser TestDisk ou PhotoRec pour essayer de récupérer des fichiers.
Bonne chance.
[^] # Re: oui, c'est lent
Posté par Professeur Méphisto . Évalué à 1.
effectivement, le FS fait sa mauvaise tête :-(
la suite ici
[^] # Re: oui, c'est lent
Posté par netsurfeur . Évalué à 4.
Ah ! Ces pratiques religieuses…
A vif ou sous anesthésie ?
[^] # Re: oui, c'est lent
Posté par Professeur Méphisto . Évalué à 3.
et si en plus c'est réalisé lentement … :-/
[^] # Re: oui, c'est lent
Posté par palm123 (site web personnel) . Évalué à 2.
Aie !!!
ウィズコロナ
[^] # Re: oui, c'est lent
Posté par steph1978 . Évalué à 2.
'tain, j'ai cherché une plombe où était le problème.
note pour plus tard: on dit "circonscrire".
[^] # Re: oui, c'est lent
Posté par BAud (site web personnel) . Évalué à 2.
Dans Ta Circoncision du terme adéquat, c'est pourtant clair (mais, peut-être pas dans ta circonscription).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.