Kurtarma işlemini hızlandırmanın bir yolu var mı?

Yaklaşık 5 gün önce 500GB'lık bir HDD sürücü kazası geçirdim. ddrescueBirkaç gün önce önemli bölümlerde kullandım ve neredeyse 2 gündür "Başarısız blokları kırmak" üzerindeydi.

Orijinal komut:

ddrescue -n /dev/rdisk1s2 /Volumes/OSXBackup/rdisk1s2.img /Volumes/OSXBackup/rdisk1s2.log

Akım çıkışı:

Initial status (read from logfile)
rescued:   248992 MB,  errsize:   1007 MB,  errors:   15867
Current status
rescued:   249021 MB,  errsize:    978 MB,  current rate:    17408 B/s
   ipos:    44405 MB,   errors:   15866,    average rate:     2784 B/s
   opos:    44405 MB,     time from last successful read:       0 s
Trimming failed blocks...

Orijinal komut ddrescue -nparametreyi kullandı ve işlemi gerektiği kadar birkaç kez yeniden başlattım (ve her seferinde bıraktığı yerden devam ediyor gibiydi).

Bu süreci hızlandırmanın bir yolu var mı?

Düzenleme: Altı saat sonra, şu anki durum:

rescued:   249079 MB,  errsize:    920 MB,  current rate:      409 B/s
   ipos:    39908 MB,   errors:   15851,    average rate:     2698 B/s
   opos:    39908 MB,     time from last successful read:       0 s
Trimming failed blocks...

"Hatalar" çok yavaş yavaş geri sayıyor olsa da, ipos / opos ne kadar veriyi harmanlaması gerektiğini sayıyor ve saatte 750 MB / saat hızında çalışıyor gibi görünüyor. Bu hızla, ~ 53 saat içinde tamamlanacaktır. Amanın.

Düzenleme # 2: İki gün sonra hala çalışıyor. Ancak, umut var. "Kırpma başarısız bloklar" bölümünü ve bir sonraki aşamaya geçerek "Başarısız blokları bölme" ye geçti. Herhangi bir şey varsa, bu soruyu görmekten uzak durulması gereken, bunun iyi miktarda veri / hata söz konusu olduğunda kesinlikle uzun zaman alacağıdır. Tek umudum, tüm söylendiğinde ve yapıldığında bazı önemli verileri başarılı bir şekilde kurtarabilmemdir.

rescued:   249311 MB,  errsize:    688 MB,  current rate:        0 B/s
ipos:    26727 MB,   errors:   15905,    average rate:     1331 B/s
opos:    26727 MB,     time from last successful read:      20 s
Splitting failed blocks...

-n(Ayrılmamış) seçeneğini birlikte kullanmanın -r 1(bir kez yeniden dene) ve -c(küme boyutu) ayarının daha küçük bir değere ayarlanmasının yardımcı olabileceğini gözlemledim .

Benim izlenimim, bölünme adımının çok yavaş olduğu ddrescueve hasarlı alanları tekrar böldüğü kadar yavaş olmasıdır . Bu çok zaman alır çünkü ddrescueçok küçük veri bölümlerini geri yüklemeye çalışır. Yani, kullanmayı tercih -nile birlikte (no-bölünmüş) -c 64, -c 32, -c 16, aso

Muhtemelen -n(ayrılmamış) her zaman ileri ve geri yönlerde ilk geçiş için kullanılmalıdır. Veriler ne kadar fazla bölünmüş görünüyorsa, klonlama o kadar yavaş olur, ancak bundan emin değilim. Tedavi edilmeyen alanların daha büyük olduğunu, ddrescuetekrar çalıştırmanın en iyi olduğu varsayılıyor çünkü daha bitişik sektörler klonlamak zorunda.

Bir günlük dosyası kullandığım için , veri okuma hızı iki düşük olduğunda komutu Ctrl+ ile iptal etmekte tereddüt etmiyorum C.

Ayrıca -R(Geri) modunu da kullanıyorum ve ilk seferden sonra bana ileri geri okumadan daha yüksek hızlar veriyor.

