Presumo che la tabella delle partizioni e la partizione di avvio possano essere ricreate facilmente, quindi mi concentrerò sulla partizione ext4.
Il layout del filesystem dipende in qualche modo dalle opzioni utilizzate durante la sua creazione. Descriverò il caso comune. Puoi vedere se corrisponde al tuo eseguendo dumpe2fs sul dispositivo (che, si spera, troverà tutti i metadati di primo livello nella cache anziché leggerli dal disco).
La normale dimensione del blocco per i filesystem ext4 è di 4096 byte, quindi hai perso 1024 blocchi.
La prima cosa sovrascritta è stata il blocco 0, il superblocco primario. Questo non è un problema di per sé, perché ci sono superblocchi di backup. Dopo c'è la tabella dei descrittori di gruppo, che ha anche i backup all'interno del filesystem.
Poi ci sono bitmap a blocchi e bitmap inode. È qui che le notizie iniziano a peggiorare leggermente. Se qualcuno di questi è al di sotto del blocco 1024, cosa che probabilmente è, hai perso informazioni su quali inode e blocchi sono in uso. Queste informazioni sono ridondanti e verranno ricostruite da fsck in base a ciò che trova attraversando tutte le directory e gli inode, se questi sono intatti.
Ma la prossima cosa è la tabella degli inode, e qui probabilmente hai perso molti inode, inclusa la directory root, il journal e altri inode speciali. Sarà bello riaverli indietro. Ovviamente almeno la directory root è ancora funzionante, o quasi tutti i comandi che provi ad eseguire fallirebbero già.
Se esegui un dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 ora otterrai una copia di backup di tutto ciò che è attualmente nella tua cache, mescolato con i dati errati per i blocchi che non sono memorizzati nella cache. Quindi, dopo aver avviato un disco di ripristino, puoi fare lo stesso dd al contrario, per rimettere quei dati parzialmente buoni sul disco, sovrascrivendo le cose completamente cattive che sono lì adesso.
Successivamente potresti trovare strumenti di ripristino automatico (fsck , testdisk ) funzionano abbastanza bene. In caso contrario, hai una mappa che puoi utilizzare per aiutarti con il ripristino manuale. Usando gli elenchi di "blocchi liberi" da dumpe2fs , sai quali blocchi ignorare.
La maggior parte di ciò che hai perso è probabilmente inode. In realtà è abbastanza probabile che tu non abbia il contenuto del file nei primi 4 MB di disco. (Ho eseguito mkfs.ext4 senza opzioni su un file immagine da 1 TB e il primo blocco non di metadati si è rivelato essere il blocco 9249)
Ogni inode che riesci a recuperare identificherà i blocchi di dati di un intero file. E quei blocchi di dati potrebbero trovarsi in tutto il disco, non necessariamente nelle vicinanze.
Giorno 2
Il dump pubblicato su pastebin rivela grandi novità:
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
Poiché pensiamo che siano stati sovrascritti solo 4 MB all'inizio del filesystem, dobbiamo preoccuparci solo dei blocchi 0-1023. E i blocchi GDT riservati vanno fino al blocco 1141! Questo è il tipo di danno che dovrebbe essere riparato con un semplice e2fsck -b $backup_superblock_number (dopo un riavvio). Potresti almeno provarlo con -n per vedere cosa ne pensa.