Bu ddrescue komutu bir şey yapıyor mu?


9

Çalışırken sırasında başarısız sabit diskten verileri kurtarmak , ben komutunu çalıştırıyorum ddrescue.

Komut 9 gündür çalışıyor ve disk etkinliğinin sesinden belki de bir şeyler yaptığını düşündüm. Komut satırı çıktısı tüm bu zaman boyunca az çok statik görünüyordu:

$ sudo ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile

Press Ctrl-C to interrupt
Initial status (read from logfile)
rescued:         0 B,  errsize:       0 B,  errors:       0
Current status
rescued:         0 B,  errsize:    500 GB,  current rate:        0 B/s
   ipos:     2539 MB,   errors:       1,    average rate:        0 B/s
   opos:     2539 MB,     time from last successful read:     9.7 d
Splitting failed blocks... 

Değişmekte olan bir kısım, söylediği yer iposve opos. 500000 MBArızalı disk sürücüsünün boyutu olan yaklaşık 9 gün sürdü . Ancak oraya vardığında, tekrar düştü 0ve tekrar yükselmeye başladı. Bunu yazarken, bu yaklaşık 2580 MBve sayıyor.

Oluşturulan görüntü dosyasının uzunluğu 0 bayttır.

Günlük dosyası yaklaşık 3 MB boyutundadır ve şöyle görünür:

# Rescue Logfile. Created by GNU ddrescue version 1.14
# Command line: ddrescue -r3 /dev/sdb /home/dave/RECOVERY/usb500.image /home/dave/recovery_usb500.logfile
# current_pos  current_status
0x975C3000     /
#      pos        size  status
0x00000000  0x00862000  -
0x00862000  0x00014800  /
0x00876800  0x00800400  -
~~~~~~edited for brevity ~~~~~~~~
0x74702CCE00  0x00320000  -
0x74705ECE00  0x00025800  /
0x7470612600  0x005F3A00  -

Bunun sadece zaman kaybı olduğunu ve hiçbir veri kurtarılmadığını düşünmeye başladım.

Bu çıktıdan faydalı bir şey olduğuna dair herhangi bir gösterge var mı?

ddrescueKomutun olduğu gibi devam etmesine izin vermek için herhangi bir neden var mı , yoksa durdurup başka bir şey yapmalı mıyım?


Bu, en son içeriği /var/log/syslog

Jun 10 07:29:17 homebase-i3 kernel: [568470.316436] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.316443] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.316450] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00
Jun 10 07:29:17 homebase-i3 kernel: [568470.316465] end_request: critical target error, dev sdb, sector 301925016
Jun 10 07:29:17 homebase-i3 kernel: [568470.346640] sd 5:0:0:0: [sdb] Unhandled sense code
Jun 10 07:29:17 homebase-i3 kernel: [568470.346646] sd 5:0:0:0: [sdb]  Result: hostbyte=invalid driverbyte=DRIVER_SENSE
Jun 10 07:29:17 homebase-i3 kernel: [568470.346651] sd 5:0:0:0: [sdb]  Sense Key : Medium Error [current] 
Jun 10 07:29:17 homebase-i3 kernel: [568470.346656] sd 5:0:0:0: [sdb]  Add. Sense: Unrecovered read error
Jun 10 07:29:17 homebase-i3 kernel: [568470.346662] sd 5:0:0:0: [sdb] CDB: Read(10): 28 00 11 ff 02 98 00 00 08 00

Yanıtlar:


8

Hala o sabit diskten veri ayıklamaya çalışıyorsanız ya da zaten başarılı olup olmadığınızı bilmiyorum, ancak başarılı olamadıysanız ve belki de kaybedip kurtaramayacağınızı görmek için bir şans vermek istiyorsanız Bitcoins veya her neyse, ddrescuekomut satırı parametrelerinizde birkaç değişiklik yaptım, aşağıdakileri ekledim:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R
  • - ddrescue'ya doğrudan disk erişimi kullanmasını söyleyen,
  • --Ddrescue'ya, okuma / yazma amacıyla kullanamayacağından şikayet etmesi durumunda günlük dosyanızı zorla kullanmasını ve okumasını / yazmasını söyleyen forforce
  • -R (evet, CAPITAL R ile) ddrescue, arızalı sabit sürücüyü ileri modda okumak yerine kurtarma işlemlerini tersine yapmayı söyler . Bazen ters okuma, hasar önemli olduğunda yardımcı olur, çünkü sorun olması durumunda sabit sürücünün önbelleğini atlar.

