Forum Linux.général vitesse de récupération avec ddrescue

Posté par  . Licence CC By‑SA.
Étiquettes :
0
14
jan.
2013

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  . É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  . Évalué à 1. Dernière modification le 14 janvier 2013 à 19:33.

      et puis dd n'est pas reputé comme super rapide,

      Euh, dd c'est très rapide, pourvu qu'on ne choisisse pas les longueurs de blocs et les offsets n'importe comment !

      d'autant plus que tu envoie vers un disque dur USB externe.

      Un disque USB2, ça encaisse au moins 30Mo/s

      • [^] # Re: d'autres options peuvent etre utiles

        Posté par  . Évalué à 2.

        Un disque USB2, ça encaisse au moins 30Mo/s

        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  . É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=1200
          1200+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  . É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

            time dd if=/dev/zero of=toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 87.199086 secs (7215048 bytes/sec)

real    1m28.350s
user    0m0.004s
sys 0m0.621s

            ca ne fait guere que 7Mo/s

            vers une autre clé :

            time dd if=/dev/zero of=/Volumes/Untitled/toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 38.935837 secs (16158523 bytes/sec)

real    0m39.267s
user    0m0.004s
sys 0m0.597s

            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  . É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 :

                  $ dd if=/dev/sda of=/dev/sdd bs=1M count=10000
    1066+0 enregistrements lus
    1065+0 enregistrements écrits
    1116733440 octets (1,1 GB) copiés, 29,8756 s, 37,4 MB/s
    1966+0 enregistrements lus
    1965+0 enregistrements écrits
    2060451840 octets (2,1 GB) copiés, 59,9819 s, 34,4 MB/s
    2867+0 enregistrements lus
    2866+0 enregistrements écrits
    3005218816 octets (3,0 GB) copiés, 90,0937 s, 33,4 MB/s
    3758+0 enregistrements lus
    3757+0 enregistrements écrits
    3939500032 octets (3,9 GB) copiés, 120,17 s, 32,8 MB/s
    4658+0 enregistrements lus
    4657+0 enregistrements écrits
    4883218432 octets (4,9 GB) copiés, 150,282 s, 32,5 MB/s
    5559+0 enregistrements lus
    5559+0 enregistrements écrits
    5829033984 octets (5,8 GB) copiés, 180,37 s, 32,3 MB/s
    6462+0 enregistrements lus
    6461+0 enregistrements écrits
    6774849536 octets (6,8 GB) copiés, 210,483 s, 32,2 MB/s
    7365+0 enregistrements lus
    7364+0 enregistrements écrits
    7721713664 octets (7,7 GB) copiés, 240,665 s, 32,1 MB/s
    8265+0 enregistrements lus
    8264+0 enregistrements écrits
    8665432064 octets (8,7 GB) copiés, 270,742 s, 32,0 MB/s
    9168+0 enregistrements lus
    9167+0 enregistrements écrits
    9612296192 octets (9,6 GB) copiés, 300,826 s, 32,0 MB/s
    10000+0 enregistrements lus
    10000+0 enregistrements écrits
    10485760000 octets (10 GB) copiés, 328,614 s, 31,9 MB/s

              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  . É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  . Évalué à 1.

              ca ne fait que 26Mo/s pendant 23 secondes
              je n'appelle pas ca un test dans le temps

              Je multiplie les chiffres par dix :

              dd if=/dev/zero of=/Volumes/Data/toto.bin bs=512k count=12000
12000+0 records in
12000+0 records out
6291456000 bytes transferred in 212.616966 secs (29590564 bytes/sec)

              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.

              mais il ne faut pas oublier qu'il lui faut lire le disque dur defecteux

              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  . Évalué à 1. Dernière modification le 14 janvier 2013 à 22:19.

                Cela dit j'ai refait les tests avec /dev/urandom et /dev/random

                Hair:~ otta $ time dd if=/dev/urandom of=/Volumes/Data/toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 60.276656 secs (10437633 bytes/sec)

real    1m0.973s
user    0m0.004s
sys 0m59.471s
Hair:~ otta$ time dd if=/dev/random of=/Volumes/Data/toto.bin bs=512k count=1200
1200+0 records in
1200+0 records out
629145600 bytes transferred in 53.121547 secs (11843511 bytes/sec)

real    0m53.393s
user    0m0.003s
sys 0m52.576s

Hair:~ otta $ ls -l /dev/*rand*
crw-rw-rw-  1 root  wheel   13,   0 14 jan 22:00 /dev/random
crw-rw-rw-  1 root  wheel   13,   1 18 oct 16:25 /dev/urandom

                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  . É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  . É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.log
      Il y a d'autres paramètres sur lesquels jouer pour optimiser le débit, par exemple -c 32 pour 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  . Évalué à 1.

        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

        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  . É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  . Évalué à 4.

      d'essayer de les circoncire au maximum

      Ah ! Ces pratiques religieuses…
      A vif ou sous anesthésie ?

    • [^] # Re: oui, c'est lent

      Posté par  (site web personnel) . Évalué à 2.

      puis d'essayer de les circoncire

      Aie !!!

      ウィズコロナ

      • [^] # Re: oui, c'est lent

        Posté par  . É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  (site web personnel) . Évalué à 2.

          'tain, j'ai cherché une plombe où était le problème.

          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.