Forum général.cherche-logiciel récup' de disque dur en NTFS : photorec ou testdisk ?

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
1
6
oct.
2017

Pour un disque de 2 Tio, initialement en RAID1, j'ai lancé une tentative de récupération de données avec :

  • testdisk : il m'a récupéré $RECYCLE_BIN et ~230 Gio dans ~5800 fichiers o_O en ~10h
  • photorec : il m'a récupéré 750 fichiers, 2 répertoires, 740 Mo et me propose après 3h de continuer encore pour 2153 heures (O'RLY, SRSLY /o\)

Le disque est censé contenir des répertoires de photos extraites d'un appareil en RAW puis transformées, leur nom a peu d'importance…

J'ai vu qu'il y a scrounge-ntfs sous Debian : quelqu'un l'aurait déjà utilisé ?
D'autres idées pour récupérer une partition NTFS foirée ? C'est sur une icybox qui s'est malencontreusement remplie, ayant sans doute entraîné la corruption des secteurs d'au moins un des disques…

J'essaie avec le disque 1 et alternativement le disque 2, mais si ça doit prendre plus d'une semaine, ça ne va pas le faire :-)
J'aurais cru qu'en extrayant les disques et en les branchant directement en sata2, ce serait plus facile voire directement lisible, mais ce n'est pas le cas :/

des idées ou des retours d'expérience ?

Tiens, la situation s'est améliorée :

Pass 1 - Reading sector 1260141052/4294967295, 106533 files found

Elapsed time 10h33m41s - Estimated time to completion 25h26m06

