Récuperation données partition chiffrée

Compte anonymisé · Le 06/05/2016, à 23:00

Dende2 a écrit :

Juste pour infom la commande
sudo dd if=/dev/sda5 of=/dev/sdc1 conv=notrunc,noerror
sert-elle a couper ou simplement a copier ? En gros, puis-je l arreter sans risaue a tout moment ?

laisse faire jusqu'à la fin (c'est normal, ça peut prendre quelques heures..), tu auras ainsi une copie exacte (en l'état) de sda5.
et ensuite après cette copie dd, tu tentera (puisque ton système a planté brutalement) :

sudo fsck -f -y /dev/mapper/rom (rien ne prouve que lvm ne soit installé...tu te souviens si tu avais un volume swap ?)

je suppose que ton boot séparé a été viré pendant la migration juste avant le plantage, je ne vois pas d'autres explications..

Dernière modification par Compte anonymisé (Le 06/05/2016, à 23:05)

maxire · Le 06/05/2016, à 23:09

@localhost, dans message #3 allusion à un problème avec dev-mapper-crypstswap1.device.
Je ne me souviens plus ce que propose l'installateur de Ubuntu, chiffrage total de l'installation (donc lvm) oui, mais est-il possible de ne chiffrer que /home?

Dans ce cas, une fois /dev/mapper/rom monté la commande blkid aurait dû lister le système de fichiers de /home.

Dernière modification par maxire (Le 06/05/2016, à 23:09)

Dende2 · Le 06/05/2016, à 23:10

Localhost a écrit :

Dende2 a écrit :
Juste pour infom la commande
sudo dd if=/dev/sda5 of=/dev/sdc1 conv=notrunc,noerror
sert-elle a couper ou simplement a copier ? En gros, puis-je l arreter sans risaue a tout moment ?
laisse faire jusqu'à la fin (c'est normal, ça peut prendre quelques heures..), tu auras ainsi une copie exacte (en l'état) de sda5.
et ensuite après cette copie dd, tu tentera (puisque ton système a planté brutalement) :
sudo fsck -f -y /dev/mapper/rom (rien ne prouve que lvm ne soit installé...tu te souviens si tu avais un volume swap ?)
je suppose que ton boot séparé a été viré pendant la migration juste avant le plantage, je ne vois pas d'autres explications..

Jai essaye directement sur le volume chiffre present sur mon ordi

ubuntu@ubuntu:~$ sudo fsck -f -y /dev/mapper/rom
fsck from util-linux 2.26.2
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/mapper/rom

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Compte anonymisé · Le 06/05/2016, à 23:30

maxire a écrit :

@localhost, dans message #3 allusion à un problème avec dev-mapper-crypstswap1.device.
Je ne me souviens plus ce que propose l'installateur de Ubuntu, chiffrage total de l'installation (donc lvm) oui, mais est-il possible de ne chiffrer que /home?
Dans ce cas, une fois /dev/mapper/rom monté la commande blkid aurait dû lister le système de fichiers de /home.

c'est tout son système qui est chiffré avec boot séparé, c'est possible avec ou sans lvm, il me semble que l'installateur utilise en effet lvm pour un chiffrement complet du système, mais on ne sait pas comment son système a été installé.

cette commande pourrait peut être nous donner quelques infos si présence d'un système de fichier:

sudo dumpe2fs -h /dev/mapper/rom

Dende2 · Le 06/05/2016, à 23:47

ubuntu@ubuntu:~$ sudo dumpe2fs -h /dev/mapper/rom
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/rom
Couldn't find valid filesystem superblock.

Compte anonymisé · Le 07/05/2016, à 00:13

Dende2 a écrit :

ubuntu@ubuntu:~$ sudo dumpe2fs -h /dev/mapper/rom
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/rom
Couldn't find valid filesystem superblock.

aucun système de fichier alors retour à la case départ pour un lvm qui ne fonctionne pas...relance lvm2 depuis le live au cas ou...après je sais pas, pas assez de recul concernant son utilisation.

vérifie aussi cryptsetup avec:

sudo cryptsetup status rom

Dernière modification par Compte anonymisé (Le 07/05/2016, à 00:20)

Nasman · Le 07/05/2016, à 12:10

A la place de dd on peut utiliser dcfldd (à "installer en session Live via internet car il n'est pas présent dans le dvd). dcfldd affiche un état d'avancement (mais ce type d'opérations peut durer des heures - mais c'est mieux quand on voit l'avancement).

A priori dd ou dcfldd ne font qu'une copie (si la commande est correctement tapée) - la syntaxe pour dcfldd est identique à dd

Nuliel · Le 07/05/2016, à 13:00

Houla, j'ai loupé pas mal de réponses.

Peux tu essayer la méthode utilisée sur la documentation: https://doc.ubuntu-fr.org/tutoriel/chif … nuellement
cad sur un live cd:

sudo su
cryptsetup luksOpen /dev/sda5 toto
lvchange -ay /dev/mapper/sda5
lvs
mkdir /mnt/disquedur
mount /dev/VG/... /mnt/disquedur/

Si toutes les commandes fonctionnent et que tu as fini de récupérer tes données,

sudo umount /mnt/disquedur

Dernière modification par Nuliel (Le 07/05/2016, à 13:07)

maxire · Le 07/05/2016, à 13:32

Non Ublender,

lvchange /dev/mapper/sda5 ne fonctionnera pas c'est toto que tu trouveras sous /dev/mapper, de plus la commande lvchange s'applique à un volume LVM en utilisant le nom de volume défini via lvm, ces noms de volumes sont disponibles en appliquant la commande lvdisplay.

Le problème actuel est qu'aucun volume physique LVM n'est détecté dans /dev/mapper/toto, pour reprendre ta notation.

Dernière modification par maxire (Le 07/05/2016, à 13:33)

Nuliel · Le 07/05/2016, à 13:56

Ok, je n'avais pas compris. Là, je ne vais absolument pas savoir faire pour réparer et monter la partition. Par contre, si on réussit à déchiffrer la partition entière (même si on récupère un lvm cassé) et qu'on utilise photorec, on devrait pouvoir récupérer les données (ce sera un bazar innommable, mais on aura récupéré les données). Je vais chercher de ce côté là.

maxire · Le 07/05/2016, à 14:01

Il n'existe pas de problème pour monter la partition chiffrée, elle ne semble plus/pas héberger de volumes LVM c'est tout.
Effectivement utiliser testdisk puis en cas d'échec photorec pourrait être une solution.

Ce qui est gênant c'est que c'est une partition de 298 G, c'est tout de même énorme.

Compte anonymisé · Le 07/05/2016, à 14:53

à noter: sur mes Live Ubuntu et Debian, lvm2 n'est pas installé par défaut en cas d'essai sans installation...
L'installateur ne va extraire le module lvm quand cas de besoin ...

@ Dende2 sudo apt-cache policy lvm2 ... pour vérifier...

Compte anonymisé · Le 07/05/2016, à 14:57

Je vous trouve un peu fatalistes à dire que les données sont détruites. Le plus gros risque était que le header LUKS ait été détruit, ce qui aurait annulé les chances de récupérer quoi que ce soit. Ici, le montage fonctionne bien, ce qu'il reste du système est donc accessible intégralement en clair. Le problème semble se limiter à une table de partitions endommagée.

La mise à niveau plantée a bien pu détruire des données, ou pas. Ça m'étonnerait qu'elle ait détruit beaucoup. Je penche plutôt pour un plantage pendant une manipulation de la table des partitions LVM, ce qui voudrait dire que les données sont encore là.

Vus les messages de ce thread, je suppose pour l'instant que les données sont là, mais inaccessibles.

En fait, vous avez sûrement déjà compris tout ça, ce message est surtout pour rassurer Dende2 qui n'a pas l'air serein, vus ses derniers messages. Il est possible que les données aient disparu, mais rien n'indique que ça soit le cas, et je parie plutôt sur le contraire. Dans tout les cas, il faut garder ce disque intact, et faire les manipulations sur une copie. La récupération peut être compliquée et longue, et nécessiter de nombreux essais, mais elle a pas mal de chances de réussir.

Tout ça n'est bien sûr pas sûr, vu qu'on ne sait pas ce que l'upgrade a fait. Je n'ai jamais utilisé Photorec, mais je connais de nom, et ça me paraît être la meilleure option. En tout cas, ça ne va pas contredire ceux qui disent que le système d'upgrade d'Ubuntu n'est pas fiable (jamais eu de problèmes personnellement).

Et j'espère que tout ça t'apprendra à faire des sauvegardes.

Edit : J'ai lu en page 2 que tu (Dende2) pense avoir détruit les 850 Mo copiés par le dd avorté. C'est faux : dd ne sert qu'à copier les données, pas à "couper". Ta commande ne fait que copier un disque sur l'autre.

En fait, je pense qu'essayer testdisk en premier est préférable, car il sera plus facile de récupérer les données si on arrive à monter la partition normalement.

Je suppose que la copie de ton disque interne sur le disque externe est terminée. On va manipuler celle-ci, pour éviter de corrompre encore plus l'original. Je suppose aussi que le nom de cette copie est /dev/sdc1, comme dans la commande que tu as postée précédemment. Si tu avais annulé la copie, relance la et laisse-la se terminer. Ça peut être long.

Une fois la copie terminée, monte le volume chiffré avec

sudo cryptsetup luksOpen /dev/sdc1 crypt

.
ensuite, installe testdisk :

sudo apt-get install testdisk

et lance le :

sudo testdisk /dev/mapper/crypt

testdisk devrait s'ouvrir avec /dev/mapper/crypt sélectionné (si le montage de l'étape précédente a fonctionné). Appuie sur Entrée.

Il va te demander le type de table de partition. Chez moi, le bon choix est automatiquement sélectionné, mais si ta table de partitions est morte, il ne va pas la détecter. Essaye avec "Intel" (il faut se déplacer avec les touches fléchées du clavier et valider avec Entrée, pas de souris ici). À l'écran suivant, choisis "Analyse", appuie sur Entrée. Note ce qui s'affiche (probablement aucune partition si la table est endommagée), puis appuie une autre fois sur Entrée pour lancer une analyse rapide. Une fois cette analyse terminée, poste ici ce qu'elle a trouvé. Ça peut prendre beaucoup de temps sur un disque aussi grand, mais la progression est affichée.

Enfin, si cette dernière étape (analyse rapide) ne donne rien, choisis de faire une analyse plus poussée (tu auras l'option à la fin de l'analyse rapide). Poste les résultats des trois étapes (après avoir choisi "Analyse", après l'analyse rapide, et après l'analyse poussée).

Si ça ne donne rien, réessaye en choisissant "GPT" à la place de "Intel".

Dernière modification par Compte anonymisé (Le 07/05/2016, à 15:23)

Compte anonymisé · Le 07/05/2016, à 15:21

Aucun pessimisme pour moi, les données sont toujours là, c'est simplement un problème lvm, un plantage système peut détériorer un système de fichier mais rarement une partition cryptsetup, (jamais vu) Maxire a raison de penser que c'est un problème lvm, parceque lorsqu'on indique à l'installateur Ubuntu de chiffrer un système complet, il utilise lvm, c'est ce qu'à du faire Dende2.

Et sur mes Live Ubuntu, lvm2 n'est pas installé lorsque je fais essayer Ubuntu sans installer...
alors @ Dende2 sudo apt-cache policy lvm2 depuis ton live, j'ai un doute qu'il soit opérationnel même si la commande sudo lvscan n'a rien retourné.

Compte anonymisé · Le 07/05/2016, à 15:26

Localhost a écrit :

Aucun pessimisme pour moi, les données sont toujours là

Dende2 a dit dans un message qu'il se sentait mal, je préférais ajouter une couche d'optimisme pour qu'il ne panique pas pour rien.

Et sur mes Live Ubuntu, lvm2 n'est pas installé lorsque je fais essayer Ubuntu sans installer...
alors @ Dende2 sudo apt-cache policy lvm2 depuis ton live, j'ai un doute qu'il soit opérationnel même si la commande sudo lvscan n'a rien retourné.

Tu as raison, c'est important. Avant de faire ce que j'ai dit,

sudo apt-get install lvm2

.
Par contre, je ne sais pas si testdisk supporte lvm. Si ce n'est pas le cas, il restera la solution photorec, l'inconvénient étant que les noms de fichier et l'arborescence des dossiers seront perdus si j'ai bien compris.

maxire · Le 07/05/2016, à 15:42

Testdisk traite LVM mais peut-être pas sans problème.

Nous ne savons pas exactement ce qui s'est passé lors de cette tentative de mise à niveau, le fait est que la partition boot a été effacée et la partition chiffrée qui était montée lors de cette mise à niveau a souffert.

Donc, oui les données sont certainement présentes mais est-il réellement possible de coller les morceaux via testdisk?

En sachant que la dégradation de /dev/sda5 a il me semble cassé le volume physique LVM et il est également possible que les systèmes de fichiers hébergés par les volumes logiques LVM aient eux-mêmes été cassés.

C'est une vision ni optimiste ni pessimiste, c'est juste un scénario possible.

L'outil Testdisk sera-il capable de recoller les morceaux?
Nous verrons bien.

@localhost, ce que je trouve bizarre c'est que dende2 a utilisé la commande lvscan de lvm via un live-usb sans de message d'erreur indiquant que cette commande est inconnue.

Que les commandes LVM ne soient pas disponibles en live-usb, je te crois, la commande blkid par contre aurait dû détecter les volumes LVM ce qui n'a pas été le cas.

Dernière modification par maxire (Le 07/05/2016, à 15:43)

Compte anonymisé · Le 07/05/2016, à 15:51

Si testdisk ne recolle rien, on lancera photorec qui récupèrera les photos une par une. J'espère que Dende2 n'a pas déjà abandonné.

Dende2 · Le 07/05/2016, à 20:32

Localhost a écrit :

à noter: sur mes Live Ubuntu et Debian, lvm2 n'est pas installé par défaut en cas d'essai sans installation...
L'installateur ne va extraire le module lvm quand cas de besoin ...
@ Dende2 sudo apt-cache policy lvm2 ... pour vérifier...

ubuntu@ubuntu:~$ sudo apt-cache policy lvm2
lvm2:
  Installed: 2.02.122-1ubuntu1
  Candidate: 2.02.122-1ubuntu1
  Version table:
 *** 2.02.122-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ wily/main i386 Packages
        100 /var/lib/dpkg/status

Dende2 · Le 07/05/2016, à 20:35

TriChromureDeChaton a écrit :

Je vous trouve un peu fatalistes à dire que les données sont détruites. Le plus gros risque était que le header LUKS ait été détruit, ce qui aurait annulé les chances de récupérer quoi que ce soit. Ici, le montage fonctionne bien, ce qu'il reste du système est donc accessible intégralement en clair. Le problème semble se limiter à une table de partitions endommagée.
La mise à niveau plantée a bien pu détruire des données, ou pas. Ça m'étonnerait qu'elle ait détruit beaucoup. Je penche plutôt pour un plantage pendant une manipulation de la table des partitions LVM, ce qui voudrait dire que les données sont encore là.
Vus les messages de ce thread, je suppose pour l'instant que les données sont là, mais inaccessibles.
En fait, vous avez sûrement déjà compris tout ça, ce message est surtout pour rassurer Dende2 qui n'a pas l'air serein, vus ses derniers messages. Il est possible que les données aient disparu, mais rien n'indique que ça soit le cas, et je parie plutôt sur le contraire. Dans tout les cas, il faut garder ce disque intact, et faire les manipulations sur une copie. La récupération peut être compliquée et longue, et nécessiter de nombreux essais, mais elle a pas mal de chances de réussir.
Tout ça n'est bien sûr pas sûr, vu qu'on ne sait pas ce que l'upgrade a fait. Je n'ai jamais utilisé Photorec, mais je connais de nom, et ça me paraît être la meilleure option. En tout cas, ça ne va pas contredire ceux qui disent que le système d'upgrade d'Ubuntu n'est pas fiable (jamais eu de problèmes personnellement).
Et j'espère que tout ça t'apprendra à faire des sauvegardes.
Edit : J'ai lu en page 2 que tu (Dende2) pense avoir détruit les 850 Mo copiés par le dd avorté. C'est faux : dd ne sert qu'à copier les données, pas à "couper". Ta commande ne fait que copier un disque sur l'autre.
En fait, je pense qu'essayer testdisk en premier est préférable, car il sera plus facile de récupérer les données si on arrive à monter la partition normalement.
Je suppose que la copie de ton disque interne sur le disque externe est terminée. On va manipuler celle-ci, pour éviter de corrompre encore plus l'original. Je suppose aussi que le nom de cette copie est /dev/sdc1, comme dans la commande que tu as postée précédemment. Si tu avais annulé la copie, relance la et laisse-la se terminer. Ça peut être long.
Une fois la copie terminée, monte le volume chiffré avec
sudo cryptsetup luksOpen /dev/sdc1 crypt
.
ensuite, installe testdisk :
sudo apt-get install testdisk
et lance le :
sudo testdisk /dev/mapper/crypt
testdisk devrait s'ouvrir avec /dev/mapper/crypt sélectionné (si le montage de l'étape précédente a fonctionné). Appuie sur Entrée.
Il va te demander le type de table de partition. Chez moi, le bon choix est automatiquement sélectionné, mais si ta table de partitions est morte, il ne va pas la détecter. Essaye avec "Intel" (il faut se déplacer avec les touches fléchées du clavier et valider avec Entrée, pas de souris ici). À l'écran suivant, choisis "Analyse", appuie sur Entrée. Note ce qui s'affiche (probablement aucune partition si la table est endommagée), puis appuie une autre fois sur Entrée pour lancer une analyse rapide. Une fois cette analyse terminée, poste ici ce qu'elle a trouvé. Ça peut prendre beaucoup de temps sur un disque aussi grand, mais la progression est affichée.
Enfin, si cette dernière étape (analyse rapide) ne donne rien, choisis de faire une analyse plus poussée (tu auras l'option à la fin de l'analyse rapide). Poste les résultats des trois étapes (après avoir choisi "Analyse", après l'analyse rapide, et après l'analyse poussée).
Si ça ne donne rien, réessaye en choisissant "GPT" à la place de "Intel".

