Czy jest jakiś sposób na przyspieszenie ratowania?

Miałem awarię dysku twardego o pojemności 500 GB około 5 dni temu. Użyłem ddrescuena ważnej partycji kilka dni temu, a od prawie 2 dni jest na „Przycinanie nieudanych bloków”.

Oryginalne polecenie:

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

Wyjście prądowe:

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...

W pierwotnym poleceniu użyto ddrescue -nparametru, a proces wznowiłem kilka razy w razie potrzeby (i wydawało się, że za każdym razem zaczynałem od początku).

Czy jest jakiś sposób na przyspieszenie tego procesu?

Edycja: sześć godzin później jest to aktualny stan:

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...

Wygląda na to, że podczas gdy „błędy” odliczają się niesamowicie powoli, ipos / opos odliczają ilość danych, które musi przerzucić, i wydaje się, że działa z prędkością 750 MB / godzinę. Przy tej szybkości zakończy się za około 53 godzin. Yikes.

Edycja nr 2: Dwa dni później nadal działa. Jest jednak nadzieja. Przeniosła się przez część „Przycinanie nieudanych bloków” i przechodzi do następnej fazy „Dzielenie nieudanych bloków”. Jeśli już, to należy odejść od przeglądania tego pytania, ponieważ na pewno zajmuje to dużo czasu, jeśli w grę wchodzi duża ilość danych / błędów. Mam tylko nadzieję, że uda mi się odzyskać niektóre ważne dane, gdy wszystko zostanie powiedziane i zrobione.

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...

Zauważyłem, że użycie opcji -n(bez podziału) wraz z -r 1(spróbuj ponownie raz) i ustawienie -c(rozmiaru klastra) na mniejszą wartość może pomóc.

Mam wrażenie, że krok podziału jest bardzo wolny, ponieważ ddrescuedzieli i ponownie rozdziela uszkodzone obszary. To zajmuje dużo czasu, ponieważ ddrescuepróbuje przywrócić bardzo małe porcje danych. Więc wolę używać -n(nie-split) wraz z -c 64, -c 32, -c 16, Aso

Prawdopodobnie -n(bez podziału) należy zawsze stosować przy pierwszym przejeździe w przód i w tył. Wydaje się, że im bardziej dane są dzielone, tym wolniej klonuje się, chociaż nie jestem tego pewien. Zakładam, że im większe nietraktowane obszary, tym lepiej przy ddrescueponownym uruchomieniu , ponieważ klonuje się więcej sąsiadujących sektorów.

Ponieważ używam pliku dziennika, nie waham się anulować polecenia za pomocą Ctrl+, Cgdy prędkość odczytu danych spadnie do dwóch.

Używam również -Rtrybu (wstecz) i po pierwszym przejściu często daje mi wyższe prędkości odczytu do tyłu niż do przodu.

Nie jest dla mnie jasne, jak -r Nobsługiwane są ponownie ponawiane sektory ( ) po ddrescueponownym uruchomieniu polecenia, szczególnie przy naprzemiennym wykonywaniu -Rpoleceń klonowania do przodu (domyślnie) i do tyłu ( ). Nie jestem pewien, czy liczba prób została zapisana w pliku dziennika i prawdopodobnie praca jest znowu bezużyteczna.

Prawdopodobnie -iflaga (pozycja wejściowa) może również pomóc przyspieszyć.

Postęp może być bardzo trudny ddrescue, ale zawiera inne polecenie o nazwie ddrescuelog.

Proste polecenie ddrescuelog -t YourLog.txtwyświetli te ładne informacje:

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%)

Możesz go nawet używać podczas ddrescuedziałania ...

Jeszcze jednym sposobem monitorowania postępu ddrescue (przynajmniej w Linuksie) jest użycie strace.

Najpierw znajdź PID dla procesu ddrescue za pomocą „ps aux | grep ddrescue”

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

Następnie uruchom „strace” przeciwko temu procesowi. Zobaczysz coś takiego:

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

...i tak dalej. Dane wyjściowe są szybkie i brzydkie, więc przepuszczam je przez „grep”, aby odfiltrować rzeczy, na których mi zależy:

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