Si ça se trouve, il s'acharnait sur des secteurs défectueux… Bon, ça reste des durées à la journée tout de même o_O

  • # usage de testdisk

    Posté par  . Évalué à 3.

    • testdisk n'est pas un programme de récupération de données, mais de récupération de partitions.
    • habituellement, je fais une image sur un disque plus important, ou un second disque avec dd_recue
    • puis, pour le format NTFS je demande a Windows de réparer le disque sur le nouveau disque avec la copie des données, modulo les secteurs illisibles qui seront remplis de zeros.
    • ensuite tu peux faire une recopie des données et ajouter une passe photorec pour récupérer d'éventuels fichiers perdus.
    • via un mécanisme de signatures, il est possible de supprimer les éventuels doublons.

    • [^] # Re: usage de testdisk

      Posté par  . Évalué à 2.

      Pour dé-dupliquer : https://www.hardcoded.net/dupeguru/

      • [^] # Re: usage de testdisk

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

        merci pour les infos.
        Je n'ai visiblement pas trop compris comment utiliser testdisk ;-)

        bref, maintenant que photorec m'annonce des durées « raisonnables », je vais peut-être le laisser terminer.
        Pass 1 - Reading sector 2290746762/4294967295, 209782 files found
        Elapsed time 15h59m47s - Estimated time to completion 13h59m44

        J'ai fait les choix suivants :

        • disque initialement en RAID1 / USB3
        • extraction d'un des disques et branchement en SATA dans une tour
        • utilisation d'un disque de 4 To pour la destination, NTFS m'impose un découpage en 2 : limitation de partition à 2 To o_O donc j'ai 2 partitions : une de 2 To et une de 1,7 To (merci encore l'arnaque entre les To et les Tio…)
        • comme je vais peut-être atteindre les limites de stockage cible, j'aurai peut-être à copier un des gros répertoires sur la 2ème partition (j'ai repéré un répertoire qui fait de l'ordre de 35 Go, ça devrait me laisser la marge)

        Je suis assez étonné de la répartition des fichiers
        txt: 121928 recovered
        jpg: 57890 recovered
        tif: 28708 recovered
        zip: 890 recovered
        doc: 790 recovered
        pdf: 646 recovered
        sqlite: 249 recovered
        mov: 204 recovered
        png: 186 recovered
        tx?: 153 recovered
        others: 340 recovered

        pour un disque censé contenir des photos en RAW, ça fait beaucoup de .txt :D

        • [^] # Re: usage de testdisk

          Posté par  . Évalué à 2.

          Je suis assez étonné de la répartition des fichiers
          txt: 121928 recovered
          jpg: 57890 recovered
          tif: 28708 recovered
          zip: 890 recovered
          doc: 790 recovered
          pdf: 646 recovered
          sqlite: 249 recovered
          mov: 204 recovered
          png: 186 recovered
          tx?: 153 recovered
          others: 340 recovered

          pour un disque censé contenir des photos en RAW, ça fait beaucoup de .txt :D

          parce qu'il ne sait pas distinguer un fichier .raw d'un fichier .txt par son mime/type ?

          • [^] # Re: usage de testdisk

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

            txt: 121928 recovered
            tif: 28708 recovered

            Si tes raw sont des raw Canon (CR2), alors c’est un format proche du tiff, dont il partage le même nombre magique (49 49 2a 00), il y a des chances donc que tes 28000 tifs soient en réalité des raw.

            Pour les txt, ce sont généralement des bouts de fichiers, par exemple des métadonnées qu’il n’a pas réussi à relier au fichier d’origine, ou juste des suites de caractères ascii trouvées dans des binaires, genre il y a des chances que si dans une zone d’octets aléatoires il trouve une suite de caractère ascii conséquente avec des alinéa dedans, il te fasse un txt, mais ça peut juste une suite aléatoire d’octets sans aucun sens.

            Un peu comme ce que te sortirai la sortie de find . -exec strings {} \;, beaucoup de bruit…

            ce commentaire est sous licence cc by 4 et précédentes

            • [^] # Re: usage de testdisk

              Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 octobre 2017 à 11:59.

              Si tes raw sont des raw Canon (CR2)

              oui, c'est le cas, mais il y a bien des fichiers cr2 aussi en plus des tiff dans l'arborescence (la synthèse présentée n'est sans doute pas exhaustive sur les extensions trouvées…). Peut-être que certains .cr2 ont un magic number distinct, j'avoue ne pas avoir trop regardé dans le détail.

              Pour les txt, ce sont généralement des bouts de fichiers, par exemple des métadonnées

              oui, cela a l'air de correspondre :

              • parfois au format texte lisible, avec les détails du type d'appareil photo
              • parfois du garbage binaire effectivement

              Merci des infos, cela m'a conforté qu'il n'y avait pas trop de dégât finalement dans le lot de fichiers. Reste à la personne qui a récupéré son disque à trier tout le bordel maintenant et retrouver les bons noms de répertoires… c'est ballot tout de même que photorec n'inclue pas une reconnaissance des fichiers répertoires, ce qui aurait permis de restaurer certains noms correctement :/

              Les smartmontools n'ont pas trouvé de secteurs défectueux sur les disques, c'est seulement les partitions NTFS qui étaient parties en vrac, sans explication vraiment trouvée (on soupçonne l'alimentation qui serait défaillante…).

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 0. Dernière modification le 03 avril 2021 à 22:25.

        Ce commentaire a été supprimé par l’équipe de modération.

  • # quel est le problème ?

    Posté par  . Évalué à 2.

    est-ce une erreur de manip ou une panne matériel ?

    si c'est une erreur de manip, je pense que photorec ne trouvera rien car il cherche des signatures de fichier, secteur par secteur. Or, à ma connaissance, les fichiers images raw n'ont pas de particularisme.
    Il faut trouver un équivalent de "undelete".

    si c'était matériel, tu aurais dû retrouver les données sur l'autre disque. ddrescue permet de faire une image d'un disque puis de la compléter avec l'autre, je crois.

  • # A chaque logiciel son usage

    Posté par  . Évalué à 4.

    Si c'est une panne matérielle, utilise ddrescue pour récupérer le plus possible du disque avant qu'il tombe complètement. Puis, travaille sur la copie, pas sur le disque.

    Si c'est une partition cassée -> testdisk.

    Si c'est des fichiers effacés par mégarde -> photorec.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.