Saya menganggap tabel partisi dan partisi boot dapat dibuat ulang dengan mudah, jadi saya akan fokus pada partisi ext4.
Tata letak sistem file agak bergantung pada opsi yang digunakan saat membuatnya. Saya akan menjelaskan kasus umum. Anda dapat melihat apakah ini cocok dengan Anda dengan menjalankan dumpe2fs di perangkat (yang diharapkan akan menemukan semua metadata tingkat atas dalam cache daripada membaca dari disk).
Ukuran blok normal untuk sistem file ext4 adalah 4096 byte, jadi Anda kehilangan 1024 blok.
Hal pertama yang ditimpa adalah blok 0, superblok utama. Ini bukan masalah dengan sendirinya, karena ada cadangan superblok. Setelah itu adalah tabel deskriptor grup, yang juga memiliki cadangan di dalam sistem file.
Lalu ada bitmap blok dan bitmap inode. Di sinilah berita mulai menjadi sedikit lebih buruk. Jika salah satu dari ini berada di bawah blok 1024, yang mungkin memang demikian, Anda kehilangan informasi tentang inode dan blok mana yang digunakan. Informasi ini berlebihan, dan akan direkonstruksi oleh fsck berdasarkan apa yang ditemukan melintasi semua direktori dan inode, jika utuh.
Tetapi hal berikutnya adalah tabel inode, dan di sini Anda mungkin kehilangan banyak inode, termasuk direktori root, jurnal, dan inode khusus lainnya. Akan menyenangkan untuk memilikinya kembali. Jelas direktori root setidaknya masih berfungsi, atau hampir semua perintah yang Anda coba jalankan akan gagal.
Jika Anda menjalankan dd if=/dev/nvme1n1p2 of=/some/external/device bs=4096 count=1024 sekarang, Anda akan mendapatkan salinan cadangan dari apa pun yang ada di cache Anda saat ini, bercampur dengan data buruk untuk blok yang tidak di-cache. Kemudian setelah mem-boot disk penyelamat, Anda dapat melakukan dd yang sama sebaliknya, untuk mengembalikan data yang sebagian baik itu ke disk, menimpa semua hal buruk yang ada di sana sekarang.
Setelah ini, Anda mungkin menemukan alat pemulihan otomatis (fsck , testdisk ) bekerja dengan cukup baik. Jika tidak, Anda memiliki peta yang dapat digunakan untuk membantu pemulihan manual. Menggunakan daftar "blok gratis" dari dumpe2fs , Anda tahu blok mana yang harus diabaikan.
Sebagian besar dari apa yang hilang mungkin adalah inode. Kemungkinan besar Anda tidak memiliki file konten di disk 4MB pertama. (Saya menjalankan mkfs.ext4 tanpa opsi pada file gambar 1 TB, dan blok non-metdata pertama ternyata adalah blok 9249)
Setiap inode yang berhasil Anda pulihkan akan mengidentifikasi blok data dari seluruh file. Dan blok data tersebut mungkin terletak di seluruh disk, tidak harus di dekatnya.
Hari 2
Dump yang diposting di pastebin mengungkapkan berita bagus:
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
Karena menurut kami hanya 4MB pada awal sistem file yang telah ditimpa, kami hanya perlu khawatir tentang blok 0-1023. Dan blok GDT yang dicadangkan sepenuhnya memblokir 1141! Ini adalah jenis kerusakan yang harus diperbaiki dengan e2fsck -b $backup_superblock_number sederhana (setelah reboot). Anda setidaknya bisa mencobanya dengan -n untuk melihat apa yang dipikirkannya.