Bagaimana cara memperkirakan loop / waktu untuk penyelesaian ddrescue GNU (1.18.1) menggunakan status saat ini?


9

Latar belakang / konteks:

Saat ini saya sedang menjalankan GNU ddrescue 1.18.1 untuk memulihkan data dari USB yang mengalami pemutusan kabel saat saya sedang menulis gambar disk virtual ke partisi disk2s1. Awalnya saya memulihkan partisi kedua saya (disk2s2) dan perhatikan bahwa saya telah mencapai tahap ketiga (Memisahkan). Saya menempatkan gambar ke penyimpanan jaringan.

Pertanyaan:

Saya perhatikan bahwa fase ini berulang. Apakah ada cara untuk menghitung jumlah loop yang mungkin saya alami, mengingat informasi status saya saat ini (saya hanya menunjukkan dua kesalahan)?

Status:

status

Perbarui / Edit:

Jadi saya masih sangat tertarik pada bagaimana seseorang dapat memperkirakan loop / waktu untuk penyelesaian menggunakan alat ddrescue. Per komentar, saya menambahkan evaluasi file log untuk partisi disk2s1 saya karena sedang berjalan (disk2s2 telah selesai setelah 14,5 jam, dengan satu gangguan pengguna selama sekitar 6 jam).

part1-log

Log Partisi yang Selesai

Untuk partisi yang baru saja selesai, berikut adalah hasil pemeriksaan log.

foto-log

Referensi (catatan algoritme ddrescue):

4 Algoritma


GNU ddrescue bukan merupakan turunan dari dd, juga tidak terkait dengan dd dengan cara apa pun kecuali bahwa keduanya dapat digunakan untuk menyalin data dari satu perangkat ke perangkat lainnya. Perbedaan utama adalah bahwa ddrescue menggunakan algoritma yang canggih untuk menyalin data dari drive yang gagal menyebabkan kerusakan sesedikit mungkin.

Ddrescue mengelola secara efisien status penyelamatan yang sedang berlangsung dan mencoba menyelamatkan bagian yang baik terlebih dahulu, penjadwalan membaca di dalam area yang buruk (atau lambat) untuk nanti. Ini memaksimalkan jumlah data yang akhirnya dapat dipulihkan dari drive yang gagal.

Utilitas dd standar dapat digunakan untuk menyimpan data dari drive yang gagal, tetapi membaca data secara berurutan, yang mungkin aus drive tanpa menyelamatkan apa pun jika kesalahan ada di awal drive.

Program lain membaca data secara berurutan tetapi beralih ke pembacaan ukuran kecil ketika mereka menemukan kesalahan. Ini adalah ide yang buruk karena itu berarti menghabiskan lebih banyak waktu di area kesalahan, merusak permukaan, kepala dan mekanisme penggerak, alih-alih keluar secepat mungkin. Perilaku ini mengurangi kemungkinan penyelamatan data baik yang tersisa.

Algoritma ddrescue adalah sebagai berikut (pengguna dapat mengganggu proses pada titik mana pun, tetapi perlu diketahui bahwa drive yang buruk dapat memblokir ddrescue untuk waktu yang lama sampai kernel menyerah):

1) Secara opsional, baca file log yang menjelaskan status penyelamatan multi-bagian atau yang sebelumnya terputus. Jika tidak ada file log yang ditentukan atau kosong atau tidak ada, tandai semua domain penyelamatan sebagai tidak dicoba.

2) (Fase pertama; Menyalin) Baca bagian-bagian yang tidak dicoba dari file input, tandai blok yang gagal sebagai tidak terpangkas dan melompati di luarnya. Lewati juga di luar area yang lambat. Area yang dilewati akan dicoba kemudian dalam dua lintasan tambahan (sebelum pemotongan), membalikkan arah setelah setiap lintasan sampai semua domain penyelamatan dicoba. Pass ketiga adalah sweeping pass, dengan lompatan dinonaktifkan. (Tujuannya adalah untuk membatasi kesalahan besar dengan cepat, menjaga logfile tetap kecil, dan menghasilkan titik awal yang baik untuk pemangkasan). Hanya area yang belum dicoba dibaca dalam blok besar. Pemangkasan, pemisahan dan coba lagi dilakukan sektor demi sektor. Setiap sektor paling banyak dicoba dua kali; yang pertama dalam langkah ini (biasanya sebagai bagian dari blok besar dibaca, tetapi kadang-kadang sebagai sektor tunggal dibaca), yang kedua di salah satu langkah di bawah ini sebagai sektor tunggal dibaca.