ubuntu@ubuntu:~$ sudo apt-get install testdisk
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package testdisk
ubuntu@ubuntu:~$ sudo testdisk /dev/mapper/crypt
sudo: testdisk: command not found

Dernière modification par Dende2 (Le 07/05/2016, à 20:46)

Dende2 · Le 07/05/2016, à 20:42

TriChromureDeChaton a écrit :

Si testdisk ne recolle rien, on lancera photorec qui récupèrera les photos une par une. J'espère que Dende2 n'a pas déjà abandonné.

J abandonne rien ne ten fais pas
Jai du mal a me connecter a cause des mes horaires de travail assez enorme, je viens des que possible, je lis tout et jessaie tout
merci enormement pour laide
pour la copie, cest un peu complique... mon pc est une vieu portable, et jai peur quil lache pendant la transmission (il faudrait environ 35heures) et que je perde simplement tout... donc tant pis, je vais risquer d agir directement sur ma partition presente sur mon pc...

Dernière modification par Dende2 (Le 07/05/2016, à 20:58)

Compte anonymisé · Le 07/05/2016, à 23:11

Désolé, je suis sous Arch Linux, ça fait longtemps que je n'utilise plus Ubuntu, donc je ne peux pas tout tester aussi facilement que si on avait le même système.

Donc, pour installer testdisk, tu dois activer les dépôts Universe (ils le sont par défaut, mais pas en Live USB). Voici la marche à suivre dont je me souviens : lance un programme appelé "Sources de logiciels", ou quelque chose comme ça. Je crois qu'il est dans les Paramètres système, vers la fin, sinon tu peux le chercher dans le menu d'Ubuntu.

