TestDisk & PhotoRec 6.10

Posté par (page perso) . Modéré par Bruno Michel.
Tags :
1
19
juil.
2008
Linux
La version 6.10 de TestDisk et PhotoRec, logiciels de récupération de données multi-plateformes sous licence GPL, vient de sortir avec de nouvelles fonctions concernant les partitions ext2/ext3/ext4: identification des partitions ext4, possibilité de copier des fichiers depuis une partition ext2/ext3/ext4 même effacée, récupération des fichiers effacés des partitions ext2. La version 6.10 de TestDisk et PhotoRec, logiciels de récupération de données multi-plateformes sous licence GPL, vient de sortir!

Le but de TestDisk est de permettre la récupération des partitions perdues (ext2/ext3/ext4, ReiserFS, XFS, JFS, Swap, LVM1/LVM2, FAT, NTFS...) et de réparer certains problèmes de corruption des systèmes de fichiers : utilisation de la sauvegarde du secteur de boot FAT32 ou NTFS, recherche des paramètres de systèmes de fichiers FAT ou NTFS pour réécrire le secteur de boot, réparation des tables FAT, recherche des sauvegardes des superblocks ext2/ext3.
PhotoRec récupère les fichiers perdus y compris si le système de fichiers (FAT, NTFS, ext2/ext3/ext4, HFS+...) est totalement corrompu ou a été reformaté. PhotoRec gère même certains cas de fragmentation de fichiers permettant de récupérer plus de données.
Écrit en C dans un code portable, TestDisk et PhotoRec fonctionnent aussi bien sous Linux que DOS, Windows, Mac OS X, Solaris et les différents BSD.

Il est désormais possible d'utiliser TestDisk 6.10 pour copier des fichiers depuis une partition ext2/ext3 (et ext4 si version assez récente de la librairie ext2) comme c'est déjà le cas pour FAT et NTFS même si la partition est effacée. Les fichiers effacés des partitions ext2 peuvent être aussi récupérés ainsi que les fichiers et répertoires effacés des partitions FAT.

Coté PhotoRec, il extrait la date des photos à partir des entêtes EXIF des fichiers JPEG récupérés, cela permet de trier ces fichiers plus facilement. Le menu FileOpt permet de spécifier le format des fichier à récupérer, cette sélection peut désormais être sauvegardé, ce qui est assez pratique si vous utilisez PhotoRec toujours sur une sélection de formats de fichiers spécifiques. Le cap des 200 formats de fichiers a été dépassé avec l'ajout de plus de 30 nouveaux formats.