3) (Fase kedua; Pemangkasan) Baca maju satu sektor pada satu waktu dari tepi terkemuka dari blok non-terpangkas terkecil, sampai sektor yang buruk ditemukan. Kemudian baca mundur satu sektor pada satu waktu dari tepi trailing dari blok yang sama, sampai ditemukan sektor yang buruk. Untuk setiap blok yang tidak dipangkas, tandai sektor buruk yang ditemukan sebagai sektor buruk dan tandai sisa blok tersebut sebagai non-split tanpa mencoba membacanya. Ulangi sampai tidak ada lagi blok yang tidak terpangkas. (Blok non-trim besar diproduksi oleh gabungan dari yang lebih kecil, dan fraksi data yang baik di tepi karenanya lebih kecil).

4) (Tahap ketiga; Pemisahan) Baca maju satu sektor pada satu waktu dari pusat blok non-split terbesar, sampai ditemukan sektor yang buruk. Kemudian, jika bad sector ditemukan bukan yang pertama dicoba, baca mundur satu per satu sektor dari pusat blok yang sama, sampai ditemukan bad sector. Jika logfile lebih besar dari '--logfile-size', baca secara berurutan blok non-split terbesar sampai jumlah entri dalam logfile turun di bawah '--logfile-size'. Ulangi sampai semua blok non-split yang tersisa memiliki kurang dari 7 sektor. Kemudian baca sisa blok non-split secara berurutan.

5) (Fase keempat; Coba lagi) Secara opsional cobalah membaca lagi bad sector sampai jumlah yang ditentukan coba lagi tercapai. Setiap bad sector dicoba hanya sekali dalam setiap pass. Ddrescue tidak dapat mengetahui apakah sektor yang buruk tidak dapat dipulihkan atau apakah pada akhirnya akan dibaca setelah beberapa percobaan ulang.

6) Secara opsional menulis file log untuk digunakan nanti.

Ukuran kesalahan total ('errsize') adalah jumlah dari semua blok yang tidak dipangkas, tidak terpecah dan sektor buruk. Ini meningkat selama fase penyalinan dan dapat berkurang selama pemangkasan, pemisahan, dan coba lagi. Perhatikan bahwa saat ddrescue memecah blok yang gagal, membuatnya lebih kecil, ukuran kesalahan total dapat berkurang sementara jumlah kesalahan meningkat.

File log secara berkala disimpan ke disk, juga ketika ddrescue selesai atau terganggu. Jadi jika terjadi kecelakaan, Anda dapat melanjutkan penyelamatan dengan sedikit penyalinan ulang. Interval antara penyimpanan bervariasi dari 30 detik hingga 5 menit tergantung pada ukuran file log (file log yang lebih besar disimpan pada interval yang lebih lama).

Juga, file log yang sama dapat digunakan untuk beberapa perintah yang menyalin area berbeda dari file input, dan untuk beberapa upaya pemulihan melalui subset yang berbeda. Lihat contoh ini:

Pertama-tama, selamatkan bagian terpenting dari disk. ddrescue -i0 -s50MiB / dev / hdc hdimage logfile ddrescue -i0 -s1MiB -d -r3 / dev / hdc hdimage logfile

Kemudian selamatkan beberapa area disc utama. ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

Sekarang selamatkan sisanya (tidak menyalin kembali apa yang sudah dilakukan). ddrescue / dev / hdc hdimage logfile ddrescue -d -r3 / dev / hdc hdimage logfile


Apakah disk masih terhubung dengan nama perangkat yang sama? Juga Anda ddrescuehanya perlu jika disk memiliki blok buruk, yang tidak akan disebabkan oleh "kabel putus". Jika Anda memiliki masalah kabel, coba saja kabel yang berbeda ...
frostschutz

@TommieC. dapatkah kamu mencoba ddrescuelog -t YourLog.txtdi terminal lain?
Simply_Me

@Simply_Me Silakan lihat pertanyaan yang diperbarui yang mencerminkan dua hasil.
Tommie C.

@frostschutz Silakan lihat pertanyaan yang diperbarui untuk detail lebih lanjut. Sambungan kabel yang hilang terjadi saat disk sedang menulis dan menyebabkan masalah dengan tabel partisi. Kabel itu sendiri tidak rusak.
Tommie C.