Komutu tekrar -r Nçalıştırırken ddrescue, özellikle ileri (varsayılan) ve geri ( -R) klonlama komutlarını değiştirirken, yeniden denenmiş sektörlerin ( ) nasıl işlendiği açık değil . Denendiklerinin sayısının logfile içerisinde saklanıp saklanmadığından emin değilim ve muhtemelen iş yine işe yaramaz hale geliyor.

Muhtemelen -i(giriş konumu) bayrağı da işleri hızlandırmaya yardımcı olabilir.

İlerlemesini görmek çok zor olabilir ddrescueama buna dahil olan başka bir komut daha var ddrescuelog.

Basit bir komut ddrescuelog -t YourLog.txtbu güzel bilgileri verecektir:

current pos:     2016 GB,  current status: trimming
domain size:     3000 GB,  in    1 area(s)
rescued:     2998 GB,  in 12802 area(s)  ( 99.91%)
non-tried:         0 B,  in    0 area(s)  (  0%)

errsize:     2452 MB,  errors:   12801  (  0.08%)
non-trimmed:   178896 kB,  in 3395 area(s)  (  0.00%)
non-split:     2262 MB,  in 9803 area(s)  (  0.07%)
bad-sector:    10451 kB,  in 19613 area(s)  (  0.00%)

Çalışırken bile kullanabilirsiniz ddrescue...

