récupération de la partition ext4 après avoir effectué le démarrage de la HD

J'ai accidentellement utilisé ddet écrit sur les premiers 208 Mo de mon disque externe. Ce que j'ai écrit est une partition à part entière (Debian nestinstaller) donc ce que je vois maintenant n'est pas mon ancienne partition ext4 (maintenant endommagée) mais une autre plus petite partition. Cela limite les outils et les conseils que je pourrais suivre.

Mon plan était de recréer la table de partition avec testdiskpuis de tout réparer avec les superblocs de sauvegarde comme décrit ici . Je perdrais les premiers 208 Mo, mais c'est correct par rapport aux 300 autres Go de données. Quelque chose comme ceci:

mke2fs -n /dev/sdb1   # doesn't work because sdb1 is the 208MB new partition
testdisk ...          # used this to create new correct partition table
mke2fs -n /dev/sdb1   # now works fine, get backup superblock positions
e2fsck -b backup_position -y /dev/sdb1 # returns many errors hence the -y

Cependant, je n'ai rien pu récupérer. J'avais l'habitude testdiskd'écrire une nouvelle table de partition qui correspondait à ce que j'avais avant. Lorsque j'exécute e2fsck, j'obtiens de nombreuses erreurs différentes. Je reçois un système de fichiers après cela, mais il est complètement vide, pas de fichiers.

Le répertoire lost + found est plein de fichiers (ceux récupérés je pense) mais j'ai besoin de récupérer l'arborescence des répertoires, pas seulement les fichiers. J'ai besoin du nom de fichier et des répertoires précédents pour savoir quels sont les fichiers (images de microscope, données de masse, etc. Sans les noms et les répertoires où ils étaient, ils ne veulent rien dire).

J'ai obtenu un autre HD exactement le même et j'ai fait une copie de tout le HD avec ddafin que je puisse expérimenter la récupération sans rien perdre. Aucun conseil?

J'ai finalement réussi à résoudre ce problème. Juste pour mémoire, voici comment je l'ai fait. Une partie de la solution que j'ai trouvée ici et qui implique de connaître les paramètres utilisés pour créer le système de fichiers (j'étais presque sûr de ne pas avoir modifié les valeurs par défaut).

Fondamentalement, j'ai d'abord dû fixer la table de partition pour refléter ce que j'avais réellement là-bas (j'ai utilisé testdiskpour cela mais parted, cfdiskou fdiskdevrait bien fonctionner aussi). Je viens de supprimer les mauvaises partitions et de les remplacer par une seule partition de type ext4 couvrant tout le disque avec les valeurs CHS correctes.

Le reste provient principalement du lien au début (lisez-le pour plus de détails) mais en gros j'ai couru mke2fs -n /dev/xxxpour trouver les positions pour la sauvegarde des superblocs. Ensuite, utilisé la dernière sauvegarde la plus proche de la fin du disque (seules celles au début du disque ont été écrasées avec dd) pour exécuter fsck. Cela a généré beaucoup d'erreurs mais fsck a une -yoption (pas la même que -a).

$ sudo e2fsck -a -b backup_block_number /dev/xxx

Je pensais que cela n'avait pas fonctionné car je ne pouvais voir aucun fichier, mais en fait, ils avaient tous été enregistrés dans le lost+foundrépertoire.

Donc, à la fin, j'ai récupéré la plupart de mes fichiers tout en conservant leurs noms de fichiers et leur structure de répertoires. J'espère que cela pourra aider les autres à l'avenir.

Ok, cela fonctionne pour la récupération à partir d'un lecteur accidentellement inité dans une baie MegaRAID. Mon contrôleur RAID a activé TOUS les disques du RAID, pas seulement ceux de la matrice RAID6 que je refaisais. Aie! Au moins, j'ai fait un démarrage rapide, et non pas un démarrage lent - le démarrage lent efface le lecteur à zéro.