Dans le premier onglet, il devrait y avoir une case à cocher pour Universe. Coche la, valide, puis une fois que c'est fini fais :

sudo apt-get update
sudo apt-get install testdisk

. Ensuite, suis le reste de mon post.

Utiliser testdisk pour analyser le disque ne devrait rien changer dessus, donc on est totalement safe pour l'instant.

Dende2 · Le 08/05/2016, à 11:19

Voici le resultat de la manip
Je suis pas certain davoir monte le disaue correctement, si ce resultat nest pas exploitable, jessaierai differement

TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 319 GB / 297 GiB - 624635904 sectors

The harddisk (319 GB / 297 GiB) seems too small! (< 4289 GB / 3994 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  FAT16 >32M             115897315 3875031058 3759133744
   HPFS - NTFS            148296879 2526024575 2377727697
   FAT32                  180015828 4207011058 4026995231
   FAT32 LBA              189354467 3174111381 2984756915
   FAT16 <32M             217146356 3964361960 3747215605
   HPFS - NTFS            230858522 2996112224 2765253703
   FAT12                  249128087 4145176720 3896048634
   FAT16 >32M             304467532 3993243151 3688775620
   FAT32                  406690339 2304648198 1897957860
   FAT32 LBA              417486572 1178296380  760809809

Compte anonymisé · Le 08/05/2016, à 12:49

C'est le résultat de quelle analyse ? L'analyse rapide ou l'analyse complète ?

D'après cette page, testdisk s'attend à un disque de 4 To parce qu'il additionne la taille de toutes les partitions dont il a trouvé des traces. Ton disque semble avoir été reformaté beaucoup de fois.

Je ne vois rien là-dedans qui ressemble aux systèmes de fichiers utilisés par Ubuntu (ext4 normalement). C'est peut-être dû à LVM qui n'est pas géré par testdisk (pas eu l'occasion de faire de test là-dessus).

Finalement, j'ai changé d'avis : la meilleure option est de lancer photorec tout de suite et de sauvegarder tout ce qui peut l'être sur ton disque externe avant d'essayer de jouer avec les partitions. On pourra ensuite faire ce qu'on voudra avec le disque original pour tenter de récupérer la partition entière (et l'arborescence, avec les noms de fichier).

On va donc utiliser photorec. D'abord, tu dois partitionner ton disque externe, car on aura besoin cette fois d'un vrai système de fichier où on pourra enregistrer ce qu'on a récupéré. Assure-toi que le disque externe ne contient rien d'important, et qu'il est bien représenté par /dev/sdc (comme tes précédentes commandes semblent indiquer), et formate le :

sudo fdisk /dev/sdc
o
n
<Entrée>
<Entrée>
<Entrée>
<Entrée>
w
sudo mkfs.ext4 /dev/sdc1
sudo mount /dev/sdc1 /mnt

Ensuite, lance photorec, qui a dû être installé avec testdisk :

sudo photorec /dev/mapper/crypt

Une fois photorec lancé, tu auras normalement un seul choix (/dev/mapper/crypt) : appuie sur Entrée. Ensuite, choisis l'option "Whole disk" (la première), puis choisis la première option ([ext2/ext3]).

On te demande maintenant l'endroit où tu voudrais stocker les fichiers récupérés. Déplace toi jusqu'à l'intérieur du dossier /mnt (flèche gauche pour monter d'un niveau, flèche droite pour descendre dans un dossier).

