Erreur de manip lors d'un dd, besoin de restaurer un HD ext

Support Debian
#1

Bonjour à tous,

J’ai fait une erreur de manipulation sur un périphérique et je cherche le moyen de corriger.

Mon objectif était de copier un iso debian sur une clé usb, ici /dev/sdd,
mais je me suis trompé et l’ai dirigé à la place, vers /dev/sdc, un HD externe.
400MB ont été copiés avant que je m’en rende compte et stoppe l’opération.

J’ai utilisé cette commande :

# dd if=debian-testing-i386-lxde-CD-1.iso of=/dev/sdc oflag=direct bs=1048576 (donc au lieu de /dev/sdd)
Maintenant le HD externe connecté n’apparaît qu’avec un # blkid pour ne montrer que :

Que puis-je faire pour en récupérer le contenu et le réabiliter dans son utilisation initiale (ce HD n’est pas à moi) ?
N’étant pas sûr de moi, je ne veux pas faire d’autres bourdes !

#2

C’est mal barré. Je suppose que le disque était partitionné avec une seule partition. Dans ce cas tu as écrasé la table de partition (pas très grave) et le début du système de fichiers de la partition (plus gênant).

Première chose à faire : effacer le MBR du disque, sinon les outils de récupération vont voir que le disque contient une image ISO et s’arrêter là.

Si tu connais le partitionnement exact de ton disque au secteur près, tu peux ensuite le recréer à l’identique. L’outil idéal pour cela est sfdisk mais il n’est pas d’un maniement facile. Attention, les différents outils de partitionnement ne positionnent pas tous les partitions de la même façon : par exemple les “anciens” (fdisk et cfdisk traditionnels) réservent 63 secteurs avant la première partition, les “nouveaux” (parted, gparted, GNU fdisk/cfdisk basés sur libparted) réservent 2048 secteurs, valeur plus adaptée aux disques SSD ou “advanced format” (avec des secteurs physiques de 4096 octets).

Les outils :

  • gpart : essaie de retrouver la table de partition effacée. Mais comme le début de la partition est aussi effacé, je ne sais pas s’il fonctionnera.
  • testdisk : essaie de retrouver les partitions perdues. Même réserve que pour gpart.
  • photorec (inclus dans le paquet testdisk) : essaie de retrouver le contenu des fichiers de données de diveres types connus (images, archives, PDF…). En revanche cela ne retrouve pas le nom des fichiers récupérés.
  • fsck : vérifie et répare un système de fichiers. Le superbloc principal qui est au début de la partition a été écrasé, mais il peut être restauré grâce aux copies qui se trouvent plus loin. Cependant d’autres structures ont probablement été écrasées (table d’inodes, répertoire racine…) sans parler des fichiers qui étaient situés dans la partie écrasée, et des données seront perdues même si fsck parvient à réparer le système de fichiers.

S’il y a des données importantes, je commencerais avec photorec pour copier sur un autre disque tout ce qui est récupérable.
Bon courage.

#3

PHOTOREC ! Je l’avais oublié celui-là.
Merci pour ta réponse rapide. Je m’y atèle cette après-midi, et reviens pour le feed back.
Heureusement, ce ne sont pas des données vitales, mais le manque de ces données peut générer une grosse dispute :mrgreen: donc si je peux éviter de me faire servir du “linux c’est nul, et t’avais qu’à pas y toucher” et j’en passe, je vais faire au mieux.

Donc en substance, j’efface le MBR, puis avec Photorec récupére les données dans un SSD assez grand que j’ai sous le coude, et je refais une table de partitions propre.
À toute !

#4

J’ai donc commencé par un :

dd if=/dev/zero of=/dev/sdc count=1 bs=512mais je pense que ça n’a pas fait grand chose : le volume est toujours reconnu comme un iso debian.

J’ai fait ensuite un testdisk pour voir ce qu’il détectait. Il ne trouve que des fichiers concernant l’iso.

Enfin, j’ai installé gpart et suivi ce tuto, je n’ai fait qu’un # gpart /dev/sdb dont voici le résultat : [code]# gpart /dev/sdb
Begin scan…
End scan.

Checking partitions…
Ok.