Kurtarma çalışmalarının ilerlemesini izlemenin bir başka yolu (en azından Linux'ta) strace kullanımıdır.

İlk önce, "ps aux | grep ddrescue" kullanarak kurtarma işlemi için PID'yi bulun

root@mojo:~# ps aux | grep ddrescue
root     12083  0.2  0.0  15764  3248 pts/1    D+   17:15   0:04 ddrescue --direct -d -r0 /dev/sdb1 test.img test.logfile
root     12637  0.0  0.0  13588   940 pts/4    S+   17:46   0:00 grep --color=auto ddrescue

Sonra bu sürece karşı "strace" çalıştırın. Gibi bir şey göreceksiniz:

root@mojo:~# strace -p 12083
Process 12083 attached - interrupt to quit
lseek(4, 1702220261888, SEEK_SET)       = 1702220261888
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(3, 1702220261376, SEEK_SET)       = 1702220261376
read(3, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
lseek(4, 1702220261376, SEEK_SET)       = 1702220261376
write(4, "\3101\316\335\213\217\323\343o\317\22M\346\325\322\331\3101\316\335\213\217\323\343o\317\22M\346\325\322\331"..., 512) = 512
^C

...ve bunun gibi. Çıktı hızlı ve çirkin, bu yüzden umurumda olan şeyleri filtrelemek için "grep" içerisinden geçiriyorum:

root@mojo:/media/u02/salvage# nice strace -p 12083 2>&1|grep lseek
lseek(4, 1702212679168, SEEK_SET)       = 1702212679168
lseek(3, 1702212678656, SEEK_SET)       = 1702212678656
lseek(4, 1702212678656, SEEK_SET)       = 1702212678656
lseek(3, 1702212678144, SEEK_SET)       = 1702212678144
lseek(4, 1702212678144, SEEK_SET)       = 1702212678144
lseek(3, 1702212677632, SEEK_SET)       = 1702212677632
lseek(4, 1702212677632, SEEK_SET)       = 1702212677632
lseek(3, 1702212677120, SEEK_SET)       = 1702212677120
lseek(4, 1702212677120, SEEK_SET)       = 1702212677120
lseek(3, 1702212676608, SEEK_SET)       = 1702212676608
^C

Bu örnekte, "1702212676608", "kurtarmaya çalıştığınız 2 Tb diskte hala işlenmesi gereken veri miktarına" eşittir. (Evet. Ouch.) Ddrescue, "1720 GB" olmasına rağmen - benzer bir sayıyı ekran çıktısına veriyor.

strace, incelemeniz için size daha yüksek bir ayrıntı düzeyi veri akışı sağlar; ddrescue hızını değerlendirmek ve bir bitiş tarihi tahmin etmek için bir yol daha.

Sürekli çalıştırılması muhtemelen kötü bir plandır çünkü CPU süresi için kurtarma aracıyla rekabet eder. Boruları "kafa" ya bağladım, böylece ilk 10 değeri alabilirim:

root@mojo:~# strace -p 4073 2>&1 | grep lseek | head

Umarım bu birine yardımcı olur.

Amacınız bozulmamış verilerin çoğunu elde etmekse, çıkarılmasını hızlandırabilirsiniz. Ancak, gerçekten mümkün olduğunca fazla veri kurtarmak istiyorsanız, o zaman her yoldan ddrecue'yu nibble edin.

-K parametresiyle oynamanın işleri hızlandıracağını öğrendim. Ddrescue, -n seçeneğiyle çalışırken bir hata bulursa, sabit miktarda sektör atlamaya çalışır. Hala okuyamıyorsa, iki katına atlar. Büyük hasarlı alanlarınız varsa, büyük bir K değeri (örneğin 100M) belirtebilirsiniz ve bu nedenle bir hataya atlamak ilk kez daha büyük olacak ve ilk önce sorunlu alanlardan hızlıca kaçınmak kolaylaşacaktır.

Bu arada, günlüğü analiz etmek için harika bir grafik uygulama var.

http://sourceforge.net/projects/ddrescueview/

Kurtarma görüntüsünü ve günlük dosyasını kaydettiğiniz sabit diskin dosya sistemi nedir? Bir USB Stick'ten Linux Mint çalıştıran bir Dizüstü bilgisayarda 500 GB dahili sabit diski kurtarmanın (SATA aracılığıyla bağlı) kurtardığını, kurtarma görüntüsünün kaydedildiğini ve exFatbiçimlendirilmiş bir USB sabit diskte logfile uygulamasının oldukça yavaş başladığını deneyimledim (1-2 MB / sn) ancak 250 GB civarında bir süreden sonra sadece <100KB / sn hızında sürünüyordu. Kurtarma görüntü dosyası büyüdükçe büyüdükçe yavaşladı.

Sonra kurtarma görüntüsünü ve kayıt ext4dosyasını başka bir geçici yere taşıdım, USB sabit sürücüyü dosya sistemiyle yeniden biçimlendirdim , dosyaları tekrar üzerine getirdim ve kurtarma işlemini sürdürdüm - ve şimdi tekrar 1-20 MB / sn ile çalışıyor (dalgalanıyor) ama ortalama olarak 7MB / sn civarında)!

Görünüşe göre exFatçok büyük dosyalarla (birkaç yüz gigabayt) çok iyi oynamıyor.

Diski kurtarmak için daha hızlı ve hızlı bir seçenek olarak, bir sh betiği dosyası kullanabilir ve dosyayı "sh filename.sh" ile çalıştırabilirsiniz. Gösterilen bu satırı, sadece "sudo kurtarma" ve "uyku 3" 'ü birkaç kez tekrarlayın, uyku sürücüyü birkaç saniye dinlendirmek için kullanılır, bazı nedenlerden dolayı iyi olabilir:

#! /bin/sh -e  
sudo ddrescue -d -r0 -e +0 -T 1s -n /dev/drivepartition file.img log.logfile 
sleep 3

-R0 yanıt vermedi. -E +0 1 hatası çıkış içindir. -T 1s, 1 saniye başarısız okuma ile çıkar. Hızlandırabilecek hiçbir kazıma için direk olarak -d, -n olarak kullanılabilecek seçenekler var.

-A komutunu bitirdikten sonra -R'yi bir kez kullanabilirsiniz, bu tüm hata boyutlarını tersine çevirir ve geriye doğru başlatır. Farklı hataları okuyacağı anlamına gelir.

dd_rhelp , tüm diskinizde dd_rescue "[...] 'yu kullanan bir kabuk betiğidir, ANCAK, badsector gruplarında yaşları denemeden önce maksimum geçerli veriyi toplamaya çalışacaktır."

oldukça eski (2012) ama hala çalışıyor. kurtarma programını henüz denemedim.