Attention : vérifie bien que tu choisis les bons emplacements ! si tu formates ton disque interne, si tu restaures tes fichiers autre part que sur le disque externe, tu risques d'écraser des données que tu voulais récupérer !

De plus, relis toutes mes commandes ou attends que quelqu'un le fasse et confirme qu'elles sont correctes, je ne voudrais pas causer une catastrophe à cause d'une erreur bête.

Si tu es sûr d'avoir tout vérifié, appuie sur la touche 'c' pour valider. photorec va lire toute la partition déchiffrée à la recherche de fichiers, et copiera tout ce qu'il trouvera dans /mnt (là où on a monté ton disque externe). Ce disque externe contiendra tous les fichiers trouvés, rangés dans des dossiers, mais les noms seront aléatoires. Si tu avais beaucoup de photos, ça peut être gênant, mais c'est mieux que tout perdre.

Si ça ne fonctionne pas, on essaiera avec l'autre option ("Other" à la place de "ext2/ext3"), mais normalement tous tes fichiers étaient stockés dans du ext.

Dende2 · Le 08/05/2016, à 13:08

ok ca marche
combien de partitions sont necessaires sur sdc1? jen fais quune seule ou je dois en faire deux ?

maxire · Le 08/05/2016, à 13:15

Avant d'aller plus loin, ce serait bien que tu nous précises comment tu es arrivé à cet affichage.
Je donne en exemple les différentes étapes par lesquelles je passe pour analyser complètement un conteneur chiffré hébergeant 2 volumes logiques LVM contenant respectivement du NTFS et de l'ext4.