L'initialisation rapide efface 10M au début et à la fin des disques. Donc, moi avec une partition ext4 sur tout le disque (sous Linux) et un disque, RAID0, j'ai eu une chance. Avec le disque étant un disque de 6 To, et presque 5 To dessus, je transpirais - c'était ma sauvegarde de la matrice RAID6 que je reformais!

Soit dit en passant, je n'ai pas dérapé - le LSI MegaRAID ne devrait PAS avoir démarré les lecteurs de mon autre groupe de lecteurs - mais il l'a fait. En tant que note, ce que j'aurais dû faire est de SUPPRIMER CE LECTEUR DE L'ENCEINTE et de le réimporter APRÈS avoir eu le groupe de disques RAID6 nouvellement organisé. Que je suis bête. VRAIMENT idiot de moi ....

OK, heureusement, le LSI MegaRaid n'a rien d'extraordinaire avec les disques RAID0 (s'il y en a un, je ne suis pas sûr de plusieurs). Voici ce que j'ai fait pour le réparer. OS = Fedora F22. Drive = une grande partition ext4, faite avec parted. J'ai d'abord cliché le lecteur sur un tout nouveau lecteur du même modèle, sur un serveur de rechange avec quelques emplacements de baie de rechange :: Dix heures plus tard, il a terminé ......

$ dd if=/dev/sdb of=/dev/sdc bs=64M conv=notrunc
89424+1 records in
89424+1 records out
6001175126016 bytes (6.0 TB) copied, 35130.2 s, 171 MB/s

C'était ma sauvegarde en or.

REMARQUE - Mon disque était /dev/sdb- vous devez régler votre disque sur le disque que vous essayez de récupérer. Ne gâchez pas les disques, sinon vous serez encore plus dans le pétrin ...

Ensuite, cela fait, j'ai fait ce qui suit.

(1) supprimer l'instantané de la machine (pas idiot encore, je peux vous assurer - que l'un serait hors de l'hôpital de récupération de disque si j'échouais, alors que je me suis enregistré dans l'urgence locale!).

(2) redémarrez la machine FC22 avec le lecteur. Exécutez parted, refaites la partition (dans mon cas, supprimez celle corrompue, écrivez une nouvelle partition ext4 de 0% à 100%). Vous DEVEZ savoir exactement où se trouvaient les partitions d'origine et leur type exact - l'étape suivante en dépend - sinon, ARRÊTEZ ICI. Vous n'y arriverez pas. utiliser testdisket / photorecou similaire, ou pour un gros disque où cela compte vraiment, expédiez-le.

(3) courir mke2fs -n /dev/sdb1(n'oubliez pas le -n, ou encore vous pouvez simplement vous éloigner ...)

Pour moi, le résultat ressemblait à:

$ mke2fs -n /dev/sdb1
$ mke2fs 1.42.13 (17-May-2015)
Creating filesystem with 1464843008 4k blocks and 183107584 inodes
Filesystem UUID: 1ac318a6-7953-42d5-8d7b-0597c54e1935
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
        4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
        102400000, 214990848, 512000000, 550731776, 644972544

Voilà, c'est là que se trouvent tous les superblocs de rechange ... Nous savons que le premier et le dernier sont des déchets, mais ceux du milieu devraient être OK. (Remarque, vous pouvez mkfs.ext4 -n /dev/sdb1être très prudent et obtenir le même résultat).

(4) Courez e2fsck -y -b 102400000 /dev/sdb1. Vous en aurez besoin -y, car il y aura beaucoup de "oui" nécessaires pour réparer le désordre créé par l'extrémité avant manquante du disque .... et choisissez n'importe quel superbloc au milieu que vous aimez ... et après environ 30 minutes de silence (utilisez un autre terminal et "top" pour regarder la progression, ou la lumière du disque clignotant) dans mon cas presto, une partition montable, et à peu près tout le reste intact dans le /lost+foundrépertoire.

Quoi qu'il en soit, j'espère que cela vous aidera - si vous lisez attentivement ce document, je vous souhaite bonne chance. Et merci aux gars qui écrivent ci-dessus. Tu m'as sauvé d'une fin vraiment écoeurante .....