Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

perte de partition, suite à arrêt de redimensionnement de la partition

herodote k210

Bonjour à tous,
J'ai un ordinateur sous ubuntu 16.04 et deux disques durs
j'ai voulu récupérer de la place sur un second Disque dur de 1 TO qui est récent
J'avais une partition data et une autre non utilisé pour pouvoir y installer une distribution au cas où.
J'ai voulu la supprimer avec gparted et ré-allouer l'espace à la partition data, j'ai lancé l'opération et en cours j'ai arrêté par inadvertance l'opération.
Maintenant gparted m'indique que j'ai 830go non alloués et que je dois les formater.
j'ai lu ici que l'on peut tenter de récupérer les informations et la partition avec testdisk.
Est ce la seule solution?

bluc

Bonjour
voila comme j'ai fait avec Testdisk

,ça fonctionne quand on a supprimé une partition par erreur

je n'ai pas bien compris,
Tu souhaitais supprimer cette partition data, donc vide certainement ,alors pourquoi vouloir la récupérer ?...
on récupère une partition qui contient des fichiers a cause des fichiers

herodote k210

Bonjour Bluc,
en fait je voulais élargir une première partition data en supprimant une partition qui ne servait à rien .
Lors du processus j'ai malencontreusement interrompu celui-ci en me trompant de bouton et donc la partition data a disparu du tableau, des partitions dans Gparted.
En tout cas merci de ta solution, j'ai lu plusieurs sujets à propos de test disque je voulais savoir s'il n'y avait pas d'autre solution donc je vais lire ton sujet tenter de résoudre le problème avec TestDisk.
Jean Marc.

herodote k210

J'ai regardé toute la documentation et les sujets concernant testdisk, certains conseil de le faire en live usb.
On a une partition qui apparaît après quicksearch et avant de taper write, là on peut accéder à la partition et faire une sauvegarde?

bluc

Oui il faut le faire en live
quand je l'ai utilisé , j'ai vraiment été surpris du résultat ,et c'est vraiment tres simple
je te souhaite la même chose

quand on choisis write,la partition réapparaît ou elle était

herodote k210

La partition est réapparue mais je ne peux y accéder que partiellement, uniquement via l'icône du bureau et pas par le menu du gestionnaire fichier, et de plus certains fichiers ne sont pas accessibles ou n'apparaissent même pas.
Ubuntu me dit que la structure a besoin d'un nettoyage.

bluc

Est ce qu'il t'es possible de sauvegarder sur un autre support dd-usb le maximum de données
et peut être de faire depuis gparted >> Périphérique >> Tenter une récupération des données , mais je ne te garanti rien , je n'ai jamais utilisé

herodote k210

Je vais acheter un DD. Et voir ce que cela donne.

Mais l'affirmation du "nettoyage de la structure de la partition", est pas très claire, j'obtiens cela quand je veux accéder à la partition.
J'ai fait une recherche et je n'ai rien trouvé à ce sujet

moko138

herodote k210,
Avant tout, désactive, dans les préférences de ton gestionnaire de fichiers, le montage automatique des périphériques amovibles !
Dans l'état où est la partition, il faut éviter à tout prix un fsck sur elle ! (le "nettoyage de la structure de la partition".) (S'il n'est pas trop tard).
Le plus sûr est encore de NE PAS brancher ton DDE.

Tu n'aurais rien dû valider dans testdisk (car si je comprends bien tu as fait un "write") avant d'avoir vu tes fichiers à l'étape "~~L" (Lister les éléments)~~.
CORRECTION : "P: list files" (=lister les éléments).
FIN de correction

L'aide d'un expert t'est nécessaire pour agir efficacement et ne plus rien faire d'irrémédiable.
Donc contactes-en un.

Non, il n'y avait pas besoin de passer en live, puisque ça se passait sur un disque autre que celui du système.
Et au moins, on disposerait du fichier testdisk.log.
D'ailleurs, si tu as utilisé une live persistante, et que tu as laissé cochée l'option "Create a log", tu le trouveras dans le home de ta live. S'il existe, colle son contenu ici ou, s'il est trop gros, téléverse le fichier chez un hébergeur, comme cjoint.com ou pastebin.

moko138

Pour comprendre l'état du système de fichiers, il faut avoir bien présent à l'esprit le caractère multicouches d'un disque en fonction :