W tym przykładzie „1702212676608” oznacza „ilość danych, które należy jeszcze przetworzyć na dysku o pojemności 2 TB, który próbujesz uratować”. (Tak. Ouch.) Ddrescue wyrzuca podobną liczbę - aczkolwiek jak „1720 GB” - na ekranie.

strace daje WIĘCEJ strumień danych o większej ziarnistości do zbadania; to jeszcze jeden sposób oceny prędkości ddrescue i oszacowania daty zakończenia.

Ciągłe działanie jest prawdopodobnie złym planem, ponieważ konkurowałby z programem ddrescue o czas pracy procesora. Zacząłem przesyłać go do „głowy”, aby móc pobrać pierwsze 10 wartości:

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

Mam nadzieję, że to komuś pomoże.

Jeśli Twoim celem jest uzyskanie nienaruszonej większości danych, możesz przyspieszyć ich wydobycie. Ale jeśli naprawdę chcesz uratować jak najwięcej danych, pozwolenie ddrecue skubać na każdym z nich jest właściwą drogą.

Odkryłem, że grając z parametrem -K można przyspieszyć. Z tego, co widziałem, jeśli ddrescue znajdzie błąd podczas działania z opcją -n próbuje przeskoczyć określoną liczbę sektorów. Jeśli nadal nie może odczytać, przeskakuje dwukrotnie. Jeśli masz duże uszkodzone obszary, możesz wskazać dużą wartość K (na przykład 100M), dzięki czemu przeskakiwanie po błędzie będzie większe za pierwszym razem i łatwiej będzie szybko uniknąć problematycznych obszarów w pierwszej przeszłości.

Nawiasem mówiąc, istnieje wspaniała aplikacja graficzna do analizy dziennika.

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

Jaki jest system plików dysku twardego, na którym zapisujesz obraz ratunkowy i plik dziennika? Właśnie zrobiłem wrażenie, że ratowanie 500 GB wewnętrznego dysku twardego (podłączonego przez SATA) na laptopie z Linux Mint z pamięci USB, zapisywanie obrazu ratunkowego i pliku dziennika na exFatsformatowanym dysku twardym USB, zaczynało się raczej powoli (1-2 MB / s), ale po około 250 GB indeksował tylko z prędkością <100 KB / s. Wydawało się, że im wolniej, tym większy był plik obrazu ratunkowego.

Następnie przeniosłem obraz ratunkowy i ext4plik dziennika do innego tymczasowego miejsca, ponownie sformatowałem dysk twardy USB za pomocą systemu plików, przeniosłem na niego pliki i wznowiłem proces ddrescue - a teraz znów działa z prędkością 1-20 MB / s (waha się ale średnio około 7 MB / s)!

Wydaje się, exFatże nie gra zbyt dobrze z bardzo dużymi plikami (kilkaset gigabajtów).

Aby uzyskać szybszą i szybką opcję ratowania dysku, możesz użyć pliku skryptu sh i uruchomić go za pomocą „sh filename.sh”. Zawiera pokazaną linię, wystarczy powtórzyć kilka razy „sudo ddrescue” i „sleep 3” jeszcze kilka razy, sen służy do zatrzymania napędu na kilka sekund, może być dobry z kilku powodów:

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

Opcja -r0 nie zawiera odpowiedzi. -E +0 oznacza wyjście przy błędzie 1. -T 1s kończy się z 1 sekundowym błędem odczytu. Istnieją opcje, które mogą być użyte jako -d dla bezpośredniego i -n dla braku zdrapywania, które mogą przyspieszyć.

Możesz użyć -R po zakończeniu z opcją -A jeden raz, który odwróci i usunie wszystkie błędy rozmiaru i zacznie od nowa od tyłu. Oznacza to, że będzie czytać błędy w różny sposób.

dd_rhelp to skrypt powłoki, który używa dd_rescue „[...] na całym dysku, ALE będzie próbował zebrać maksymalne prawidłowe dane przed próbą przez całe wieki na wiązkach złych”

jest dość stary (2012), ale nadal działa. nie próbowałem jeszcze ddrescue.