Guessed primary partition table:
Primary partition(1)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(2)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
type: 000(0x00)(unused)
size: 0mb #s(0) s(0-0)
chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r
[/code]
Avant de paniquer (car “il faut tout récupérer parce que tout est important”, qu’on me précise avec beaucoup d’insistance), il doit y avoir d’autres choses à faire.
Déjà, il devrait déjà au moins trouver quelque chose concernant l’iso.
Ensuite est-ce que la première étape a été bien appliquée avec l’effacement du MBR, sachant que l’iso Debian se monte toujours ?

Point de détail notable que j’ai omis : il s’agit d’un disque dur de 500GB dans boîtier Iomega avec une partition virtuelle reconnue en /dev/sr0 qui se monte automatiquement, et encore après ces manipulations. Elle contient le logiciel de chiffrage Iomega sensé pouvoir être lancé sous Win.
Celui-ci se monte toujours et tourne toujours automatiquement.

#5

Déjà, un point à éclaircir : le disque externe est sdb ou sdc ?
La commande que j’ai indiquée efface le MBR de sdc, mais si le disque externe est sdb alors elle a effacé le MBR d’un autre disque…

#6

Ah non. La première chose à faire aurait été de prendre un disque dur au moins aussi grand que celui à récupérer, puis copier l’intégralité du disque dur endommagé vers ce 2ème disque dans un fichier quelconque avec la commande “dd” qui va bien (sans se tromper cette fois, hein ? :smiley: ). Comme ça après il peut bidouiller tout ce qu’il veut sur le disque dur endommagé, il peut toujours restaurer le contenu d’origine si jamais il détruit encore plus de données que ce qui est déjà détruit.

Croyez-en mon expérience…

#7

C’est vrai que cette mésaventure ne me donne pas crédit par rapport à l’identification des périphériques, mais il s’agissait bien d’avoir saisi trop vite.
Donc dans les tests que j’ai fait, j’ai bien fait attention sur quel périphériques je travaillais… cette fois…

L’ordre des périphériques a été modifié par les reboot et retraits des appareils.

#8

Voilà pourquoi il faut travailler avec l’UUID ou le label si on ne veut pas prendre la peine d’identifier à chaque fois l’ordre des périphériques.

#9

L’UUID et le label n’identifient pas un disque mais un système de fichiers ou un swap. Ils sont essentiellement utilisés dans fstab. On ne peut pas les utiliser pour spécifier la destination d’une image ISO, cela n’aurait donc pas évité l’erreur à l’origine de cette discussion.

#10

J’ai refait un gpart sur le disque dur concerné (c’est assez long), il me sort le même résultat. Cependant, comme j’ai déjà précisé, le fait qu’il se monte toujours ne iso Debian, il semble qu’il ne reconnaisse rien, comme tu le précisais, tant que le MBR n’a pas été effacé, c’est ça ?

J’ai pourtant bien fait la commande (sur le bon périphérique), en root et en user, mais ça n’a l’air d’avoir fait quelque chose.

#11

Que gpart ne détecte rien pousse à imaginer que le disque d’origine puisse être de type GPT.
Gpart n’est pas capable de détecter l’ancien partitionnement hors de son rayon : les disques de type MBR.

$ man gpart

[quote]
GPART(8) System Manager’s Manual GPART(8)

NAME
gpart - guess PC-type hard disk partitions [/quote]
Autre point à considérer, gpart ne détectera pas les partitions étendues des disques à MBR.

Essaye avec le type GPT en testdisk.
cgsecurity.org/mw/images/Par … e_type.gif

cgsecurity.org/wiki/TestDisk_Etape_par_Etape
Est-ce que tu as poussé la détection par testdisk au delà de la prime apparence ?
Ne pas s’arrêter à la première détection de testdisk : insister, “deeper search”.
Si tu ne pousses pas la détection plus avant, il est normal que seul le partitionnement de saboteur apparaisse. L’ancien partitionnement est enfoui à cause de ta bêtise …
Le tarif est le même en effaçant le mauvais MBR à coup de
dd if=/dev/zero of=/dev/sdc count=1 bs=512
Un MBR à zéro ne rétablira pas l’ancien partitionnement, il faudra aller le chercher au fond de la soute …

#12

Je suis en train de lancer un testdisk, en précisant l’option GPT, et non NTFS.

Disk /dev/sdb - 499 GB / 465 GiB - CHS 60712 255 63 Bad root cluster check_FAT: Unusual media descriptor (0xf0!=0xf8) Warning: Incorrect number of heads/cylinder 2 (FAT) !=255 (HD) Warning: Incorrect number of sectors per tracks 18 (FAT) !=63 (HD)
Je le laisse continuer ?