Couche 1 : c'est le disque (support matériel).

Couche 2 : ce sont les frontières de la partition ("s'étend du point A au point B"), en tant que récipient, sans idée de formatage.

Couche 3 : c'est le système de fichiers (FS) (ext4 ou autre).

Couche 4 : ce sont les données. Elles sont supportées par la couche 3.

- -

En général, les couches 2 et 3 font la même taille, mais
- ce n'est pas obligatoire : on peut très bien mettre un FS de 500 Go dans une partition de 1000 Go ;
- c'est toujours faux pendant un redimensionnement.
> si on a demandé un agrandissement, il faut agrandir d'abord le récipient (couche 2)
> si on a demandé une réduction, il faut rétrécir d'abord le contenu (couche 3).
> /![/b] si on a demandé un déplacement, gparted procède en de nombreuses étapes, dont (je simplifie) les 4 temps suivants :
agrandir le récipient d'un côté (instantané) ;
agrandir le FS du même côté ;
rétrécir le FS du second côté ;
rétrécir le récipient du second côté (instantané).

La seule opération longue, c'est le déplacement du début du FS, car c'est tout le FS qui, morceau après morceau, est déplacé avec lui.
Avec un disque rotatif, prévoir environ une minute par Gio, soit une 15aine d'heures pour 1To !

Application :
Voici un compte-rendu, réel mais abrégé, de gparted
(en bleu et en romains : la couche "frontières",
en vert et en italiques : la couche FS).

Déplacer /dev/sdc4 vers la gauche et l'agrandir de 93.16 Gio à 118.85 Gio 03h16'38"
calibrer /dev/sdc4 00:00:01
calcule la nouvelle taille et position de /dev/sdc4 00:00:00

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:34"
e2fsck -f -y -v /dev/sdc4

agrandit la partition de 93.16 Gio à 118.85 Gio 00:00:02

déplacer le système de fichiers vers la gauche 03:13:24
effectuer le test en lecture seule 01:01:11
effectue le déplacement réel 02:12:13

réduit la partition de 118.85 Gio à 93.16 Gio 00:00:02
calcule la nouvelle taille et position de /dev/sdc4 00:00:01

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:48
e2fsck -f -y -v /dev/sdc4

agrandit la partition de 93.16 Gio à 118.85 Gio 00:00:02

vérifier le système de fichiers sur /dev/sdc4 et corriger les problèmes (si possible) 00:00:47
e2fsck -f -y -v /dev/sdc4
agrandir le système de fichiers pour remplir la partition 00:00:57
resize2fs /dev/sdc4
En train de redimensionner le système de fichiers sur /dev/sdc4 à 31156059 (4k) blocs.
Le système de fichiers /dev/sdc4 a maintenant une taille de 31156059 blocs.
==============

Concernant ton DDE, herodote k210, nous ignorons
- à quel stade les opérations ont été interrompues ;
- comment testdisk a procédé.
Voilà pourquoi je t'invite à ne rien faire sans le guidage par un expert.

herodote k210

Bonjour Moko138,
donc pour te répondre voici ton message et mes réponses:

moko138 a écritherodote k210,
Avant tout, désactive, dans les préférences de ton gestionnaire de fichiers, le montage automatique des périphériques amovibles !
Dans l'état où est la partition, il faut éviter à tout prix un fsck sur elle ! (le "nettoyage de la structure de la partition".) (S'il n'est pas trop tard).
Le plus sûr est encore de NE PAS brancher ton DDE.

J'ai débranché mon DDE comme tu me l'as indiqué.
Je me suis abstenu de lancer fsck, je ne savait qu'il y avait un lien entre le montage d'un périphérique amovible et la vérification par fsck.

moko138 a écrit Tu n'aurais rien dû valider dans testdisk (car si je comprends bien tu as fait un "write") avant d'avoir vu tes fichiers à l'étape "L" (Lister les éléments).

L'aide d'un expert t'est nécessaire pour agir efficacement et ne plus rien faire d'irrémédiable.
Donc contactes-en un.

.

Je n'avais pas vu la mention L pour liste, mais uniquement celle L pour logical, dans le choix du "format" de la partition. (D'ailleurs il se mêle des protocoles window et unix (fat, ntfs pour ext, boot...)

