Miałem awarię dysku twardego o pojemności 500 GB około 5 dni temu. Użyłem ddrescue
na 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 -n
parametru, 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...
źródło
-M
na wypadek, gdyby dzisiejsze rano ponowne uruchomienie i aktualizacja spowodowały jakiś bałagan)Odpowiedzi:
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ż
ddrescue
dzieli i ponownie rozdziela uszkodzone obszary. To zajmuje dużo czasu, ponieważddrescue
próbuje przywrócić bardzo małe porcje danych. Więc wolę używać-n
(nie-split) wraz z-c 64
,-c 32
,-c 16
, AsoPrawdopodobnie
-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 przyddrescue
ponownym 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ż
-R
trybu (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 N
obsługiwane są ponownie ponawiane sektory ( ) poddrescue
ponownym uruchomieniu polecenia, szczególnie przy naprzemiennym wykonywaniu-R
poleceń 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
-i
flaga (pozycja wejściowa) może również pomóc przyspieszyć.źródło
Postęp może być bardzo trudny
ddrescue
, ale zawiera inne polecenie o nazwieddrescuelog
.Proste polecenie
ddrescuelog -t YourLog.txt
wyświetli te ładne informacje:Możesz go nawet używać podczas
ddrescue
działania ...źródło
errsize: 289420 MB, errors: 34926 ( 7.23%) non-trimmed: 288130 MB, in 105407 area(s) ( 7.20%) non-split: 1243 MB, in 185 area(s) ( 0.03%) bad-sector: 47490 kB, in 92728 area(s) ( 0.00%)
(... ale dzięki stosy dla polecenia!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”
Następnie uruchom „strace” przeciwko temu procesowi. Zobaczysz coś takiego:
...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:
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:
Mam nadzieję, że to komuś pomoże.
źródło
strace -e lseek …
na to - choćpv -d <pid>
może być ładniejsza.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ą.
źródło
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/
źródło
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
exFat
sformatowanym 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
ext4
plik 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).źródło
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:
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.
źródło
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.
źródło