Şu anda bu komutları kullanıyorum ( 3[YET] 'in ddrescuekötü sektörleri yeniden denemesini istemediğim için komutu kullanmıyorum hariç , ilk süpürmem tamamlandıktan sonra bunu son olarak bırakacağım ve kurtarma konusunda büyük bir başarı elde ediyorum 1TB Seagate'imdeki veriler, 2009-2010 yıllarında madencilik yapıyor olabileceğim birkaç bitcoin tutuyor olabileceğine dair sabit diskte başarısız oldu, muhtemelen her biri 50 BTC'den 1 ila 3 blok buldum, umarım bu sabit diskte, işlemin ortalama 634 kbps okuma hızında tamamlanması toplamda 15 günden fazla sürecek.

Ayrıca, sabit disk sürücüsünün daha fazla okumayı reddedeceği bir durumla karşılaşacağınız "GÜNLÜK okuma etkinliği" nin 9 GÜNÜN önceki geçmiş kaydınıza dayanarak ve büyük olasılıkla, Durum, bir günlük dosyası kullandığınız için iptal etmek için CTRL + C tuşlarına basın, SATA kablosunu arızalı sabit sürücüden çıkarın, ancak USB denetleyicisini USB bağlantı noktasından çıkarın (evet, bağlantı yerine USB SATA denetleyicisi kullanın) sabit bir yeniden başlatmaya zorlamak için tüm bilgisayarınızı kilitlemeyecek ve daha sonra sabit sürücüyü yeniden başlatmak için SATA güç kaynağını tekrar takıp 10 saniye gibi bir süre vermeniz ve önceki terminalinizi yeniden yüklemek için yukarı veya aşağı oka basmanız gerekir. komutunu verin veddrescueçalışma, önceki günlüğünüz sayesinde en son kaldığı yerden devam edecek ve okuma yapılıyor olacak ve "son başarılı okuma" her zaman olması gereken yerde "0s" (sıfır saniye) olarak kalacaktır ddrescue. sabit sürücüden okuma ve "son okuma" öğesinin saniye saymaya başladığını fark ederseniz ddrescue, CTRL+ ile bir kez daha sonlandırın C, sabit sürücüyü kapatıp yeniden başlatınddrescue, "en son okunan" öğesinin kendi başına 0'lara geri dönüp dönmediğini görmek için hiçbir anlamı yoktur, deneyimlerime dayanarak asla olmayacak, sonsuzluğu bekleyeceksiniz. Kötü 1 TB sabit diskimi toplamda yaklaşık 20 kez tekrarlamak zorunda kaldım, 7 gün gibiydi ve 500GB kurtarılmış işaretine ulaşmaya çok yakınım, hala yarı yolda, umarım herhangi bir büyük başarısızlıkla karşılaşmayacağım Son 3 gündür kusursuz bir şekilde devam ettiği için% 100'e yaklaştım, yine 634 kbps'nin üzerinde.

Ayrıca, birçok parametreyi ve farklı blok boyutlarını denemeye çalışmam, güç döngüsünden sonra 1 saniyenin üzerinde çalışmayı durduracak tamamen ölü bir sert rive ile beni terk ettiğinden, daha hızlı bir veri çıkışı okuma hızı elde etmeye çalışırken açgözlü olmayın. (5 gün önceydi) ama neyse ki bir kez daha hayat belirtisi göstermeye başladı, başlangıçta 2.000 b'de (saniyede evet BYTES) okuma 2kbps'den biraz daha az, çok hayal kırıklığına uğradım, ancak iptal ettikten sonraddrescueCTRL + C ile ve sadece bir kez daha (-R ile tersine) parametresi eklendikten sonra, 930 kbps'de ileri okumadan önce hız 630'a geri döndü, en azından tersine 630 kbps yaptığım içerik ve 2kbps ile uğraşmak zorunda kalmamanız, bu yüzden 500 kbps aralık çubuğunda olduğu gibi herhangi bir okuma hızında başarı elde ederseniz ve hızları daha yükseğe itmek için hiçbir şey denemiyorsanız, bu son başarılı girişiminiz olabilir. herhangi bir okuma hızı.

Alternatif olarak, ddrescuesizin için iyi değilse, hangi parametreleri denediğinizden bağımsız olarak hiçbir şey okuyamazsanız, mantık kartını sabit sürücüden değiştirmeyi düşünebilirsiniz, çünkü zamanın% 90'ı Kötü, ama önce, mantık kartını çıkarın ve sabit sürücünün pimleri ile temas eden tüm temas noktalarını temizleyin, bazen bu temas noktaları siyahımsı bir gooey karışımı alır, başarısızlığınızın kaynağı olabilecek teması keser. Ancak, sabit sürücünüzün mantık kartını değiştirmeniz gerekiyorsa, aynı marka, seri numarası (yakın), model numarası, revizyon numarasından birini almanız gerekeceğinden, orijinaline yakın olması gerekir. bağış kurulu çalışmak.


2
Bu metin duvarını biraz aşağı doğru düzenlemek isteyebilirsiniz.
slm

4
Aslında bunun konuyla ilgili gördüğüm en yapıcı ve ayrıntılı gönderilerden biri olduğunu düşündüm. Umarım umursamıyorsunuz, sadece gerçekten yararlı katkınızdan bahseden benzer bir soru unix.stackexchange.com/q/219365/125662 ekledim
baroquedub

1
GNU ddrescue kılavuzundan: "--force Outfile üzerine yazmaya zorla. Outfile normal bir dosya değil, bir aygıt veya bölüm olduğunda gereklidir. Bu seçenek, bölümlerin yanlışlıkla imha edilmesini önlemek için sadece bir korumadır ve normal dosyalar için yok sayılır ." Bu , mapfile / logfile ile ilgili değildir .
Arch Linux Tux

Lütfen --forceseçeneğin açıklamasını düzeltin, doğru değil
endolith

5

İşlemini ddrescuekaldığı yerden (yakın) yeniden başlatabilmek için günlük dosyasını kullandığından durabilirsiniz . Ancak logfile zaman damgası bakarak veya yaparak güncellenmiş olup olmadığını kontrol ediyorum tail -f /home/dave/recovery_usb500.logfile.

Görüntü dosyanızın hala o kadar küçük olması, sürücüden henüz başarılı bir şekilde alınamamış olmasıyla ilgili olabilir. Ancak tüm bu zaman geçtikten sonra bu kötü bir sonuç olacaktır. Cihazda sadece birkaç bozuk blok bulunduğunu ve başlangıçta olmadıklarını varsayarsak, ilk giriş durumunuz olacaktır +. IIRC ddrescuebir hata bulana kadar okumaya başlar ve ardından diskin geri kalanını bölmeye başlar. Diskiniz en başından beri başarısız gibi görünüyor.

(Çoklu) bulunmadığı sürece +günlüğüne girişleri ve dosya boyutu yine olurdu 0sanmıyorum ddrescueyanlıştır. Bu +, sürücünüzden hiçbir şeyin kurtarılamayacağı anlamına gelmez. Bu, kızartılmış elektronik veya kötü bir kafa anlamına gelebilir, çünkü birkaç sektörün hatalı olması durumunda sonuçların daha hızlı olması gerekir.

Başka bir şey yapmaya gelince. Zaten normal dd ile birkaç blok okumaya çalıştığınızı varsayıyorum. Buna dayalı olarak sistem günlüğüne baktınız ve orada bulduğunuz tüm mesajları aradınız mı?


"Sonuç: hostbyte = geçersiz driverbyte = DRIVER_SENSE" araması, birkaç öneriyle daha ilginç birkaç okumaya (kısmen Almanca) neden olur:

  • 2.0 yerine USB 1.1 ile bağlanmayı deneyin
  • Sürücü ısınabilir, bu nedenle plastiğe sarın ve 10 dakika buzdolabına koyun, bu sürücü tekrar ısınmadan önce biraz okunabilirlik süresi sağlar.
  • SMART'ı BIOS'ta değiştirin (ve SATA'ya bağlayın).
  • USB sürücüsünün yeterli güce sahip olduğundan emin olun (ekstra güç kaynağı)
  • USB üzerinden okuma bir süre sonra başarısız olursa, programlı bir şekilde USB HUB'dan birkaç saniye boyunca sürücüye güç geçişi yaptığınız uzaktan kumandalı bir USB Hub kullanın.

Okunamayan bir diski (soğutma spreyi ile) soğutmanın yanı sıra bunlardan hiçbirini denemedim.


Yanıt verdiğiniz için teşekkürler. Bunun ddne olduğunu bilmediğim için "normal" denemedim . Bağırsak hissim, sürücünün ve verilerin çoğunun sağlam olduğu, ancak diskin bazı kritik alanlarında dizin oluşturma veya listeleme işlemlerinin yapıldığı bazı hatalar var.
Soru

Bir hatayla karşılaşıldığında bunun durmayan ddrescuebir türevi ddolduğunu düşünebilirsiniz . +İşaretleri kontrol ettin mi?
Anthon

Günlük dosyasında hiçbir +işaret yoktur . Sadece vardır -ve \ işaretler.
Soru

Bu, henüz hiçbir şey geri kazanılmadığı anlamına gelir ve sanırım ddrescuebunca zaman sonra başlaması pek olası değildir . İsterseniz bu konuda sohbet edebiliriz (bu sayfanın üst kısmına bağlantı)
Anthon

Sorusunun içeriğini ekledim /var/log/syslog.
Soru
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.