Recovery harddisk dengan partisi NTFS

Ini adalah pengalaman saya merecover data dari sebuah hard disk (bukan SSD) yang partisinya memakai filesystem NTFS (New Technology Filesystem) yang umum dipakai Windows saat ini (di masa depan Microsoft mungkin akan memakai ReFS/Resilient File System). Metode yang saya pakai untuk recovery ini mungkin berguna untuk beberapa kasus, tapi tidak semua kasus, tergantung jenis kerusakan yang terjadi.

Kerusakan pada Hard disk

Bentuk kegagalan (failure) hard disk berbeda dengan SSD, jadi harap dicatat bahwa banyak hal di tulisan ini yang tidak berlaku untuk SSD. Hard Disk memiliki komponen mekanis: head dan platter dan juga komponen elektronik (controller). Controller hard disk adalah PCB yang memiliki CPU dan RAM dan menjalankan firmware hard disk.

Harddisk bisa rusak perlahan, mulai dari lambat (karena ada beberapa sektor yang harus dibaca ulang), atau tiba-tiba. Ada banyak penyebab kerusakan hard disk, bisa karena fisik (jatuh, terbakar, terkena air, dsb), bisa karena salah satu komponennya rusak (misalnya headnya stuck atau controllernya rusak).

Bentuk kegagalan hard disk yang lain adalah: sebuah sektor tidak terbaca karena ada masalah dengan permukaannya tapi kadang jika dicoba berkali-kali bisa terbaca, ini bisa terjadi random jika hard disk sudah tua, atau mungkin ada cacat produksi.

Jika hard disk tidak terbaca sama sekali, maka ada kemungkinan bisa dibaca jika head dan atau controllernya diganti (atau platternya dipindah ke harddisk yang sehat). Dalam kasus di mana head atau controller perlu diganti, kadang tetap ada kemungkinan sebagian disk tidak terbaca.

Cara kerja hard disk ini sangat mirip dengan floppy disk. Buat Anda yang pernah mengalami memakai floppy disk seperti saya, mungkin pernah mengalami bahwa floppy disk kadang gagal dibaca di satu drive, tapi berhasil di drive lain.

Sebuah harddisk juga bisa seolah-olah tidak terbaca sama sekali (tidak muncul di Windows atau tidak bisa dimount di Linux) jika ada sektor tertentu yang tidak terbaca dan menyebabkan bootloader atau sistem operasi tidak mengenali disk tersebut.

Sebuah disk dibagi menjadi banyak sektor, dulu ukuran satu sektor adalah 512 byte, sekarang yang umum adalah 4096 byte (4K). Jika ada kerusakan di satu sektor, maka keseluruhan ukuran sektor tersebut tidak terbaca (jadi tidak mungkin hanya 1 byte yang terbaca).

Sebelum harddisk modern memakai controller yang menempel di harddisk, pengalamatan sektor memakai notasi Cylinder, Head, Sector (CHS). Tapi sejak 20-an tahun yang lalu, semuanya memakai alamat absolute (LBA/Logical block addressing). Jadi kita bisa memandang sebuah harddisk sebagai file yang memiliki kelipatan ukuran sejumlah sektor yang ada, dan kita bisa melakukan “seek” ke sembarang sektor.

Kasus yang saya tangani

Dalam kasus ini, harddisk ini dipakai untuk drive data di sebuah laptop (ada disk lain untuk Windows). Suatu hari Windows tidak mau booting, dan penyebabnya ternyata adalah hard disk data ini menyebabkan Windows stuck ketika booting.

Dari label harddisknya, terlihat bahwa harddisk ini adalah Western Digital Blue Mobile (SMR), model WDC WD10SPZX-21Z10T0 dengan kapasitas 1TB. Ukuran sektornya adalah: 512 bytes logical, 4096 bytes physical. Artinya: jika ada 1 sektor rusak, kemungkinan data yang tidak terbaca adalah kelipatan 4KB (sesuai physical sizenya).

Ketika dihubungkan ke USB-SATA tidak terdeteksi di Windows. Ketika saya hubungkan ke Linux menggunakan USB-SATA, terlihat bahwa:

1. Hard disk ini masih terdeteksi
2. Tabel partisi masih terdeteksi
3. Terlihat ada pesan error sektor tidak terbaca