je vais faire appel à un expert.

Mais penses tu que au moins pour une fois je peux rebrancher mon DDE pour faire une sauvegarde sur un autre?

J'ai à peu près 85% de récupéré, dont une grande part de ce qui importe voire même la majeure partie.

moko138 a écrit Non, il n'y avait pas besoin de passer en live, puisque ça se passait sur un disque autre que celui du système.
Et au moins, on disposerait du fichier testdisk.log.
D'ailleurs, si tu as utilisé une live persistante, et que tu as laissé cochée l'option "Create a log", tu le trouveras dans le home de ta live. S'il existe, colle son contenu ici ou, s'il est trop gros, téléverse le fichier chez un hébergeur, comme cjoint.com ou pastebin.

Je ne l'ai pas fais en live et je suis passé par la mention "create log" donc je dois avoir un log quelque part, je vais le trouver et le mettre en lien.
Sur ma home je n'ai pas vu de fichier .testdisk

Et un grand merci pour ton second message, il a clarifié certains fait, je pensais que déplacer les cloisons d'une partition, déplaçait en même temps le système fichier.

herodote k210

J'ai trouvé avec la fonction recherche:

Sun Nov 18 01:08:47 2018
Command line: TestDisk

TestDisk 7.0, Data Recovery Utility, April 2015
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
OS: Linux, kernel 4.4.0-139-generic (#165-Ubuntu SMP Wed Oct 24 10:58:50 UTC 2018) x86_64
Compiler: GCC 5.3
ext2fs lib: 1.42.13, ntfs lib: libntfs-3g, reiserfs lib: none, ewf lib: none, curses lib: ncurses 6.0
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 976773168 sectors
/dev/sda: user_max 976773168 sectors
/dev/sda: native_max 976773168 sectors
/dev/sda: dco 976773168 sectors
/dev/sdb: LBA, HPA, LBA48, DCO support
/dev/sdb: size 1953525168 sectors
/dev/sdb: user_max 1953525168 sectors
/dev/sdb: native_max 1953525168 sectors
/dev/sdb: dco 1953525168 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors, sector size=512
Hard disk list
Disk /dev/sda - 500 GB / 465 GiB - CHS 60801 255 63, sector size=512 - ST3500312CS, S/N:9VV78L92, FW:SS16
Disk /dev/sdb - 1000 GB / 931 GiB - CHS 121601 255 63, sector size=512 - ST31000524NS, S/N:9WK42JP7, FW:AV22

Partition table type (auto): Intel
Disk /dev/sdb - 1000 GB / 931 GiB - ST31000524NS
Partition table type: Intel

Interface Advanced
Geometry from i386 MBR: head=255 sector=63
1 * Linux Swap 0 32 33 127 122 59 2045952
SWAP2 version 1, pagesize=4096, 1047 MB / 999 MiB
2 P Linux 127 122 60 117139 90 7 1879795712
ext4 blocksize=4096 Large_file Sparse_SB Recover, 962 GB / 896 GiB
New options :
Dump : No
Align partition: Yes
Expert mode : No

Interface Advanced
Geometry from i386 MBR: head=255 sector=63
1 * Linux Swap 0 32 33 127 122 59 2045952
SWAP2 version 1, pagesize=4096, 1047 MB / 999 MiB
2 P Linux 127 122 60 117139 90 7 1879795712
ext4 blocksize=4096 Large_file Sparse_SB Recover, 962 GB / 896 GiB

TestDisk exited normally.

moko138

Ce n'était pas "L" mais "P: list files" (=lister les éléments), je viens de corriger mon erreur du #9.
Tu le verras dans l'indispensable tutoriel de l'auteur du logiciel, en
https://www.cgsecurity.org/wiki/TestDisk_Etape_par_Etape
- -

Bravo pour le log retrouvé !
Bizarrement, je n'y vois pas de "write".

- -

penses tu que au moins pour une fois je peux rebrancher mon DDE pour faire une sauvegarde sur un autre?
J'ai à peu près 85% de récupéré

Le fsck peut être automatique, mais il est quasi systématique quand le système, ~~au moment de monter le système de fichiers, détecte un problème~~.
EDIT
Voir le 2ème message de jamesbad0000 ci-dessous.
FIN d'édit.

Donc non, ne fais pas de montage.

...Ou alors seulement en lecture seule. Ce qui implique :
- désactiver le montage auto (déjà dit)
- vérifier avec une banale clef usb, que c'est bien désactivé.
- s'exercer à monter (et démonter) la clef usb en lecture seule, genre

mkdir /tmp/test
sudo mount -v -t auto -o ro /dev/sdb1   /tmp/test

sudo umount -v /tmp/test

quand tu es prêt, clef démontée et débranchée,
brancher le DDE et, en remplaçant X par ce qui va bien, tenter

sudo mount -v -t auto -o ro /dev/sdX2   /tmp/test

sudo umount -v /tmp/test

mais si ça renâcle, n'insiste surtout pas !

moko138

Merci beaucoup, jamesbad000 !

jamesbad000

Bonsoir.

Pourrais tu préciser si ton opération interrompue comportait un déplacement de la partition ou un agrandissement par la gauche. (Ce qui dans les 2 cas implique un changement de la position de début !)
Et un ordre de grandeur du temps écoulé avant l'interruption.

Dans tous les cas je te conseille de cesser toute manipulation intempestive.
Merci de préciser également l'importance que tu attache aux données à récupérer

Tu donnera aussi, en connectant le disque concerné par l'incident après démarrage complet de linux) le retour de :

sudo lsblk -o size,name,fstype,label,mountpoint
ls -l /dev/disk/by-id

moko138 a écritLe fsck peut être automatique, mais il est quasi systématique quand le système, au moment de monter le système de fichiers, détecte un problème.

Jamais vu linux faire automatiquement un fsck en dehors du démarrage du système, et à condition que le disque soit répertorié dans fstab.

moko138

Oups ! Merci de la précision ! Je raye, plus haut.

herodote k210

Bonjour jamesbad000
donc pour te répondre et merci pour ta silicitude ainsi qu'à moko :

jamesbad000 a écritBonsoir.
Pourrais tu préciser si ton opération interrompue comportait un déplacement de la partition ou un agrandissement par la gauche. (Ce qui dans les 2 cas implique un changement de la position de début !)
Et un ordre de grandeur du temps écoulé avant l'interruption.

J' agrandissait vers la gauche ma partition, il y avait une partition vide de 37GO que voulais réserver à une distribution.

Le temps écoulé correspond à environ 50 mn et il ne restait que moins d'1h20.
Donc si je comprends bien et que je ne savais pas lors d'une extension de partition, les éléments sont déplacés bloc par bloc et quasi matériellement les éléments de fichiers qui sont en début, donc ce qui commencent par la lettre A sont déplacés en premier?

jamesbad000 a écrit Dans tous les cas je te conseille de cesser toute manipulation intempestive.
Merci de préciser également l'importance que tu attache aux données à récupérer

En fait ce qui m'importe le plus m'est accessible, en fait des heures de vidéos de grands magiciens cartes, pièces,... Et certaines sont rares. J'ai des livres récupérés par un peu tous les moyens.

J'ai récupéré par le write, qui n'apparaît pas environ 85%, il me manque un fichier "livre de magie" que j'ai en double et un fichier de 100 GO environ d'enregistrements de dwhelper des documentaire arte et france TV certains sont intéressants. Leur perte est tout de même secondaire.

jamesbad000 a écritB

moko138 a écritLe fsck peut être automatique, mais il est quasi systématique quand le système, au moment de monter le système de fichiers, détecte un problème.
Jamais vu linux faire automatiquement un fsck en dehors du démarrage du système, et à condition que le disque soit répertorié dans fstab.

Bizarrement dans l'écriture au début de ce DDE je n'ai pas obtenu un montage automatique, il est reconnu, mais il faut que je le monte à chaque fois.

jamesbad000 a écritBonsoir.
Tu donnera aussi, en connectant le disque concerné par l'incident après démarrage complet de linux) le retour de :

sudo lsblk -o size,name,fstype,label,mountpoint
ls -l /dev/disk/by-id

Le retour des commandes:

jean-marc@gargantua:~$ sudo lsblk -o size,name,fstype,label,mountpoint
  SIZE NAME   FSTYPE LABEL MOUNTPOINT
465,8G sda                 
  3,7G ├─sda1 swap         [SWAP]
 23,3G ├─sda2 ext4         /
 23,3G ├─sda3 ext4         
    1K ├─sda4              
415,5G └─sda5 ext4         /data
931,5G sdb                 
  999M ├─sdb1 swap         
896,4G └─sdb2 ext4         /media/jean-marc/a129a72a-2c70-4b0d-bade-4a6d122c621c
 1024M sr0                 
jean-marc@gargantua:~$

total 0
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-Optiarc_DVD_RW_AD-7200S -> ../../sr0
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-ST31000524NS_9WK42JP7 -> ../../sdb
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST31000524NS_9WK42JP7-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST31000524NS_9WK42JP7-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 nov.  19 16:59 ata-ST3500312CS_9VV78L92 -> ../../sda
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 nov.  19 16:59 ata-ST3500312CS_9VV78L92-part5 -> ../../sda5
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_Compact_Flash_20021111153705700-0:0 -> ../../sdc
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_MS_MS-Pro_20021111153705700-0:3 -> ../../sdf
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_SD_MMC_20021111153705700-0:2 -> ../../sde
lrwxrwxrwx 1 root root  9 nov.  19 16:59 usb-Generic-_SM_xD-Picture_20021111153705700-0:1 -> ../../sdd
lrwxrwxrwx 1 root root  9 nov.  19 16:59 wwn-0x5000c5002e28ae51 -> ../../sdb
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c5002e28ae51-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c5002e28ae51-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 nov.  19 16:59 wwn-0x5000c500363f4f2a -> ../../sda
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 nov.  19 16:59 wwn-0x5000c500363f4f2a-part5 -> ../../sda5

jamesbad000

Bonsoir.
Un déplacement ou tout mouvement de la position de début (agrandissement/rétrécissement par la gauche) est le cas le plus défavorable qui entraîne un déplacement de la totalité du système de fichier.

L'agrandissement par la droite lui n'implique pas de mouvement, et le rétrécissement par la droite n'impacte le déplacement que de ce qui est en dépassement.

Dans ton cas, le système de fichier se trouve coupé en 2. Il sera très compliqué de recoller les morceaux même si ce n'est pas impossible.

herodote k210 a écritles éléments de fichiers qui sont en début, donc ce qui commencent par la lettre A sont déplacés en premier?

L'ordre alphabétique est sans objet pour ce qui est de l'emplacement des segments de fichiers. Et le début d'un fichier peut être à la fin de la partition, alors même que la fin du fichier se trouve au début.
Ce qui prévaut c'est l'ordre d'arrivé et la place disponible. Même si ext4 fait tout de même des efforts pour que les différents segments d'un même fichiers se trouvent dans des régions proches (facile quand c'est vide. Impossible quand ça a été bien remplie, et qu'on supprime en ne laissant que des petits trous un peu partout)

A noter que dans ta situation, il est hautement probable que certains fichiers récupérés soient ~~totalement~~ corrompus (un inode, déplacé qui référence un segment de fichier à +10Go du nouveau début de partition alors que celui-ci est encore à + 10Go de l'ancien début de partition par exemple)

Maintenant la question est : serais tu prêt à passer des heures sur plusieurs jours pour tenter de récupérer ce qui manque, sans être certain qu'on y arrivera ?

herodote k210

Oui!
Déjà stabiliser et dé- corrompre puis sauvegarder ce que j'ai et aussi retrouver ce que j'ai perdu.

jamesbad000

Bah ca va être un tout.
La difficulté étant de trouver ou se trouvent la borne de fin du morceau de gauche, et la borne de début du morceau de droite. La suite n'est qu'une affaire de technique comme disent les grands maîtres aux échecs...

Si tu avais dans un coin un résultat de fdisk ou parted faisant apparaitre l'ancien partitionnement de ton disque ça pourrait aider (j'ai cherché dans tes post, et trouvé un rapport boot info, mais il n'y avait pas ton disque externe dedans)

Petite collecte d'info pour commencer

sudo lsb_release -a
sudo uname -a
mke2fs -V
sudo fdisk -l /dev/disk/by-id/wwn-0x5000c5002e28ae51
sudo dumpe2fs -h /dev/disk/by-id/wwn-0x5000c5002e28ae51-part2

Page suivante »