Putuskan kabel biasanya akan menyebabkan kesalahan logis (mis. Data pada disk tidak 100% valid), tetapi tidak akan menyebabkan masalah fisik dengan drive - kecuali Anda menjatuhkannya pada saat yang bersamaan. ddrescuehanya dapat mencoba memulihkan masalah fisik dan tidak akan membantu dengan kesalahan logis sama sekali. Untuk yang terakhir, coba fsckatau sama-sama ..
Udo G

Jawaban:


6

Meskipun pertanyaan diajukan 10 bulan yang lalu, jawabannya mungkin relevan karena siklus pemulihan mungkin masih berjalan tergantung pada beberapa faktor! Tidak ada pelesetan yang dimaksudkan.

Alasannya adalah, perkiraan waktu hampir tidak mungkin, namun kadang-kadang Anda bisa mendapatkan ide kasar sebagai berikut. Salah satu alasan yang paling jelas adalah bahwa Anda tidak dapat memprediksi berapa lama waktu yang dibutuhkan untuk membaca sektor yang buruk dan jika Anda ingin ddrescue membaca dan mencoba kembali setiap sektor, maka itu bisa memakan waktu yang sangat lama. Misalnya, saya sedang menjalankan pemulihan pada drive 500GB kecil yang telah berlangsung selama lebih dari 2 minggu dan saya mungkin memiliki beberapa hari lagi. Tapi milik saya adalah situasi yang lebih rumit karena drive dienkripsi dan untuk membaca sesuatu dengan sukses, saya harus memastikan untuk mendapatkan semua sektor yang memiliki tabel partisi, sektor boot dan bagian penting lainnya dari disk. Saya menggunakan teknik selain ddrescue untuk meningkatkan peluang saya untuk semua sektor buruk. TKI,

Dengan memperkirakan "loop", jika Anda berarti jumlah percobaan ulang maka itu adalah sesuatu yang Anda tentukan oleh parameter yang Anda gunakan. Jika Anda maksud "jumlah total lintasan", itu mudah ditentukan dengan membaca tentang algoritma di sini .. > man ddrescue </ Algoritma: Bagaimana ddrescue memulihkan data

Saya akan secara khusus berbicara dengan angka di layar menangkap yang Anda berikan. Situasi lain mungkin memiliki faktor lain yang berlaku, jadi ambil informasi ini sebagai pedoman umum.

Dalam sampel yang Anda berikan lihat layar status ddrescue yang sedang berjalan. Kami mendapatkan "taksiran" total masalah (domain penyelamatan) dengan "errsize". Ini adalah jumlah data yang "belum dibaca". Dalam sampel itu adalah 345GB. Baris berikutnya di bawah ini adalah "rata-rata tarif". Dalam sampel itu adalah 583 kb / s

Jika "tingkat rata-rata" tetap dekat dengan stabil, ini berarti Anda memiliki 7 hari lagi. 345 GB / (583 kb * 60 * 60 * 24) = 7.18 Namun masalahnya adalah Anda tidak dapat mengandalkan 583kb / s. Bahkan lebih dalam Anda masuk ke pemulihan, drive menjadi lebih lambat karena membaca lebih banyak dan lebih sulit dan melakukan lebih banyak percobaan ulang. Jadi waktu untuk menyelesaikan meningkat secara eksponensial. Semua ini tergantung pada seberapa parah drive rusak.

Sampel yang Anda berikan menunjukkan "bacaan sukses" lebih dari 10 jam yang lalu. Itu mengatakan bahwa itu tidak benar-benar mendapatkan apa pun dari drive selama 10+ jam. Ini menunjukkan bahwa drive Anda mungkin memiliki 345GB nilai (atau sebagian) pengambilan data. Ini berita buruk bagi Anda.

Sebaliknya, drive 500GB kedua saya yang baru saja mulai memberi saya kesalahan "SMART", disalin disk ke disk (dengan file log pada drive lain) dan seluruh operasi memakan waktu sekitar 8-9 jam. Bagian terakhir melambat. Tapi itu masih bisa diterima. Sementara drive yang sangat buruk, seperti disebutkan di atas sudah melewati 2 minggu bekerja pada 500GB dan masih memiliki sekitar 4-5% yang tersisa untuk pulih.

HTH dan YMMV

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.