Baca file terakhir untuk memulihkan data

File .swp yang sangat lama mengembalikan file yang saya edit, jadi sekarang secara signifikan lebih pendek. Saya tidak melakukan apa pun di direktori itu sejak itu, jadi byte segera setelah akhir file masih harus memiliki data saya. Fungsi apa yang dapat saya gunakan untuk membaca N byte dari alamat memori yang diberikan? dddan readberhenti di batas file, kecuali saya melewatkan opsi di suatu tempat.

Ukuran file saat ini adalah 3,2 KB. Saya tidak ingat persis seberapa besar file itu sebelum dipotong, tetapi mungkin tidak lebih dari 10 KB. Bagaimana saya bisa membaca 10 KB dari awal file, mengabaikan batas file? Tidak apa-apa jika data tidak disimpan dengan sempurna, selama saya tidak harus memulai dari awal.

data-recovery

— Matthew Bedford
sumber

Biasanya ketika editor menyimpan file, mereka menghapus atau memotong ke 0, sehingga membebaskan ruang yang dialokasikan, dan kemudian menulis, yang mengalokasikan ruang baru. Ini menghasilkan filesystem yang meletakkan data di lokasi fisik yang sama sekali berbeda. Jadi ide Anda mungkin tidak berhasil.

Anda bisa mendapatkan lokasi fisik file menggunakan filefragatau hdparm --fibmap, dan kemudian gunakan dduntuk membaca lokasi fisik secara langsung. Saya telah menggambarkan proses ini dalam konteks yang berbeda di sini: /unix//a/85880/30851

Dalam kasus Anda, kemungkinan besar Anda membutuhkan pendekatan umum untuk menemukan data tekstual ... sesuatu seperti:

strings -n 12 -t d /dev/partition | grep -F 'text snippet'

strings akan mencari data ASCII berturut-turut (juga mendukung beberapa pengkodean lainnya, tidak yakin tentang UTF-8. Jika itu kode atau bahasa Inggris Anda tidak akan membutuhkannya) dan juga akan mencetak offset di tempat ditemukannya.

text snippetharus berupa sampel teks unik, persis yang Anda ingat berada di bagian file yang Anda cari [dalam satu baris]. (Jika Anda tidak mengetahuinya dengan tepat, Anda bisa mengatasinya dengan ekspresi reguler.)

-n 12adalah panjang minimum yang stringsakan dicari. 12harus menjadi panjang Anda text snippet. Parameter ini bersifat opsional, jika disediakan mungkin akan membantu strings | grepsedikit lebih cepat.

Akan memakan waktu lama untuk membaca seluruh partisi tetapi jika berhasil, Anda akan memiliki offset yang dapat Anda beri makan dduntuk meraih area umum dan kemudian menghapus barang-barang yang bukan milik.

Saya tidak melakukan apa pun di direktori itu sejak itu

Jika direktori Anda tidak menjadi titik mount ... kebanyakan filesystem tidak benar-benar menyediakan ruang "per direktori" jadi ... setiap dan semua penulisan di seluruh filesystem mungkin menimpa bit yang Anda cari. Dalam situasi pemulihan data, Anda biasanya mengubah semuanya menjadi mode hanya baca.

— frostschutz
sumber

Perhatikan bahwa setiap file disimpan dalam banyak blok dan biasanya tidak disimpan secara berurutan. Jadi stringshanya akan menemukan beberapa bagian file kecuali Anda sangat beruntung.

— Gilles 'SO- stop being evil'

Justru sebaliknya, Anda harus sangat sial untuk menemukan file 10KB terfragmentasi. Jika Anda hanya menemukan bagian, kemungkinan besar bagian lainnya ditimpa dalam kasus ini. Tetapi kecuali jika Anda memiliki banyak aktivitas penulisan dalam sistem file itu, atau itu adalah SSD dengan pembuangan instan, jika Anda menyimpan file itu beberapa kali saat mengedit, Anda mungkin menemukan banyak salinan file itu.

— frostschutz

Saya akan merekomendasikan strings -n16atau panjang minimum yang masuk akal, untuk membuatnya lebih cepat.

— Peter Cordes

Poin bagus, menambahkannya ke jawabannya.

— frostschutz

Terima kasih banyak. Hanya ada sampah yang hanya melewati akhir file, tetapi dengan stringssaya dapat menemukan seluruh file di tempat lain di partisi. Itu hampir dua bulan kerja yang tidak harus saya lakukan lagi, dan pengingat yang sangat baik untuk selalu menggunakan kontrol versi untuk hal-hal penting.

— Matius Bedford