Supongo que la tabla de particiones y la partición de arranque se pueden recrear fácilmente, así que me centraré en la partición ext4.
El diseño del sistema de archivos depende en cierta medida de las opciones utilizadas al crearlo. Voy a describir el caso común. Puedes ver si esto coincide con el tuyo ejecutando dumpe2fs en el dispositivo (que con suerte encontrará todos los metadatos de nivel superior en la memoria caché en lugar de leerlos del disco).
El tamaño de bloque normal para los sistemas de archivos ext4 es de 4096 bytes, por lo que ha perdido 1024 bloques.
Lo primero que se sobrescribió fue el bloque 0, el superbloque primario. Esto no es un problema en sí mismo, porque existen supermanzanas de respaldo. Después de eso está la tabla de descriptores de grupo, que también tiene copias de seguridad dentro del sistema de archivos.
Luego están los mapas de bits de bloques y los mapas de bits de inodos. Aquí es donde las noticias comienzan a empeorar un poco. Si alguno de estos está debajo del bloque 1024, que probablemente lo esté, ha perdido información sobre qué inodos y bloques están en uso. Esta información es redundante y fsck la reconstruirá en función de lo que encuentre al atravesar todos los directorios e inodos, si están intactos.
Pero lo siguiente es la tabla de inodos, y aquí probablemente haya perdido muchos inodos, incluido el directorio raíz, el diario y otros inodos especiales. Será bueno tenerlos de vuelta. Obviamente, el directorio raíz al menos todavía funciona, o casi todos los comandos que intente ejecutar ya estarían fallando.
Si ejecuta un dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 ahora, obtendrá una copia de respaldo de lo que sea que esté en su caché actualmente, mezclado con los datos incorrectos de los bloques que no están almacenados en caché. Luego, después de iniciar un disco de rescate, puede hacer lo mismo dd a la inversa, para volver a colocar los datos parcialmente buenos en el disco, sobrescribiendo las cosas totalmente malas que hay ahora.
Después de esto, es posible que encuentre herramientas de recuperación automáticas (fsck , testdisk ) funcionan lo suficientemente bien. De lo contrario, tiene un mapa que puede usar para ayudar con la recuperación manual. Usando las listas de "bloqueo libre" de dumpe2fs , ya sabes qué bloques ignorar.
La mayor parte de lo que perdiste probablemente sean inodos. En realidad, es bastante probable que no tuviera ningún archivo contenido en los primeros 4MB del disco. (Corrí mkfs.ext4 sin opciones en un archivo de imagen de 1 TB, y el primer bloque sin metadatos resultó ser el bloque 9249)
Cada inodo que logre recuperar identificará los bloques de datos de un archivo completo. Y esos bloques de datos pueden estar ubicados en todo el disco, no necesariamente cerca.
Día 2
El volcado publicado en pastebin revela buenas noticias:
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
Dado que creemos que solo se han sobrescrito 4 MB al comienzo del sistema de archivos, solo debemos preocuparnos por los bloques 0-1023. ¡Y los bloques GDT reservados llegan hasta el bloque 1141! Este es el tipo de daño que debe repararse con un simple e2fsck -b $backup_superblock_number (después de un reinicio). Al menos podrías intentarlo con -n a ver que piensa.