Forum Linux.général Récupération disque dur externe

Posté par . Licence CC by-sa.
Tags :
3
25
mai
2019

Bonjour,

Je voulais faire une clé bootable en utilisation dd, comme d'habitude.
Malheureusement j'ai pas sélectionné ma clé mais mon disque dur externe de sauvegarde !

Quelle est la solution la plus simple pour récupérer mes fichiers s'il vous plait ?
Si vous avez un outil graphique, c'est bien, sinon, tout est bon a prendre :)

Je vous remercie d'avance.

(Je suis sur Fedora)

  • # houps

    Posté par (page perso) . Évalué à 5 (+3/-0).

    clairement tu ne pourra pas récupérer toutes tes données
    A ton niveau, les outils de base sont testdisk et photorec
    Après si tu as de gros moyens, fait appel à un labo, mais c'est un budget …

    • [^] # Re: houps

      Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 25/05/19 à 15:37.

      Tu ne pourras espérer récupérer que les zones disques sur lesquels tu n'auras pas écrit, donc avec une image écrite avec un dd, il ne reste pas grand chose; en dehors de la solution de laboratoire très coûteuse citée ci-dessus.

      • [^] # Re: houps

        Posté par . Évalué à 6 (+3/-0).

        Du coup ça va dépendre de la taille de l’image qu’il a posé dessus… Si elle est pas trop grosse et qu’il a écrit à partir du début du disque, en utilisant photorec il devrait pouvoir retrouver pas mal de choses. Si par exemple l’image fait quelques GB et que le disque est beaucoup plus gros ça se tente carrément.

  • # Photorec

    Posté par (page perso) . Évalué à 3 (+2/-0).

    Tu n'as du écraser que le début de ton disque en faisant ton dd, donc tout le reste doit être récupérable "en vrac" :
    - utilise photorec pour tout récupérer en vrac
    - trie tes fichiers par type et classe les photos par date en utilisant ce petit script python : https://github.com/tfrdidi/sort-PhotorecRecoveredFiles
    - supprime les fichiers dont le type n'a pas été trouvé, à priori il ne te sont pas utiles
    - met de côté les types de fichier dont tu penses qu'ils ne servent à rien
    - supprime les doublons (un même fichier peut ressortir plusieurs fois) : rdfind -outputname doublons-recup -deleteduplicates true /fichiers/récupérés
    - renomme les morceaux en MP3 en utilisant leurs métadonnées : for dir in ./MP3/*; do for file in "$dir"/*; do mp3rename "$file"; done; done (note que ça doit pouvoir s'adapter à d'autres formats)

    C'est loin d'être idéal mais c'est déjà ça… L'avantage de ta situation :
    - c'est que tu feras attention avant de faire un dd (si tu es sous Gnome, tu peux utiliser le logiciel
    "Disque" pour faire tes clés, ça réduit les chances de se rater)
    - c'est que ça te donnera envie de faire de meilleures sauvegardes :-)

    Bon courage !

    • [^] # Re: Photorec

      Posté par . Évalué à 1 (+0/-0).

      Merci !

      Par contre j'ai un petit problème : le script que tu as donné ne marche pas chez moi.

      [jared@localhost ~]$ pip install exifread
      DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
      Requirement already satisfied: exifread in /usr/lib64/python2.7/site-packages (2.1.2)
      [jared@localhost ~]$ 
      

      Résultat :

      [jared@localhost ~]$ python recovery.py /home/jared/Vidéos/ /home/jared/Documents/
      python: can't open file 'recovery.py': [Errno 2] No such file or directory
      [jared@localhost ~]$ 
      

      J'ai raté quelque chose ?

      • [^] # Re: Photorec

        Posté par . Évalué à 3 (+0/-0).

        Pour la première commande à priori elle s’est déroulée correctement et tu as maintenant la bibliothèque Python "exifread" installée. Tu peux, pour vérifier, avec le même utilisateur que tu as lancé la commande, faire un pip freeze, ça va lister tous les modules installés, tu devrais voir exifread (tu peux utiliser grep pour filtrer…). C’est juste un message d’avertissement pour te dire que Python 2.7, il faudra absolument te démerder pour ne plus avoir à l’utiliser d’ici au 1er janvier 2020. Ça va arriver vite mais pour l’instant, tu t’en fous.

        Pour la deuxième, es-tu bien positionné dans le dossier où le fichier recovery.py existe ? À priori non (No such file or directory = Pas de tel fichier ou répertoire). Là tu es positionné dans ton $HOME (indiqué par ~ ici, et qui doit correspondre à priori à /home/jared), tu es sûr que le script est bien ici ? Peut-être dans un sous dossier "Téléchargement" plutôt ?

  • # Un grand classique !

    Posté par . Évalué à 4 (+1/-0). Dernière modification le 25/05/19 à 21:48.

    Bon courage avec photorec !

    YvanM t’as donné les bons tuyaux pour exploiter ce que tu vas retrouver : photorec retrouve les fichiers, mais pas leur nom, ça c’est perdu à jamais… Il peut deviner le type des fichiers d’après leur structure mais c’est tout. Ensuite il faudra faire comme il t’as dit pour la plupart des fichiers, et pour certains fichiers tu devras les ouvrir, voir ce qu’il y a dedans pour leur redonner un nom.

    Typiquement, pour les fichiers bureautiques (les fichiers LibreOffice par exmple) je ne sais pas s’il existe une technique similaire à celle donné plus haut pour les MP3…

    Pas d’outil graphique mais comme tu le peux voir ici, la commande photorec n’admet pas beaucoup d’options. Ça devrait pas être plus compliqué que :

    photorec /d <dossier où placer les fichiers récupérés> </dev/sd? qui correspond à ton disque>

    Par contre tu peux t’attendre à ce que ce soit assez long comme processus. Plusieurs heures ce serait pas étonnant.

  • # extundelete

    Posté par (page perso) . Évalué à 2 (+2/-1). Dernière modification le 25/05/19 à 22:19.

    J'ai déjà utilisé extundelete avec succès : l'avantage c'est qu'il récupère les noms de fichiers (mais pas les dates/heures, liens et attributs étendus). Il faut que la partition soit en ext3 ou ext4.

    Il ne semble plus maintenu depuis 2013, mais le paquet est disponible dans les distributions à base de Debian. Et pour Fedora : https://apps.fedoraproject.org/packages/extundelete

    Voir ci-dessous :
    http://extundelete.sourceforge.net/
    https://doc.ubuntu-fr.org/extundelete

  • # Ce que je ferais

    Posté par . Évalué à 7 (+5/-0). Dernière modification le 25/05/19 à 22:23.

    Je commencerais par faire une copie brute du disque externe sur un autre disque au moins aussi gros (sans se tromper de destination cette fois, hein !).
    Comme ça, si la méthode qu’on essaie n’est pas la bonne, on peut toujours recommencer avec une autre à partir d’une autre copie non altérée.

    Ensuite, sur cette copie, je copierais des zéros sur la place prise par l’image copiée involontairement. Ça éviterait de perdre du temps sur ce qu’elle contient avec les outils de récupération.
    Une commande de ce style devrait faire l’affaire :

    dd if=/dev/zero of=/dev/disque_sur_lequel_est_la_copie bs=1024 count=taille_de_l_image_en_Kio

    Ensuite, j’essaierais de rétablir les partitions avec testdisk. S’il y en avait plusieurs, il devrait au moins retrouver intactes celles qui n’ont pas été touchées. Il n’y aurait plus qu’à les monter et récupérer les données. Ou encore rétablir la même table de partitions sur le disque d’origine :

    sfdisk -d /dev/disque_avec_la_copie > /tmp/sfdisk.txt
    sfdisk /dev/disque_d_origine < /tmp/sfdisk.txt

    (il me semble que la version actuelle de sfdisk supporte les partitions GPT ; sinon, il faut trouver comment faire l’équivalent avec sgdisk si la table de partitions est en GPT).

    S’il n’y en avait qu’une seule et que testdisk échouait, j’essaierais de refaire avec fdisk la partition par défaut, en espérant que l’ancienne commençait bien au même endroit.

    Là, je tenterais sur la première partition le fsck du système de fichiers qui était dessus (fsck.ext4, fsck.xfs…).
    Si par chance il fonctionnait (même si c’est loin d’être gagné, ce n’est pas complètement à exclure : ext2 et ses descendants notamment créent des superblocs de secours au formatage), il arriverait sûrement mieux à rétablir les fichiers et surtout leurs noms et la structure que photorec.

    Et en dernier recours, photorec.

    Bonne chance.

    Moralité : sur un gros disque externe, il faudrait peut-être laisser une partition bidon de 8 Go au début (et puis sauvegarder la table des partitions avec sfdisk -d sur un autre disque), au cas où on copierait par erreur une distribution live dessus…

    ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

    • [^] # Re: Ce que je ferais

      Posté par . Évalué à 4 (+1/-0). Dernière modification le 26/05/19 à 23:32.

      Comme ça, si la méthode qu’on essaie n’est pas la bonne, on peut toujours recommencer avec une autre à partir d’une autre copie non altérée.

      Toutes les méthodes à essayer sont censés seulement lire le disque et jamais écrire dessus, à part le dd malencontreux qui nous occupe il est pas censé subir une seule autre altération… Faire une image du disque peut permettre de réutiliser le disque, en gardant les données à récupérer dans un fichier. On a aussi intérêt à faire ça quand le disque a montré des signes de faiblesse mais là dans son cas cette étape ne me paraît pas indispensable… Il faut faire une image raw, faut avoir le temps et l’espace, or il a d’abord besoin d’espace pour la récupération.

      Ça reste un bon conseil dans l’absolu, ça permet de réutiliser le disque, pour remettre en place une sauvegarde fonctionnelle des fichiers actuels… faut juste pouvoir garder un fichier DD_flingué_par_dd.img de plusieurs centaines de GB quelque part ailleurs…

      • [^] # Re: Ce que je ferais

        Posté par . Évalué à 3 (+1/-0).

        Toutes les méthodes à essayer sont censés seulement lire le disque et jamais écrire dessus

        Pas celle que je propose, puisque je préconise d’abord de réécraser la zone écrasée par l’image disque par des zéros (une occasion de reperdre des données si on se trompe sur la taille — accessoirement, je n’ai pas testé mon indication) pour éviter ensuite que les utilitaires ne perdent du temps avec son contenu, et qu’ensuite si tu valides les partitions que trouve testdisk, il réécrit la table des partitions (OK, avec peu de partitions, on peut supposer qu’elle n’occupe que le début du disque).

        Il faut faire une image raw, faut avoir le temps et l’espace

        En effet.
        Cela dit, un nouveau disque acheté à l’occasion pourra servir ensuite à faire des sauvegardes ensuite…

        ¯ : macron (typographie), petit signe diacritique, qui prétend ne pencher ni à gauche ni à droite, mais se place nettement au dessus des vraies lettres, qu’il considère avec mépris.

Envoyer un commentaire

Suivre le flux des commentaires

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