frankenstein@FRANKENSTEIN ~]$ sudo cryptsetup open /dev/sdc1 crypt
Saisissez la phrase secrète pour /dev/sdc1 : 
[frankenstein@FRANKENSTEIN ~]$ sudo testdisk /dev/mapper/crypt
===> Écran 1
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

  TestDisk is free software, and
comes with ABSOLUTELY NO WARRANTY.

Select a media (use Arrow keys, then press Enter):
>Disk /dev/mapper/crypt - 4234 MB / 4037 MiB




































>[Proceed ]  [  Quit  ]

Note: Disk capacity must be correctly detected for a successful recovery.
If a disk listed above has incorrect size, check HD jumper settings, BIOS
detection, and install the latest OS patches and disk drivers.

===> Écran 2
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


Disk /dev/mapper/crypt - 4234 MB / 4037 MiB

Please select the partition table type, press Enter when done.
 [Intel  ] Intel/PC partition
 [EFI GPT] EFI GPT partition map (Mac i386, some x86_64...)
 [Humax  ] Humax partition table
 [Mac    ] Apple partition map
>[None   ] Non partitioned media
 [Sun    ] Sun Solaris partition
 [XBox   ] XBox partition
 [Return ] Return to disk selection



Hint: None partition table type has been detected.
Note: Do NOT select 'None' for media with only a single partition. It's very
rare for a disk to be 'Non-partitioned'.