Parmi les améliorations générales, le nom du constructeur et le modèle des disques sont remontés pour une identification plus facile des disques sous Linux et Windows. Cette information n'était disponible jusqu'à présent que pour la version Linux.
Sous Linux, les raids logiciels /dev/md? et les volumes /dev/mapper/* sont ajoutés à la liste des disques.
Le fichier de log enregistre plus d'informations sur le système d'exploitation de la machine utilisée pour la récupération de données ainsi que le compilateur utilisé et les différentes librairies utilisées.
  • # \o/

    Posté par . Évalué à 5.

    PhotoRec est mon Dieu et Christophe Grenier est son prophète.
    • [^] # Re: \o/

      Posté par . Évalué à 7.

      en tout cas bravo, je viens de lire certaines de ses publications, dispo sur la page de son CV ici : http://www.cgsecurity.org/wiki/CV_Christophe_GRENIER
      tres tres interessant, en particulier le format bug.

      Merci Christophe.
      • [^] # Re: file opt

        Posté par . Évalué à 2.

        "Le menu FileOpt permet de spécifier le format des fichier à récupérer, cette sélection peut désormais être sauvegardé, ce qui est assez pratique si vous utilisez PhotoRec toujours sur une sélection de formats de fichiers spécifiques."


        Effectivement, c est une option très pratique. Merci pour le gain de temps et ces deux très bons logiciels.
  • # Attention, ce n'est qu'un dispositif de secours !

    Posté par (page perso) . Évalué à 7.

    L'idéal, ce serait de ne jamais avoir besoin de ces deux très bons logiciels !
    Ils ne vous dispensent pas de faire des sauvegardes.

    Un petit rappel sur les sauvegardes ne peut pas faire de mal :
    - une sauvegarde est une interface avec soi et différée dans le temps.
    - elle ne doit pas être stockée au même endroit (vol, incendie,...)
    - elle dépend du le type du disque dur sauvegardé qui n'est plus fabriqué
    - il n'y a plus de lecteur pour lire ce type de support
    - on n'a jamais essayé de valider la sauvegarde. Elle ne sera donc pas utilisable.
    - il faut plusieurs sauvegardes au cas où l'une d'elles serait mauvaise.

    Et si vous ne pouvez pas vous en sortir, photorec sera votre dernier secours. Il y a aussi une méthode que l'on peut utiliser : "Récupération de données sur une partition avec des badblocks ou comment surmonter une défaillance du disque" : http://abul.org/Recuperation-de-donnees-sur-une.html
    • [^] # Re: Attention, ce n'est qu'un dispositif de secours !

      Posté par (page perso) . Évalué à 3.

      Merci pour ce lien fort instructif ! A la fois accessible et précis.
    • [^] # Re: Attention, ce n'est qu'un dispositif de secours !

      Posté par . Évalué à 4.

      - on n'a jamais essayé de valider la sauvegarde. Elle ne sera donc pas utilisable.

      je reagis a ce point. Valider une sauvegarde a un instant t, c'est bien pour verifier que le processus de sauvegarde fonctionne, mais pas que la sauvegarde sera utilisable a un instant t+1. C'est donc garantie 0.

      Voila pourquoi il faut non seulement sauvegarder, mais re-sauvegarder regulierement (la validation de la sauvegarde permet juste d'eviter de sauvegarder pour rien quelque chose qui est deja pourri a la base).

      Desole pour le manque d'accents, les touche alt ne semblent pas fonctionner sur cette distrib (d'ailleurs si quelqu'un sait pourquoi les touche alt et certains accents comme le circonflexe sont reconnues ou pas suivant les distribs sous xorg avec pourtant le meme keymap fr_CH) sur mon laptop, je suis preneur.
      • [^] # Re: Attention, ce n'est qu'un dispositif de secours !

        Posté par (page perso) . Évalué à 6.

        Pour ta touche alt, à mon avis c'est juste que ta config xkb est écrite sur un secteur défectueux de ton disque dur et que tu devrais backuper.
        • [^] # Re: Attention, ce n'est qu'un dispositif de secours !

          Posté par . Évalué à 3.

          très drôle.

          Non j'ai trouvé pourquoi finalement. C'est juste que la mode de spécifier une keymap est obsolète mais existe encore pour des raisons de compatiblité. Mais comme les gens de xorg ont l'air d'être des blagueurs, leur compatibilité est n'est pas complète. Bref c'est stupide, soit on dit qu'on le garde et on se débrouille pour que ça reste compatible, soit on le vire et on met un beau message dans le log de xorg pour dire qu'il n'existe plus.

          Bref dans le xorg.conf il fallait mettre :
          Options "XkbLayout" "ch"
          Options "XkbVariant" "fr"
    • [^] # Re: Attention, ce n'est qu'un dispositif de secours !

      Posté par (page perso) . Évalué à 5.

      Peut-être en dernier secours mais pas plus tard que la semaine dernière, j'essaie de lire un CD photos prises et gravées il y a maintenant presque 7 ans.
      Le CD complètement intact dans sa boite qui n'a pratiquement jamais bougé de la pile de CDs pendant tout se temps s'est avéré illisible alors qu'il y a 4/5 ans ou je l'avait utilisé pour la dernière fois, il marchait nickel !
      Bref, je le teste dans 4/5 lecteurs différents sans aucun succès. Je me résigne en me disant que photorec pourrait peut-être faire quelque chose pour moi l'ayant déjà utilisé plusieurs fois pour des amis. Je le lance et là... LE MIRACLE au bout de 15/16h d'attente, je n'était pas pressé vu que je n'y croyais que très moyennement. La sauvegarde c'est bien mais photorec c'est mieux :)

      Depuis cette mésaventure, je me demande si je peux faire confiance à mes CDs. Je savais que la durée de vie d'un CD n'était pas éternelle mais bon là, moins de 10 ans pour un CD de "marque" (un verbatim)...
      Du coup je ne sais pas si je dois me prévoir une session regravage tout les cinq ans comme les vacins :p

Suivre le flux des commentaires

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