Bagian partisi bisa dilihat di baris sdb: sdb1 sdb2 sdb3 sdb4. Tabel partisi yang dipakai adalah GPT (GUID Partition Table). Jaman dulu partisi yang banyak dipakai adalah jenis MSDOS/MBR. Pada GPT, ada backup tabel partisi di akhir disk. Jika salah satu gagal dibaca atau error, yang satu lagi bisa dipakai.

Partisi yang penting adalah sdb3, partisi pertama adalah EFI (tidak penting, hanya untuk booting), partisi kedua tidak dipakai, dan partisi terakhir adalah untuk Windows Recovery (tidak berisi data penting).

Berikut ini status SMART (Self-Monitoring, Analysis and Reporting Technology) menggunakan smartctl yang mengkonfirmasi bahwa disk ini memang rusak (lihat teks:”FAILING_NOW”).

Meskipun partisi terdeteksi, ketika saya mencoba me-mount partisinya, hasilnya gagal:

ntfs_attr_pread_i: ntfs_pread failed: Input/output error
Failed to read NTFS $Bitmap: Input/output error
Failed to read NTFS $Bitmap: Input/output error
NTFS is either inconsistent, or there is a hardware fault, or it's a
SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows
then reboot into Windows twice. The usage of the /f parameter is very
important! If the device is a SoftRAID/FakeRAID then first activate
it and mount a different device under the /dev/mapper/ directory, (e.g.
/dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation
for more details.

Teori dasar dalam forensik dan dalam data recovery adalah membuat disk image, alias salinan disk menjadi bentuk file di hard disk lain. Dari disk image itu kita akan berusaha melakukan recovery dengan tool standard yang akan berusaha mencari file yang ada di disk.

Dalam kasus ini, karena tabel partisi masih bisa dibaca, saya cukup menyalin partisi data saja, tidak perlu semua partisi.

Menghubungkan disk

Ada tool khusus yang dipakai oleh professional untuk membaca hard disk, tapi karena saya ingin melakukan recovery sendiri, maka tool yang dipakai adalah komputer. Ada dua alternatif untuk menghubungkan hard disk ke komputer langsung ke port SATA atau menggunakan SATA to USB adaptor (atau singkatnya saya sebut USB-SATA).

Masalah dengan hard disk rusak adalah: jika dihubungkan ke komputer kadang membuat komputer “hang” atau bootingnya lama sekali. Ini tergantung bagian disk mana yang error. Jika posisinya adalah di area data sebuah file, maka biasnya ini tidak akan menyebabkan hang, jika di area penting filesystem, maka ini bisa menyebabkan hang.

Sebagai catatan: definisi hang di sini bisa sekedar tidak responsif agak lama (tidak tahu berapa lama karena jika lewat beberapa menit, saya sudah tidak sabar dan merestart kompuetrnya), sampai benar-benar hang dalam arti: UEFI yang stuck tidak mau boot, GRUB yang hang tidak menampilkan menu dan kernel yang crash. Ini sudah saya alami berkali-kali ketika melakukan recovery ini.

Ketika komputer melakukan startup, maka UEFI/BIOS akan mencoba mencari semua hard disk dan mengecek apakah bisa diboot. Pada sistem modern yang memakai UEFI (silakan baca lebih lanjut tentang UEFI di tulisan saya yang ini), maka tabel partisi akan dibaca untuk melihat apakah ada partisi UEFI. Jika harddisk rusak di bagian partisi atau data EFI, proses ini kadang “hang” atau butuh waktu lama sekali sampai timeout. Sebagai catatan: ini tergantung pada versi UEFI dan setting yang aktif saat itu (saya test di 2 komputer, satu mau boot setelah beberapa menit berusaha membaca disk, yang satu lagi stuck).

Setelah melewati BIOS/UEFI, bootloader juga akan mengecek partisi hard disk yang, dan ini juga bisa menyebabkan hang lagi. Contohnya: GRUB akan mencari hard disk yang ada ketika booting untuk mengecek partisi mana yang perlu diboot. Setelah itu, OS juga akan berusaha membaca partisi setiap disk yang terhubung (misalnya jika ingin melakukan mounting root filesystem berdasarkan disk GUID di Linux), dan ini juga kadang bisa menyebabkan hang.

Terakhir: setelah kita login, maka environment desktop modern seperti Gnome/KDE juga akan otomatis mencoba me-mount filesystem dan juga bisa menyebabkan “hang”. Dalam kehidupan sehari-hari ini sangat praktis: jika kita colok USB maka akan termount, tapi dalam kasus ini proses automount bisa mengesalkan.

Untuk memastikan booting lancar dan cepat, jika motherboard dan UEFI mendukung SATA hotplug, maka aktifkan fitur ini agar port SATA bisa dicolok setelah proses boot selesai. Dalam kasus recovery kali ini, saya memutuskan menggunakan USB-SATA adaptor yang saya hubungkan ke komputer yang menggunakan Linux. Hard Disk bisa saya colokkan setelah proses booting selesai.

Memakai USB-SATA menurut saya praktis: kita bisa cabut/colok disk kapan saja dengan mudah, dan kadang sektor yang stuck bisa dibaca lagi setelah cabut colok. Penjelasan ilmiah untuk ini: harddisk memiliki controller yang menjalankan algoritma tertentu ketika membaca sektor rusak, kadang dengan mereset RAM pada controller (dengan mencabut power disknya), algoritma pembacaan disknya direset agar berjalan dari awal.

Tapi ternyata USB-SATA juga memiliki masalah: dalam kasus tertentu bisa menyebabkan Linux hang karena kernel panic. Seorang teman menyarankan agar saya memakai port USB 2.0, tapi karena komputer yang saya pakai cukup modern, tidak lagi memiliki port USB 2.0, maka sarannya tidak bisa saya coba.

Tool untuk membuat disk image

Ada beberapa tool gratis untuk membaca harddisk rusak: dd_rescue, myrescue, dcfldd, safecopy dsb. Dalam proses akuisi forensik, ada tool-tool komersial yang diakui untuk pengadilan. Tujuan saya adalah ingin recovery data dan bukan untuk tujuan pengadilan, jadi saya bebas memakai cara apapun termasuk tool buatan sendiri.

Semua tool yang membaca disk secara sekuensial memiliki masalah yang sama: ketika ketemu bad sector, maka akan tersendat selama beberapa detik. Biasanya bad sector ini berurutan, jadi jika ketemu satu, kemungkinan akan ketemu di N sektor berikutnya. Jika kita beruntung, hanya sebagian kecil sektor yang rusak, dan proses imaging ini bisa cepat, tapi di kasus yang saya alami ini: bagian awal disk banyak sekali bad sectornya, selama beberapa jam hanya terbaca beberapa megabyte. Program myrescue dan safecopy memiliki fitur pintar untuk skip bad sector ini, tapi tetap butuh waktu lama mengcopy seluruh disk.

Sebenarnya saya masih ingin mencoba-coba tool-tool lain, tapi mengalami masalah dengan beberapa USB-SATA yang saya pakai: ketika terjadi error berturut-turut, maka akan terjadi “USB Reset”, dan ketika terdeteksi lagi, nama disk berubah, misalnya /dev/sdb menjadi /dev/sdc lalu menjadi /dev/sdd dst. Nah semua tool yang saya pakai tidak menangani kasus perubahan nama device ini, jadi ketika sedang berusaha membaca disk dan gagal, ketika mencoba ulang, nama disknya sudah berubah.

Karena masalah nama drive yang berubah ini, saya juga mencoba menggunakan port SATA langsung. Sayangnya komputer yang saya pakai ini tidak memiliki fitur hotplug, jadi jika stuck agak lama, tidak bisa dengan mudah kita cabut colok harddisknya.

Perhatikan kecepatan membaca disk, jika kecepatan membaca disk hanya bisa 100GB/hari, maka akan butuh 10 hari untuk membaca seluruh disk, menurut saya ini terlalu lama. Jadi perhatikan dengan seksama fakta ini: jika proses terinterupsi, bagaimana meneruskan proses copynya menggunakan program yang Anda pilih.

Contoh: saya mencoba safecopy, terbaca cukup banyak data (ratusan gigabyte). Di tengah proses, tak terduga ada mati listrik cukup lama karena ada maintenance di kompleks perumahan saya (biasanya ini diumumkan, tapi kali ini saya tidak dapat informasinya), dan UPS saya tidak cukup menyalakan komputer beberapa jam. Jadi saya stop prosesnya dan matikan komputernya.

Ketika listrik sudah kembali normal, saya boot komputernya, dan secara refleks saya mencet panah atas untuk mengulangi proses copy dengan harapan akan diteruskan, tapi ternyata ini salah dan tanpa peringatan ataupun konfirmasi, proses copy diulangi dari nol. Ternyata seharusnya untuk meneruskan perlu pakai parameter khusus. Manual pagenya kurang membahas kasus ini.

Karena frustrasi dengan berbagai keterbatasan tool dan berbagai sifat tool yang unexpected, saya membuat program sederhana: membaca disk dengan ukuran sektor 128 MB, jika terbaca, maka akan saya tuliskan ke file. Jika tidak terbaca, akan saya skip. Saya akan mencari nama disk terakhir di /dev, jadi ketika error, saya akan membaca partisi disk yang benar.

Semua status sektor saya catat di file. Jika beruntung, kadang saya bisa mendapatkan satu blok 64MB, tapi jika tidak, hanya beberapa kilobyte terbaca. Di pass kedua, saya mencoba membaca lagi dengan ukuran sektor 64 megabyte untuk sektor yang belum terbaca, lalu saya ulangi lagi 32 megabyte. Dengan cara ini dalam waktu sekitar 48 jam, seluruh disk terbaca, walau banyak bad sector. Saya berhenti di 32 megabyte, karena ketika mencoba 16 megabyte, ketemu banyak bad sector dan pembacaannya lambat.

USB-SATA yang mana?

Ada banyak merk adaptor SATA to USB, mana yang sebaiknya dipilih? saya tidak bisa menyarankan yang terbaik, saya memiliki beberapa merk, tapi tidak bisa menyaranken merk tertentu. Bahkan yang chipsetnya sama dan merknya sama, ternyata kualitasnya tidak sama (entah memang ada kelemahan design, atau mungkin saja kurang beruntung kena barang yang cacat produksi).

Ada adaptor yang setelah saya pakai beberapa kali tiba-tiba rusak dan tidak dikenali sama sekali sebagai USB device. Ada yang hanya mau dihubungkan ke SSD tertentu, kalau ini kemungkinan karena daya yang bisa dilewatkan ke disk dibatasi oleh salah satu komponen di dalam adaptornya.

Kesimpulannya: jika memang datanya berharga, belilah beberapa adaptor SATA USB. Coba juga untuk membaca disk yang sehat untuk memastikan adaptornya memang jalan. Saya masih punya beberapa hard disk lama yang belum saya buang yang ternyata berguna untuk mengetes adaptor semacam ini.

Memahami internal NTFS

Dalam kasus recovery saat ini, sebenarnya tidak semua isi hard disk diperlukan, karena ternyata sudah ada backup yang dibuat bulan Maret 2023. Saya jadi terpikir: apakah mungkin berusaha recover file-file yang dibuat setelah Maret 2023 saja?

Idenya seperti ini: kalau sulit dan lama membuat disk image lengkap, bagaimana kalau pembacaan difokuskan hanya pada sektor-sektor yang memang dibutuhkan saja. Di langkah sebelumnya saya sudah mendapatkan cukup banyak bagian disk yang terbaca, tapi bagian bad sector sisanya masih banyak, dan bagian bad sector ini yang makan waktu banyak ketika dibaca.

Di NTFS semua tersimpan sebagai file, termasuk daftar file juga disimpan di file, namanya $MFT (master file table) dan informasi sektor untuk sebuah file ada di file bernama $Btimap. Jika saya beruntung dan $MFT serta $Bitmap masih terbaca di NTFS, maka saya bisa mencari file-file yang diperlukan dan membaca file-file itu saja. Tidak perlu seluruh MFT/Bitmap terbaca, kalaupun ada sektor yang tidak terbaca di sebuah subdirectory, itu bisa diskip.

NTFS memiliki format yang tidak terlalu rumit, tapi juga tidak sederhana. Mengimplementasikan sendiri parser untuk NTFS akan butuh waktu lama, jadi saya mencoba memakai berbagai tools dari ntfs-3g. Dengan memakai tool ini dan sedikit hack untuk melakukan tracing, saya bisa mendapatkan daftar sektor mana yang perlu direcover.

Langkah pertama yang saya lakukan adalah melakukan listing direktori. Karena gagal memount partisinya dengan Linux, maka saya memakai tool ntfsls dari ntfs-3g. Ternyata sukses untuk melihat daftar direktorinya.

ntfsls -f /dev/sdb3

Tapi saya perlu mendapatkan list tanggalnya juga.

ntfsls -f /dev/sdb3 -l

Pertama gagal, tapi setelah diulang-ulang beberapa kali, akhirnya terbaca, ketika komputer restart dan dicoba lagi, tidak terbaca, lalu terbaca lagi. Ini menunjukkan betapa berbahayanya bekerja langsung di disk yang rusak: mencoba membaca berulang-ulang kadang membuat sektor bisa dibaca, tapi kadang bisa membuat sektor tersebut dan sekitarnya malah menjadi tidak bisa dibaca sama sekali.

Cara yang benar adalah dengan bekerja pada disk image yang sudah berhasil dibuat. Karena disk image-nya tidak lengkap (ada sektor-sektor yang 0), maka ntfsls ini bisa gagal dan mnampilkan pesan error.

Contohnya begini: membaca daftar nama file saja berhasil, tapi ketika berusaha membaca atributnya, gagal

# ntfsls -f part3 
WARNING: Dirty volume mount was forced by the 'force' mount option.
$RECYCLE.BIN
Acer (C) - Shortcut.lnk
ACER_SWIFT
ACER_SWIFT - Shortcut.lnk
bootTel.dat
chat.txt
installer
# ntfsls -f part3 -l
WARNING: Dirty volume mount was forced by the 'force' mount option.
       0 May  9 16:19 2019 $RECYCLE.BIN
ntfs_mst_post_read_fixup_warn: magic: 0x00000000  size: 1024   usa_ofs: 0  usa_count: 0: Invalid argument
Record 23021 has no FILE magic (0x0)

Bagian disk mana yang berusaha dibaca oleh ntfsls ini? kita bisa menggunakan strace, dari percobaan, ternyata ntfsls menggunakan fungsi POSIX pread64 untuk membaca disk (tanpa menggunakan seek). Jadi saya jalankan strace seperti ini:

strace -e pread64 ntfsls -f part3 -l

Hasilnya panjang, tapi ada bagian ini:


pread64(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"…, 1024, 37030413312) = 1024


Terlihat pread64 yang terakhir berusaha membaca sektor yang gagal terbaca dari disk asli (jadi hasilnya semuanya 0). Sekarang saya tahu harus membaca dari disk asli mulai dari offset 37030413312 sebanyak 1024 byte (kalau perlu diulangi sampai berhasil). Ini bisa dilakukan dengan dd atau program custom.

Secara default blocksize untuk dd adalah 512 byte, jadi untuk offset tersebut kita bagi 512 menjadi 72325026, lalu:

dd if=/dev/sdb3 skip=72325026 seek=72325026 count=2 conv=notrunc of=part3

Setelah itu jika kita melakukan ntfsls lagi, hasilnya file berikutnya terbaca, tapi berhenti di error berikutnya. Langkah ini tinggal diulangi saja sampai semua terbaca.

Untuk memudahkan, saya membuat library dengan teknik LD_PRELOAD (pernah saya bahas di tulisan ini), yang akan mengintercept pread64, jika datanya sudah sukses dibaca di disk image, maka bisa dikembalikan apa adanya, dan jika belum terbaca, maka akan membaca dari disk asli dan dipindah ke disk image. Alternatif lain adalah langsung mengedit/recompile program ntfs-3g.

Ternyata saya sangat beruntung karena sebagian besar MFT berhasil dibaca. Saya menangani manual 140 direktori top level, hasilnya ada beberapa yang tidak berbaca isi subdirektorinya, untungnya dari nama direktorinya terlihat bahwa ini adalah file lama. Dengan teknik ini daftar file berhasil didapatkan, dan dari sini saya bisa mengetahui direktori/file mana saja yang perlu disalin.

Konten File

Setelah mendapatkan nama-nama filenya, berikutnya yang perlu dilakukan adalah membaca filenya. Pembacaan file bisa berhasil jika file $Bitmap pada NTFS masih valid. Untungnya dalam kasus saya ini, $Bitmap masih valid.

Pembacaan file secara manual bisa dilakukan dengan ntfscat. Seperti halnya ntfls , program ntfscat juga menggunakan pread64, jadi jika ada blok yang hasilnya semuanya nol, maka coba baca berkali-kali dari disk aslinya sampai berhasil (walau dalam kasus saya, ada juga blok yang kontennya gagal dibaca).

Menguji File Hasil

Sebuah harddisk memakai Error Correction Code untuk memastikan bahwa data yang berhasil dibaca adalah data yang benar. Masalahnya adalah bahwa masih ada kemungkinan error di filesystem, misalnya lokasi yang seharusnya dimiliki satu file dipakai oleh file lain.

Bagaimana kita bisa yakin bahwa file-file yang berhasil diselamatkan tidak corrupt?. Kebanyakan file yang direscue adalah Ms Office (docx, xlsx, pptx), Libreoffice (odt), zip, pdf, png dan JPG. Untuk file-file berbasis zip (file-file office), saya cukup menjalankan:

unzip -t namafile.docx

Jika tidak ada error, maka file kemungkinan besar OK, karena tiap file dalam zip memiliki checksum.

Untuk file JPG/PNG saya memakai identify -verbose jika tidak keluar error message, maka image baik-baik saja.

File PDF agak sulit dicek validitasnya 100%, misalnya kadang file PDF tetap berhasil ditampilkan dengan sukses jika bagian yang corrupt adalah bagian gambarnya saja.

Testdisk

Program testdisk merupakan program terdekat yang bisa melakukan secara otomatis yang saya lakukan secara manual. Program ini akan langsung membaca ke disk, jadi akan gagal juga jika memakai USB-SATA yang merename disk ketika reconnect.

Saya masih tidak mengerti 100% perilakunya, karena kadang bisa masuk/keluar direktori dengan cepat, tapi kadang tersendat ketika ke direktori parent (padahal seharusnya sudah dicache sebelum masuk subdirektori). Ini menyebabkan proses browsing file menjadi sangat mengesalkan.

Saya juga tidak menemukan fitur untuk otomatis menghasilkan list file, supaya bisa difilter file-file baru yang bisa direscue. Ada fitur untuk mencari jenis/extension file saja. Selain itu, saya menemukan beberapa direktori yang tertulis tahun 2023, dan ketika saya cek isinya dari tahun 2020. Hasil pembacaan yang saya lakukan manual lebih akurat (memang seharusnya tahun 2020).

Hasil Akhir

Akhirnya hampir semua file berhasil dibaca dengan sukses, hanya sekitar 60kb yang gagal dibaca. Saya senang sekali karena usaha recovery ini tidak sia-sia.

Saya merasa beruntung karena yang dibutuhkan adalah file-file baru yang masih terbaca. Di kasus reovery lain, mungkin yang dibutuhkan adalah file lama karena file baru mungkin masih dikerjakan bersama, jadi ada teman yang memiliki salinannya.

Di kasus ini sebagin besar sektor file baru masih aman, di kasus lain, kadang justru data terbaru yang rusak. Contoh kasus kenapa bisa terjadi: harddisk mengalami guncangan ketika menulis file terbaru, jadi merusak MFT dan sektor-sektor sekitar file baru.

Secara umum, teknik recovery yang saya pakai akan berhasil hanya jika:

• Disk masih terbaca partisinya
• MFT pada NTFS masih terbaca
• $Bitmap pada NTFS masih bisa terbaca dan valid

Dan langkah yang saya sarankan:

• Memakai SATA langsung (tidak memakai USB-SATA) jika memungkinkan (tapi jika hanya memakai laptop maka kemungkinan yang bisa dilakukan adalah memakai USB-SATA)
• Memakai testdisk langsung pada disk jika ingin berusaha mengakses file langsung
• Memakai safecopy (jika langsung memakai SATA, tapi perhatikan baik-baik opsinya) atau membuat program custom sendiri untuk membaca disk (dalam kasus USB-SATA), lalu imagenya berusaha dibaca dengan testdisk.

Bagaimana jika $MFT atau $Bitmap rusak? kasus ini akan sulit, yang bisa dilakukan adalah File Carving menggunakan berbagai tool recovery. Intinya adalah: tiap sektor akan berusaha digabungkan dengan sektor lain dan dicek apakah membentuk file yang valid. Contoh tool yang bisa dipakai adalah: PhotoRec dan Foremost.

Dalam kasus File Carving, nama dan tanggal file mungkin tidak terlihat sama sekali dan isi dokumen harus dicek satu per satu. Dalam pengalaman saya, file carving ini efektif hanya pada kasus recovery foto/video pada USB/Micro SD dan dipakai di kamera atau ponsel.

Penutup

Dulu saya akan mempercayakan saja recovery pada sebuah software, tapi sekarang saya sudah tahu lebih banyak mengenai hard disk, partition, dan filesystem. Saya merasa bahwa lebih baik untuk mengerti setiap langkah proses recovery dibandingkan menggantungkan diri pada berbagai software berusaha mengekstrak data otomatis.

Program-program custom yang saya buat untuk recovery sengaja tidak saya share karena saya membuatnya terlalu spesifik untuk disk ini dan juga untuk komputer saya (banyak yang saya hard code). Saya takut kalau merilis kode yang kurang teruji, malah bisa menyebabkan orang lain kehilangan lebih banyak data.