===> Écran 3
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org


Disk /dev/mapper/crypt - 4234 MB / 4037 MiB
     8269696 sectors - sector size=512

>[ Analyse  ] Analyse current partition structure and search for lost partitions
 [ Advanced ] Filesystem Utils
 [ Geometry ] Change disk geometry
 [ Options  ] Modify options
 [ Quit     ] Return to disk selection







Note: Correct disk geometry is required for a successful recovery. 'Analyse'
process may give some warnings if it thinks the logical geometry is mismatched.

===> Écran 4
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 4234 MB / 4037 MiB - 8269696 sectors
Current partition structure:
     Partition                  Start        End    Size in sectors

   P Linux LVM2                     0    8269695    8269696


>[Quick Search]
                            Try to locate partition

===> Écran 5
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 4234 MB / 4037 MiB - 8269696 sectors
     Partition               Start        End    Size in sectors
>P Linux LVM2                     0    8269695    8269696


Structure: Ok.


Keys T: change type,
     Enter: to continue
LVM2, 4234 MB / 4037 MiB

===> Écran 6
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 4234 MB / 4037 MiB - 8269696 sectors

     Partition                  Start        End    Size in sectors

   P Linux LVM2                     0    8269695    8269696

Write isn't available because the partition table type "None" has been selected.


 [  Quit  ] >[Deeper Search]

