Vous n'êtes pas identifié(e).
Dernière modification par phux (10-01-2021 10:39:54)
Hors ligne
Dernière modification par otyugh (05-01-2021 10:36:06)
Hors ligne
Je connais ddrescue
Il ne fait que copier les données brutes encore présentes. Sans intérêt ici.
Si ça m'arrivait, je considèrerait que "c'est mort", et que photoreq
Mais non, si ce n'est pas un SSD ultra-rapide en écriture il y a de bonnes chances qu'en quelques secondes moins de 10 Go aient été écrasés.
J'avais toujours accès au trois partitions et à leurs fichiers tant que le PC était en route, seuls des fichiers de la partition 1 avaient disparus.
Au redémarrage, patatras, plus aucune des partitions du HDD n'est accessible, sans doute parce que le MBR du disque a été écrasé.
Evidemment. Redémarrer était l'erreur à ne pas commettre, car le noyau avait encore en mémoire les positions et tailles des partitions.
J'ai entendu parler de fsck, testdisk et j'ai utilisé photorec par le passé. Un de ces outils serait-il plus approprié ?
fsck vérifie/répare un système de fichiers. Rien à voir avec les partitions.
photorec récupère le contenu des fichiers non fragmentés de type connu. Résultat aléatoire, à utiliser en dernier recours.
testdisk sert à retrouver les partitions perdues, donc oui. Mais je n'aime pas sa façon de présenter qui utilise les coordonnées CHS obsolètes au lieu de l'adressage LBA. En tout cas je ne le laisse pas écrire sur le disque, je teste ses propositions moi-même avec addpart.
Un autre programme qui sert aussi à retrouver les partitions perdues est gpart (à ne pas confondre avec gdisk ou gparted), mais je ne l'ai jamais utilisé.
Note : si la table de partition est au format GPT, il y a une table de secours à la fin du disque, que des outils comme gdisk peuvent utiliser pour restaurer la table principale.
GPT c'est bon, mangez-en.
Il vaut mieux montrer que raconter.
Hors ligne
Si ça m'arrivait, je considèrerait que "c'est mort", et que photoreq ne permettera que de récuperer quelques fichiers dans une bouillie apocalyptique de fichier système.
Ben non, j'ai la foi, parce que c'est linux, que des générations entières de bidouilleurs ont fait la même c...nnerie avant moi, et que certains ont trouvé des solutions et développé les outils qui vont bien.
Sinon autant rester sous Windows, et réinstaller son système à chaque fois que ça plante.
Un autre programme qui sert aussi à retrouver les partitions perdues est gpart (à ne pas confondre avec gdisk ou gparted), mais je ne l'ai jamais utilisé.
Note : si la table de partition est au format GPT, il y a une table de secours à la fin du disque, que des outils comme gdisk peuvent utiliser pour restaurer la table principale.
J'ai lancé gpart.... Ça mouline sec, mais avec un téra, va falloir être patient. Voici ce que ça donne pour l'intant :
J'ai aussi passé parted pour voir si mon second disque est en GPT, mais pas de résultat sur sdb :
Je vais tenter gdisk dès que gpart aura terminé.
Dernière modification par phux (05-01-2021 16:56:02)
Hors ligne
Gpart is a tool which tries to guess the primary partition table of a PC-type hard disk in case the primary partition table in sector 0 is damaged, incorrect or deleted. The guessed table can be written to a file or device. Supported (guessable) filesystem or partition types:
DOS/Windows FAT (FAT 12/16/32)
Linux ext2
Linux swap partitions versions 0 and 1 (Linux >= v2.2.X)
OS/2 HPFS
Windows NTFS
*BSD disklabels
Solaris/x86 disklabels
Minix FS
Reiser FS
Linux LVM physical volume module (LVM by Heinz Mauelshagen)
Dernière modification par phux (05-01-2021 16:02:09)
Hors ligne
Possible partition(Windows NT/W2K FS), size(9999mb), offset(10000mb)
gpart a trouvé une information qui peut être associée à une partition NTFS de la bonne taille, mais pas à la bonne place. C'est peut-être un superbloc de secours situé à la fin de la partition. En tout cas c'est un signe que l'écrasement n'est pas allé au-delà de la partition NTFS. Et comme par défaut gpart saute les secteurs de la supposée partition, il ne trouvera pas la partition ext4 suivante. Pour éviter cela il faudrait spécifier "-f". D'autre part d'après la page de manuel par défaut gpart scanne tête par tête (-n h), ce qui n'est pas adapté au partitionnement actuel basé sur des blocs de 2048 secteurs. Donc spécifier soit "-n s" pour scanner tous les secteurs (long), soit "-n 2048" pour scanner par bloc.
Dernière modification par raleur (05-01-2021 16:07:59)
Il vaut mieux montrer que raconter.
Hors ligne
sais-tu si gpart détecte les partitions ext4 ? J'ai un doute quand je lis le manuel.
ext4 est une évolution de ext2, donc il y a des chance que oui.
Il vaut mieux montrer que raconter.
Hors ligne
Comme tu l'avais prédit, gpart a "sauté" la fin de la partition ntfs, et semble avoir trouvé la troisième partition.
J'avais partitionné comme suit :
ntfs = 10 Go -> la première partition, bousillée par ma bévue (size 0, offset 3347)
ext4 = 100 Go -> ce doit être la partition détectée à l'offset 10001, et cataloguée en ntfs. Soit gpart a sauté des secteurs, soit l'écriture a aussi bousillé le début de cette partition.
ext4 = le solde de l'espace disque -> je la retrouve à l'offset 110001 Mo.
Et comme par défaut gpart saute les secteurs de la supposée partition, il ne trouvera pas la partition ext4 suivante. Pour éviter cela il faudrait spécifier "-f". D'autre part d'après la page de manuel par défaut gpart scanne tête par tête (-n h), ce qui n'est pas adapté au partitionnement actuel basé sur des blocs de 2048 secteurs. Donc spécifier soit "-n s" pour scanner tous les secteurs (long), soit "-n 2048" pour scanner par bloc.
Pourquoi -n 2048 ? parted indique :
D'où vient cette valeur de 2048 secteurs / bloc ?
Allez hop, c'est reparti pour un scan ...
Hors ligne
Pourquoi -n 2048 ? parted indique :
Sector size (logical/physical): 512B/4096B
Ce n'est pas la taille de secteur mais l'alignement des partitions.
D'où vient cette valeur de 2048 secteurs / bloc ?
C'est l'alignemement par défaut appliqué par les outils de partitionnement actuel parce qu'il convient aux disques durs au format avancé comme celui-ci (secteurs physiques de 4096 octets et secteurs logiques de 512 octets) et aux SSD (taille de bloc d'effacement pouvant aller jusqu'à 1 Mio, soit 2048 secteurs logiques de 512 octets).
Pour trouver le début de la deuxième partition, il faut recommencer avec "-f -n 2048" (pour aller plus vite en supposant un alignement de 1Mio) ou "-f -n s" pour scanner tous les secteurs. On peut arrêter quand la 1e partition ext4 est trouvée.
L'ennui avec les informations fournies par gpart, c'est qu'elles sont précises à 1 Mio près. Même en supposant un alignement à 1 Mio, ça fait encore trois possibilités.
Il vaut mieux montrer que raconter.
Hors ligne
phux a écrit :J'avais toujours accès au trois partitions et à leurs fichiers tant que le PC était en route, seuls des fichiers de la partition 1 avaient disparus.
Au redémarrage, patatras, plus aucune des partitions du HDD n'est accessible, sans doute parce que le MBR du disque a été écrasé.Evidemment. Redémarrer était l'erreur à ne pas commettre, car le noyau avait encore en mémoire les positions et tailles des partitions.
Et qu'aurait-il donc fallu faire ?
Merci d'éclairer nos lanternes car cette blague peut arriver à tout le monde.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Hors ligne
Et qu'aurait-il donc fallu faire ?
Soit faire une sauvegarde du contenu des partitions tant qu'il était encore accessible.
Soit récupérer les positions et tailles des partitions dans /sys/block/sdb/sdb[1-3]/ (de mémoire, je n'ai pas de Linux sous la main pour vérifier) afin de recréer facilement une table de partition.
Dernière modification par raleur (05-01-2021 18:06:08)
Il vaut mieux montrer que raconter.
Hors ligne
Soit récupérer les positions et tailles des partitions dans /sys/block/sdb/sdb[1-3]/ (de mémoire, je n'ai pas de Linux sous la main pour vérifier)
Si si, c'est bien ça.
afin de recréer facilement une table de partition.
À grands coups de sfdisk ou similaire, et ça aurait ressuscité les fichiers disparus ? Désolé de poser des questions aussi naïves mais comme cette mésaventure ne m'est jamais arrivée, je n'ai jamais eu à tenter une recovery à l'arrache.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
À grands coups de sfdisk ou similaire, et ça aurait ressuscité les fichiers disparus ?
Ça aurait recréé les partitions avec leur contenu restant, mais pas restauré les fichiers écrasés de la première partition.
Il vaut mieux montrer que raconter.
Hors ligne
Ça aurait recréé les partitions avec leur contenu restant,
Ok.
mais pas restauré les fichiers écrasés de la première partition.
Ça va sans dire,
Difficile de régénérer un livre de ses cendres une fois qu'il a brûlé.
Merci pour les précisions.
AMD Ryzen3 3200G sur Gigabyte B450M & Make Love Not War
Hors ligne
Et qu'aurait-il donc fallu faire ?
Je pensais n'avoir perdu que la première partition puisque j'accédais aux deux suivantes et que les fichiers paraissaient ok. L'erreur a été d'arrêter le système sans réaliser que la table de partitionnement du disque avait été touchée. J'aurais dû transférer immédiatement tous les fichiers sur un disque de sauvegarde alors qu'ils étaient encore accessibles.
Dernière modification par phux (05-01-2021 19:26:16)
Hors ligne
Je tente un gpart -f simple cette nuit.
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Cette fois-ci, j'ai bien repéré la partition de 100 Go, puis celle de 843 Go. Je laisse le scan se terminer pour avoir toutes les infos de gpart. Quelle est l'étape suivante ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
et ô miracle :
Idem pour la partition suivante :
Pour ma formation, je ne comprends pas la fin de la ligne de commande "file -". Que fait le - ? Et pourquoi la commande renvoie "4+0 enregistrements écrits", alors que je ne lui ai pas indiqué de fichier cible ?
Bien, maintenant que j'ai confirmation que les deux partitions sont intactes et que j'ai isolé leur emplacement, comment est-ce que je localise au secteur près ?
Je sais que la partition 2 démarre quelque part après le bloc 10001*2048. En tatonnant avec les paramètres, j'ai trouvé
alors que count=1 et count=2 renvoient "data". Et je ne connais pas la taille d'un bloc, fdisk -l ne me renseigne que sur le disque SSD en sda.
Dernière modification par phux (07-01-2021 22:11:40)
Hors ligne
. Mais ça ne fonctionne pas.
Hors ligne
je ne comprends pas la fin de la ligne de commande "file -". Que fait le - ?
Il dit à file de lire son entrée standard (/dev/stdin) au lieu d'un fichier ou un périphérique.
Et pourquoi la commande renvoie "4+0 enregistrements écrits", alors que je ne lui ai pas indiqué de fichier cible ?
C'est dd qui écrit cette information sur sa sortie d'erreur (/dev/stderr). Si on n'indique pas de fichier de sortie avec of=, dd écrit les données sur sa sortie standard (/dev/stdout), qui est redirigée vers l'entrée standard de file par l'opérateur | ("tube", "pipe").
Je sais que la partition 2 démarre quelque part après le bloc 10001*2048
Pas "quelque part après" mais exactement à cette position. Le nombre de blocs lus ne sert qu'à fournir assez de données pour que file puisse identifier un superbloc ext4.
Et je ne connais pas la taille d'un bloc, fdisk -l ne me renseigne que sur le disque SSD en sda.
Mais si :
C'est la taille de secteur logique qui nous intéresse, 512 octets, qui est aussi la taille de bloc par défaut de dd. La taille de secteur physique n'est utile que pour l'optimisation des performances, notamment au travers de l'alignement des partitions et de la taille de bloc pour les entrées-sorties et les systèmes de fichiers.
Reste à définir précisément la taille ou la position de fin des partitions. Le plus simple est de prendre en première approximation, pour la première, le secteur précédent le secteur de début de la seconde, et pour la seconde, le dernier secteur du disque (ou 34 secteurs avant pour laisser la place à la table de partition de secours si on veut le format GPT). Ou bien on peut déterminer la taille de la partition via la taille du système de fichiers avec la commande tune2fs ou dumpe2fs. Ces commandes ne peuvent pas lire sur l'entrée standard, donc il leur faut un fichier ou un périphérique.
Le fichier peut être créé avec dd :
Le périphérique peut être créé avec losetup :
ou avec addpart (qui déclare une partition sans l'écrire) :
Il ne reste plus qu'à calculer la taille en secteurs de la partition : block count * block size / 512
Dernière modification par raleur (09-01-2021 12:04:42)
Il vaut mieux montrer que raconter.
Hors ligne