#13

Continue, ça n’engage à rien . Tu ne te seras engagé que lorsque tu écriras le résultat de la détection.
La question te sera posée pour accepter d’écrire les résultats de la détection sur le disque. Puisque la géométrie semble coincer
tu y répondras NO pour l’instant et lanceras une détection en spécifiant le type de disque MBR, alias “intel” sous testdisk en poussant la recherche.
Tu répondras YES à l’écriture lorsque tu seras certain de ton coup.
Comment être certain de son coup ?
Avoir une idée assez précise de l’ancien partitionnement. Par exemple, il y avait cinq partitions, la première était une partition ext4, la seconde hfs+ …
Rassemble tes souvenirs, nous ne te serons d’aucun secours pour savoir comment était agencé le disque.
Après avoir trouvé trace des anciennes partitions, testdisk permet de lister les fichiers pour vérifier le contenu.
cgsecurity.org/mw/images/First_results.gif
P : list files

[quote]
Mettre en surbrillance cette partition et presser la touche p pour lister les fichiers (Utiliser q pour quitter et retourner à cet écran).[/quote]
Si tu te rappelles qu’il y avait un dossier appelé “XXX” contenant le fichier “YYY” et qu’ ils apparaissent, répondre YES à l’écriture sera envisageable …

#14

J’en suis à 75% du scan par testdisk avec option GPT.
Pour l’heure il ne trouve rien…

Pour ce qui est des partitions, il n’y avait qu’une partition en FAT32, avec des fichiers video et photo (souvenirs chers à la propriétaire). Pour plus de détails, je ne peux que me souvenir vaguement de l’agencement des dossiers, n’y passant pas tout mon temps dessus, mai je vois à peu près.
Il y a en plus cette fameuse partition “virtuelle” non détruite, avec l’outil de chiffrage de Iomega.

Je relancerai donc demain le scan avec MBR, mais je pense qu’il ne trouvera que les données de l’iso Debian.

#15

Dans ce cas il faut peut-être augmenter l’option bs à 2048, qui est la taille d’un secteur de CD/DVD. Voir augmenter le nombre de blocs, si les informations d’identification ne se trouvent pas que sur le premier secteur. De toute façon tant que tu n’écris pas au-delà des 400 Mo déjà écrasés, tu ne risques rien.

#16

Jusqu’à quelles valeurs je peux aller sans risque ?
J’ai tenté : sudo dd if=/dev/zero of=/dev/sdc count=2 bs=2048 et sudo dd if=/dev/zero of=/dev/sdc count=2 bs=4096mais l’iso se monte toujours.
L’objectif ici est bien d’effacer le mbr de l’iso pour permettre un scan non influencé par cet iso, c’est bien ça ?

#17

Jusqu’à la limite de ce qui a été écrasé. Tu as dit 400 Mo, soit 195000 blocs de 2048 octets. Mais il n’est probablement pas nécessaire d’aller si loin. Je viens de lire que les 32768 premiers octets sont inutilisés par le format ISO 9660 et suivis par les descripteurs de volume du CD de 2048 octets chacun (minimum 2 pour un CD de données ISO 9660). Effacer 65536 octets devrait suffire.

#18

440MB en fait. Mais puisque tu précises que 65536 octets suffisent, cela ne fait pas de différence.

Avant d’aller plus loin, je voulais pouvoir faire une copie du disque dur, or je me rends compte que je n’en ai pas d’autre à disposition.

#19

Bon !
J’ai finalement obtenu un disque dur de 2TB et je m’en suis sorti !
Voici ce que j’ai fait :
j’ai donc d’abord fait un backup :# dd=if/dev/sdb of=/media/2TB/500GB.img bs=1M count=500000Avec le disque à récupérer connecté sur /dev/sdb.

J’ai ensuite lancé un premier photorec, mais il ne m’a copié que les fichiers de l’iso, comme le premier test avec testdisk.

J’ai alors créé une table de partition msdos avec fdisk, puis appliqué photorec encore, et cette fois, ça a bien marché ! 13h de récup, et tout est là. Du moins je pense la plus grande partie. La propriétaire du disque passe en revue les données, mais nous sommes satisfait.

En tout cas, je peux considérer le problème résolu. En vous remerciant tous pour votre aide.

Edit : J’ai créé un autre post concernant le traitement et le tri de ces données.