===> Écran 7
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 4234 MB / 4037 MiB - 8269696 sectors

The harddisk (4234 MB / 4037 MiB) seems too small! (< 4296 MB / 4096 MiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  NTFS                     4196351    8390654    4194304


[ Continue ]
NTFS, blocksize=4096, 2147 MB / 2048 MiB

===> Écran 8
TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/mapper/crypt - 4234 MB / 4037 MiB - 8269696 sectors
     Partition               Start        End    Size in sectors
>P NTFS                           0    8269695    8269696
 P Linux LVM2                     0    8269695    8269696
 P NTFS                        2048    4196351    4194304
 P ext4                     4196350    6293501    2097152
 P ext4                     4196352    6293503    2097152

Structure: Ok.


Keys T: change type, P: list files,
     Enter: to continue
NTFS found using backup sector, blocksize=4096, 4234 MB / 4037 MiB

Tout ceci pour informer qu'avec Testdisk version 7.0 (tu utilises la version 6.14) disponible sous Archlinux, il n'existe pas de problème pour reconnaître du LVM.

Mais bon, rien n'est cassé dans mon système.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 06/05/2016, à 23:00

Re : Récuperation données partition chiffrée

#52 Le 06/05/2016, à 23:09

Re : Récuperation données partition chiffrée

#53 Le 06/05/2016, à 23:10

Re : Récuperation données partition chiffrée

#54 Le 06/05/2016, à 23:30

Re : Récuperation données partition chiffrée

#55 Le 06/05/2016, à 23:47

Re : Récuperation données partition chiffrée

#56 Le 07/05/2016, à 00:13

Re : Récuperation données partition chiffrée

#57 Le 07/05/2016, à 12:10

Re : Récuperation données partition chiffrée

#58 Le 07/05/2016, à 13:00

Re : Récuperation données partition chiffrée

#59 Le 07/05/2016, à 13:32

Re : Récuperation données partition chiffrée

#60 Le 07/05/2016, à 13:56

Re : Récuperation données partition chiffrée

#61 Le 07/05/2016, à 14:01

Re : Récuperation données partition chiffrée

#62 Le 07/05/2016, à 14:53

Re : Récuperation données partition chiffrée

#63 Le 07/05/2016, à 14:57

Re : Récuperation données partition chiffrée

#64 Le 07/05/2016, à 15:21

Re : Récuperation données partition chiffrée

#65 Le 07/05/2016, à 15:26

Re : Récuperation données partition chiffrée

#66 Le 07/05/2016, à 15:42

Re : Récuperation données partition chiffrée

#67 Le 07/05/2016, à 15:51

Re : Récuperation données partition chiffrée

#68 Le 07/05/2016, à 20:32

Re : Récuperation données partition chiffrée

#69 Le 07/05/2016, à 20:35

Re : Récuperation données partition chiffrée

#70 Le 07/05/2016, à 20:42

Re : Récuperation données partition chiffrée

#71 Le 07/05/2016, à 23:11

Re : Récuperation données partition chiffrée

#72 Le 08/05/2016, à 11:19

Re : Récuperation données partition chiffrée

#73 Le 08/05/2016, à 12:49

Re : Récuperation données partition chiffrée

#74 Le 08/05/2016, à 13:08

Re : Récuperation données partition chiffrée

#75 Le 08/05/2016, à 13:15

Re : Récuperation données partition chiffrée

Pied de page des forums