Récupérer les données sur clé USB défectueuse – Photorec
Lorsque je pars en vacances j’aime bien avoir mes PlayLists audio sur une clé USB que je branche dans la voiture. Et là, après avoir récupéré mon véhicule au garage (oui, m’a vie est pleine d’imprévues) ma clé tombe au sol. Je la branche et l’écran de ma voiture m’affiche « Erreur connexion usb… ». Bref elle ne fonctionne plus.
Je préviens, inutile de me mettre en commentaire des propos du genre : une playlist sur clé usb, c’est un truc de vieux, tu peux avoir tes playlists en ligne, il y a des services dédiés… En plus Sima, tu as tes playlists sur ton cloud, alors ton smartphone et le bluetooth, tu sais ça marche bien, etc »
Je sais tout ça, donc inutile de me le rappeler, mes gosses se chargent déjà très bien de ce genre de réflexion IRL…
Bah oui, c’est peut-être un truc de vieux d’avoir ses playlists sur clé usb, et moi j’aime bien !
Rentrons donc dans le vif du sujet, je ne peux plus accéder aux musiques de ma clé usb.
Je branche la clé USB sur mon pc portable, elle s’allume mais ne clignote pas, ne se monte pas automatiquement.
Bon je sens que je vais passer plusieurs lignes de commande en root alors pour ne pas répéter les « sudo »
$ sudo -s
Ensuite, voyons si elle est visible
root@Port-01:~# fdisk -l [Je ne mets pas tout l’affichage, allons à l’essentiel, tout en bas] (…) Périphérique Amorçage Début Fin Secteurs Taille Id Type /dev/sdb1 * 32 15669247 15669216 7,5G c W95 FAT32 (LBA)
Point positif la clé est vue !
Donc j’essaie de la monter à la main :
root@Port-01:~# mount /dev/sdb1 /media/sima/ mount: /media/sima : wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.
Bon là c’est déjà moins sympa. Je tente un fsck, sans grande conviction :
root@Port-01:~# fsck -r /dev/sdb1 fsck de util-linux 2.31.1 e2fsck 1.44.1 (24-Mar-2018) ext2fs_open2: Numéro magique invalide dans le super-bloc fsck.ext2 : Superbloc invalide, tentons d'utiliser les blocs de sauvetage... fsck.ext2: Numéro magique invalide dans le super-bloc lors de la tentative d'ouverture de /dev/sdb1 Le superbloc n'a pu être lu ou ne contient pas un système de fichiers ext2/ext3/ext4 correct. Si le périphérique est valide et qu'il contient réellement un système de fichiers ext2/ext3/ext4 (et non pas de type swap, ufs ou autre), alors le superbloc est corrompu, et vous pourriez tenter d'exécuter e2fsck avec un autre superbloc : e2fsck -b 8193 <périphérique> ou e2fsck -b 32768 <périphérique> /dev/sdb1: status 8, rss 4400, real 0.107799, user 0.004140, sys 0.004140
Bon, comme ce n’est pas satisfaisant et que je n’ai pas envi de perdre trop de temps en ligne de commande, passons directement à Photorec.
Photorec
Ayant déjà utiliser Photorec avec succès, je me dis : pourquoi pas !
Installation de TestDisk dans lequel se trouve photorec
root@Port-01:~# apt install testdisk
Puis on lance :
root@Port-01:~# photorec PhotoRec 7.0, Data Recovery Utility, April 2015 Christophe GRENIER <grenier@cgsecurity.org> http://www.cgsecurity.org
Le dernier screenshot est pris en cours d’exécution.
Et là, hourra ! Non seulement j’ai récupéré toutes mes musiques mais aussi retrouvé des fichiers que j’avais effacés depuis longtemps (photos, textes, vidéos, etc.).
Bien entendu, les fichiers audios ne sont plus ordonnés comme avant et n’ont plus leur nom de fichier d’origine mais un nom imposé par défaut lors de la récupération.
Reste plus qu’à passer par une application permettant de renommer mes fichiers audios en se basant sur les tag… Puis remettre tout sur une nouvelle clé USB.
J’ai utilisé « Entagged », mais il en existe plein d’autres sous linux « EasyTAG », etc. Ce sera peut-être un sujet de billet à venir.
Note: Si je n’ai pas récupéré mes playlists directement depuis mon cloud, ce qui aurait été plus simple, c’est que j’avais une connexion catastrophique à cet instant. Installer testdisk était la solution la plus rapide, même si j’ai dû m’y reprendre à deux fois.
Bonjour,
Content que tu aies pu récupérer les données!
J’aimerais juste apporter quelques précisions: généralement, lorsqu’on veut récupérer les données d’une clé usb défectueuse, on commence par le copier avec ddrescue vers un fichier iso (cela permet notamment de pouvoir travailler sur une copie et de ne plus écrire sur une clé usb qui pourrait mal supporter l’écriture), puis on peut tenter de réparer la copie. Ici fsck a cru reconnaître une partition extX, ce qui est probablement une erreur (généralement c’est plutôt une partition FAT32 qu’il y a sur les clés usb), je pense qu’il aurait fallu plutôt utiliser fsck.fat.
Une autre possibilité est d’utiliser testdisk sur la copie, il y a une option P pour lister les fichiers qui marche assez souvent et qui permet aussi de récupérer les noms et l’arborescence, et ça c’est cool!
Sinon, la musique sur une clé usb, c’est pas un truc de vieux, je fais la même chose 😉
@Nuliel Merci pour ces précisions complémentaires et précieuses. Je regrette d’avoir jeté la clé usb, j’aurai testé aussitôt.
Encore merci.
Hello,
Juste une remarque dont tu feras ce que tu veux : je trouve qu’il est plus propre de faire un « sudo -i » plutôt qu’un « sudo -s ». C’est la même différence qu’entre un « su – root » et un « su root ». Avec le -i tu ouvres une session comme l’utilisateur root (avec prise en charge de scripts d’ouverture de session .profile, .bash_profile, .login,…) avec le -s tu ne fais qu’invoquer un shell.
Voilà fin du dérangement et bonne journée.
@Gilles Tu as entièrement raison, sur tous les autres pc qui sont sous debian, je fais un « su – root » … Je retiens la leçon! 😉