Je suppose que la table de partition et la partition de démarrage peuvent être recréées facilement, je vais donc me concentrer sur la partition ext4.
La disposition du système de fichiers dépend quelque peu des options utilisées lors de sa création. Je vais décrire le cas courant. Vous pouvez voir si cela correspond au vôtre en exécutant dumpe2fs sur l'appareil (qui, espérons-le, trouvera toutes les métadonnées de niveau supérieur dans le cache plutôt que de lire à partir du disque).
La taille de bloc normale pour les systèmes de fichiers ext4 est de 4096 octets, vous avez donc perdu 1024 blocs.
La première chose écrasée était le bloc 0, le superbloc principal. Ce n'est pas un problème en soi, car il existe des superblocs de sauvegarde. Vient ensuite la table des descripteurs de groupe, qui contient également des sauvegardes dans le système de fichiers.
Ensuite, il y a les bitmaps de bloc et les bitmaps d'inode. C'est là que les nouvelles commencent à s'aggraver légèrement. Si l'un d'entre eux se trouve sous le bloc 1024, ce qui est probablement le cas, vous avez perdu des informations sur les inodes et les blocs utilisés. Ces informations sont redondantes et seront reconstruites par fsck en fonction de ce qu'il trouvera dans tous les répertoires et inodes, si ceux-ci sont intacts.
Mais la prochaine chose est la table des inodes, et ici vous avez probablement perdu beaucoup d'inodes, y compris le répertoire racine, le journal et d'autres inodes spéciaux. Ce sera bien de les avoir de retour. De toute évidence, le répertoire racine au moins est toujours fonctionnel, ou à peu près toutes les commandes que vous essayez d'exécuter échoueraient déjà.
Si vous exécutez un dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 maintenant, vous obtiendrez une copie de sauvegarde de tout ce qui se trouve actuellement dans votre cache, mélangé avec les mauvaises données pour les blocs qui ne sont pas mis en cache. Ensuite, après avoir démarré un disque de secours, vous pouvez faire la même chose dd à l'inverse, pour remettre ces données partiellement bonnes sur le disque, en écrasant les mauvaises choses qui s'y trouvent maintenant.
Après cela, vous pourriez trouver des outils de récupération automatisés (fsck , testdisk ) fonctionnent assez bien. Si ce n'est pas le cas, vous disposez d'une carte que vous pouvez utiliser pour faciliter la récupération manuelle. Utilisation des listes de "blocage libre" de dumpe2fs , vous savez quels blocs ignorer.
La plupart de ce que vous avez perdu est probablement des inodes. Il est en fait assez probable que vous n'ayez aucun fichier contenu dans les 4 premiers Mo du disque. (J'ai couru mkfs.ext4 sans options sur un fichier image de 1 To, et le premier bloc sans métadonnées s'est avéré être le bloc 9249)
Chaque inode que vous parvenez à récupérer identifiera les blocs de données d'un fichier entier. Et ces blocs de données peuvent être situés partout sur le disque, pas nécessairement à proximité.
Jour 2
Le dump posté sur pastebin révèle une excellente nouvelle :
Group 0: (Blocks 0-32767) csum 0x9569 [ITABLE_ZEROED]
Primary superblock at 0, Group descriptors at 1-117
Reserved GDT blocks at 118-1141
Block bitmap at 1142 (+1142)
Inode bitmap at 1158 (+1158)
Inode table at 1174-1685 (+1174)
21349 free blocks, 8177 free inodes, 2 directories, 8177 unused inodes
Free blocks: 11419-32767
Free inodes: 16-8192
Puisque nous pensons que seuls 4 Mo au début du système de fichiers ont été écrasés, nous n'avons qu'à nous soucier des blocs 0-1023. Et les blocs GDT réservés vont jusqu'au bloc 1141 ! C'est le genre de dommage qui devrait être réparé par un simple e2fsck -b $backup_superblock_number (après un redémarrage). Vous pourriez au moins essayer cela avec -n pour voir ce qu'il en pense.