Eu assumo que a tabela de partições e a partição de inicialização podem ser recriadas facilmente, então vou focar na partição ext4.
O layout do sistema de arquivos é um pouco dependente das opções usadas ao criá-lo. Eu descreverei o caso comum. Você pode ver se isso corresponde ao seu executando dumpe2fs no dispositivo (que esperamos encontrar todos os metadados de nível superior no cache, em vez de ler do disco).
O tamanho normal do bloco para sistemas de arquivos ext4 é de 4096 bytes, então você perdeu 1024 blocos.
A primeira coisa sobrescrita foi o bloco 0, o superbloco primário. Isso não é um problema por si só, porque existem superblocos de backup. Depois disso é a tabela de descritor de grupo, que também tem backups dentro do sistema de arquivos.
Depois, há bitmaps de bloco e bitmaps de inode. É aqui que a notícia começa a ficar um pouco pior. Se algum deles estiver abaixo do bloco 1024, o que provavelmente é, você perdeu informações sobre quais inodes e blocos estão em uso. Essas informações são redundantes e serão reconstruídas pelo fsck com base no que encontrar percorrendo todos os diretórios e inodes, se estiverem intactos.
Mas a próxima coisa é a tabela de inode, e aqui você provavelmente perdeu muitos inodes, incluindo o diretório raiz, o diário e outros inodes especiais. Será bom ter aqueles de volta. Obviamente, o diretório raiz, pelo menos, ainda é funcional, ou apenas sobre todos os comandos que você tenta executar já estaria falhando.
Se você executar um dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 agora, obterá uma cópia de backup do que estiver em seu cache atualmente, misturada com os dados incorretos dos blocos que não estão armazenados em cache. Então, depois de inicializar um disco de recuperação, você pode fazer o mesmo dd no sentido inverso, para colocar de volta os dados parcialmente bons no disco, sobrescrevendo todas as coisas ruins que estão lá agora.
Depois disso, você pode encontrar ferramentas de recuperação automatizadas ( fsck , testdisk ) funcionam bem o suficiente. Caso contrário, você tem um mapa que pode ser usado para ajudar na recuperação manual. Usando as listas "bloco livre" de dumpe2fs , você sabe quais blocos ignorar.
A maior parte do que você perdeu provavelmente é inodes. Na verdade, é bem provável que você não tenha nenhum arquivo conteúdo nos primeiros 4 MB de disco. (Eu corri mkfs.ext4 sem opções em um arquivo de imagem de 1TB, e o primeiro bloco não-metadata acabou sendo o bloco 9249)
Cada inode que você conseguir recuperar identificará os blocos de dados de um arquivo inteiro. E esses blocos de dados podem estar localizados em todo o disco, não necessariamente nas proximidades.
Dia 2
O despejo postado no pastebin revela uma ótima notícia:
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
Como achamos que apenas 4MB no início do sistema de arquivos foram sobrescritos, precisamos nos preocupar apenas com os blocos 0-1023. E os blocos GDT reservados vão até o bloco 1141! Este é o tipo de dano que deve ser reparado por um simples e2fsck -b $backup_superblock_number (após uma reinicialização). Você poderia pelo menos tentar com -n para ver o que pensa.