File Log DDRescue Rusak setelah pemulihan 6 minggu

Saya telah menjalankan DDRescue pada drive 3TB selama hampir 2 bulan dan saya telah memulihkan sekitar 2.8TB ketika sistem crash dan file log yang saya gunakan rusak. Saya dapat memulihkan sebagian file log itu tetapi ada celah di sektor-sektor dalam log yang dipulihkan yang membuat DDRescue mengembalikan kesalahan ketika saya meluncurkannya lagi. Berikut ini adalah tautan transfer basah untuk melihat file log: https://we.tl/58aSOeCOJo

Saya mencoba mengedit file log untuk mengeluarkan data yang korup tetapi karena ini menciptakan 'celah' dalam kronologi sektor, DDRescue tampaknya tidak seperti itu.

Terima kasih atas bantuannya, saya benar-benar ingin menghindari menjalankan kembali DDRescue selama dua bulan untuk menyelamatkan drive ini ...

Untuk membuat jawaban ini setidaknya sebagian bermanfaat bagi pengguna lain dengan masalah yang sama, mari kutip bagian penting dari log Anda di sini:

# Rescue Logfile. Created by GNU ddrescue version 1.18.1
# Command line: ddrescue -f -d -R -r3 /dev/sde /dev/sdf /mnt/somedir/logfiles/log3.log
# Start time:   2017-08-14 10:22:44
# Current time: 2017-08-14 12:13:09
# Copying non-tried blocks... Pass 1 (backwards)
# current_pos  current_status
0x27BF0520000     ?
#      pos        size  status
0x00000000  0x02870000  +
0x02870000  0x001A0000  *
0x02A10000  0x00010200  +
0x02A20200  0x0005FE00  *
# ...                          many lines here
0x2BA92360000  0x00040000  ?
0x2BA923A0000  0x00010000  *
#                              binary garbage here
0xE4E1710000  0x00010000  *
# ...                          many lines here
0x13D75970000  0x00000200  +
0x13D75970200  0x00

Anda mengidentifikasi baris tepat sebelum sampah biner menjadi yang terakhir valid. Ia mengatakan 0x2BA923A0000 0x00010000 * dan itu adalah nomor baris 880829 dalam kasus Anda. Masuk akal karena garis setelah sampah memiliki posisi lebih rendah (angka pertama), mereka sepertinya menduplikasi garis sebelumnya.

aku melakukannya

<log3.txt head -n 880829 > log3new.txt

dan lari ddrescue (dengan infile menjadi perangkat loop dari file jarang besar, seharusnya tidak masalah). Ia mengeluh tentang garis 583658.

Ini adalah garis dengan lingkungannya:

# ...
0x186C6940000  0x00000200  +
0x186C6940200 A9520200  0x0001FE00  *  # <- this line here
0x24AA9540000  0x00000200  +
# ...

Untuk memperbaiki ini, Anda harus mencakup seluruh rentang dari 0x186C6940200 untuk 0x24AA9540000, jadi logfile berdekatan. Panjangnya 0x24AA9540000 - 0x186C6940200 = 0xC3E2BFFE00. Seluruh baris 583658 harus:

0x186C6940200 0xC3E2BFFE00 ?

dimana ? berarti blok yang belum dicoba.

Saya membuat perbaikan dengan

sed -i '583658s/.*/0x186C6940200 0xC3E2BFFE00 ?/' log3new.txt

File log yang dihasilkan valid untuk ddrescue.

EDIT

Masalah yang saya miliki adalah bahwa itu membuat DDrescue berpikir bahwa itu hanya pulih 2041GB sementara ketika kecelakaan itu terjadi di atas 2800GB dan seperti yang Anda bayangkan, 800GB terakhir ini membutuhkan waktu berminggu-minggu untuk dipulihkan.

Sebenarnya kita tidak tahu apakah itu sama dengan 800 GB. Ada sebuah alat ddrescueview (dengan GUI, tersedia sebagai ddrescueview paket di Ubuntu) yang akan menunjukkan kepada Anda di mana tepatnya blok yang belum dicoba ini kami perkenalkan. Perhatikan posisi saat ini di tempat lain:

Jadi saya bertanya-tanya apakah info setelah sampah mungkin ada hubungannya dengan itu? Bagaimana kami bisa memasukkannya ke dalam file log?

Saya telah mengisolasi bagian "setelah sampah" ini, baris 129289 terakhir:

tail -n 129289 log3.txt > extra.txt

Perintah ini akan menunjukkan kepada Anda baris yang ada di extra.txt tapi tidak di log3new.txt:

diff --suppress-common-lines extra.txt log3new.txt | grep -e '^<'

Outputnya adalah

< 0x13D75970200  0x00

Ini berarti hanya baris terakhir (tidak lengkap) dari setelah sampah tidak ada sebelum sampah di aslinya log3.txt. Maaf, menurut saya log3new.txt sudah menjadi yang terbaik yang bisa Anda dapatkan.