ddrescue bardzo wolno, pisząc do NTFS - czy warto teraz konwertować na Ext4?

Dwa dni temu zacząłem odzyskiwać dysk twardy o pojemności 1 TB, który został mi przekazany z nadzieją, że uda mi się go uratować za niską cenę.

Początkowo zachowywało się nieregularnie, często nagle odłączało się i wydawało przerażające dźwięki, a prędkość kopiowania wahała się od kilku KB na sekundę do około 50 MB na sekundę (był to gorący dzień, starałem się zapobiec przegrzaniu za pomocą podkładki chłodzącej do laptopa) pod spodem i blok chłodzący nad nim, który zmieniłem co godzinę). Następnie, pierwszego wieczoru, stał się bardziej stabilny, ale średnia prędkość kopiowania znacznie spadła, do około 3-4 MB / s. Teraz, po odzyskaniu 250 GB, jestem średnio do około 400 KB / s, co jest boleśnie powolne (przynajmniej nie wydaje się, aby dalej spadało).

Moje pytania to:

• Robię to odzyskiwanie na partycji NTFS, która z tego, co czytałem dość późno (on ten francuski przewodnik ), nie jest zalecane, ponieważ może znacznie spowolnić proces odzyskiwania. Czy to (nadal) jest prawdziwe, a jeśli tak, to dlaczego?
  • A może to już przeszłość, kiedy sterownik NTFS dla Linuksa nie był wystarczająco dojrzały? (Używam najnowszego Knoppix Live DVD, skopiowanego na kartę pamięci, ponieważ nie udało się uruchomić z płyty DVD-RW.)
• Czy na tym etapie warto byłoby przekonwertować partycję na natywny format Linuksa, taki jak Ext4? Czy to znacznie poprawiłoby prędkość kopiowania?
  • Czy może normalne jest takie spowolnienie z powodu awarii dysku, po pierwszym przejściu, gdzie większość „zdrowych” sektorów została już odzyskana? (Parametry SMART pogarszają się, „wynik testu ogólnej samooceny zdrowia” przechodził z „PASSED” na „FAILED”, liczba realokowanych sektorów wzrosła ze 144 do 1360).
• Czy jest jeszcze coś, co mogę zrobić, aby poprawić współczynnik odzysku i / lub szybkość odzyskiwania?
• Czy są opcje w ddrescue co mógłbym wypróbować z prawdziwymi korzyściami?

Pierwsze uruchomienie wykonałem za pomocą tego polecenia:

ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log

(The -n & amp; -N przełączniki przypuszczalnie omijają fazy zgarniania i przycinania - chociaż nie jestem pewien, w którym momencie procesu te akcje są podejmowane przez program i czy jest to rzeczywiście przydatne do ich ominięcia. Następnie określiłem minimalną prędkość kopiowania 500000 bajtów na sekundę i wartość 1 MB dla „początkowego rozmiaru do pominięcia przy błędzie odczytu”, próbując jak najszybciej skopiować obszary, które są nadal zdrowe lub łatwo dostępne. The -u jest dla „jednokierunkowego”: w poprzednim odzyskiwaniu z innym dyskiem twardym, kopiowanie w odwrotnym kierunku za pomocą -R przełącznik wydawał się poprawiać sprawy, ale z tym wydaje się siać spustoszenie, a ten przełącznik wydaje się bardziej stabilny.

Teraz, po zakończeniu jednego przejścia, usunąłem większość tych parametrów, zachowując tylko -u. Próbowałem -d w pewnym momencie („użyj bezpośredniego dostępu do dysku”), ale wtedy nic nie zostało skopiowane, „rozmiar błędu” bardzo szybko się zwiększył.

Aby uzupełnić moje komentarze powyżej (przepraszam za formalne niedogodności / niespójności): Powiedziałbym, że było warto, mimo że nie do końca rozumiem dlaczego. Druga próba, odzyskiwanie do partycji Ext4, miała znacznie wyższą szybkość kopiowania na początku (średnio około 90 MB / s, podczas gdy w pierwszej próbie miałem tylko około 50 MB / s, odzyskiwanie na partycję NTFS) i bez błędów, a nawet spowolnień. Ale potem, po skopiowaniu około 165 GB (tak wcześniej niż wcześniej), stał się bardzo niestabilny i spowolnił do pełzania, ponownie klikał i szumiał (był to bardzo gorący okres, który nie pomógł - próbowałem go ochłodzić jak najdalej, używając podkładki chłodzącej laptopa poniżej i zamrożonego opakowania, zmieniane co godzinę); Próbowałem raz po raz (czasami wracało do szybkości 120 MB / s przez kilka sekund, a potem z powrotem do 0), ale musiałem porzucić to po chwili.

Tutaj jest ddrescueview mapa pierwszego odzyskiwania:

Istnieje ciekawy wzór z paskami łatwo odzyskanych danych na przemian z bardzo wolnymi lub nieczytelnymi danymi. Z tego, co wiem, zdaje się wskazywać, że głowa stykała się z talerzem, uszkadzając powierzchnię i uwalniając pył magnetyczny, który następnie rozprzestrzeniał się wraz z siłą odśrodkową. A ponieważ ścieżka serwo (która zawiera istotne informacje dla procesu uruchamiania) znajduje się na zewnętrznej krawędzi dysku twardego (jest to 3,5-calowy Hitachi 1 TB), część tego pyłu mogła do niego dotrzeć, co utrudnia dostęp, co może tłumaczyć częste kliknięcia przy starcie (popraw mnie, jeśli się mylę).

Tutaj jest ddrescueview mapa drugiego odzyskiwania:

Tak więc dysk twardy stał się bardzo niestabilny, a odzyskiwanie coraz trudniejsze po około 165 GB, ale wcześniej tempo kopiowania było stale wysokie, bez pominiętych obszarów. Później użyłem ddru_ntfsbitmap metoda, dla ostatnich prób, więc wolna przestrzeń była przeważnie pomijana.

Tutaj jest ddrescueview mapa pliku dziennika utworzonego za pomocą ddru_ntfsbitmap, pokazując obszary dysku twardego zawierające rzeczywiste dane w kolorze zielonym oraz wolne miejsce w kolorze szarym:

Na szczęście większość rzeczywistych danych została zlokalizowana w pierwszym kwartale i została pomyślnie odzyskana. Teraz muszę połączyć dobre części tych dwóch obrazów i wyodrębnić rzeczywiste pliki, prawdopodobnie z R-Studio (najlepsze oprogramowanie do odzyskiwania danych, które próbowałem).

Jedna rzecz, którą później odkryłem, jest interesująca i osobliwa, jeśli chodzi o moje pierwsze pytanie (chyba powinienem był to umieścić jako komentarz, zgodnie z zasadami formalnymi, ale byłby zbyt długi i nie mogłem dostarczyć zrzutów ekranu) .

Próbowałem skopiować uratowane obszary obrazu 2 na partycję Ext4, której brakowało na obrazku 1, do tego obrazu 1, na partycji NTFS ^{1} , co powinno być zrobione z bardzo dużą szybkością (wejście i wyjście są na zdrowym dysku twardym o pojemności 2 TB), ale mam szybkość, zgadnijcie, tylko 660 KB / s średnio!

Polecenie użyte (plik dziennika dla obrazu 2 używanego jako plik dziennika domeny):

ddrescue -m [image2.log] [image2] [image1] [image1.log]

Zrzut ekranu:

Zatrzymałem się więc i zrobiłem coś przeciwnego: skopiowałem uratowane obszary na obrazie 1 (NTFS), których brakowało na obrazku 2, do tego obrazu 2 (Ext4) - a teraz szybkość kopiowania wynosiła około 43000 KB / s lub 43 MB / s średnio (może nieco wolniej niż należy się spodziewać w przypadku kopii na tym samym dysku twardym, w przypadku Seagate 2 TB, który ma maksymalną prędkość zapisu bliską 200 MB / s, więc powinien być w stanie osiągnąć około 100 MB / s dla kopiować z jednej partycji na drugą, ale nadal prawie 100 × lepiej niż przy pierwszej próbie). Jakie byłoby wyjaśnienie tak ogromnej rozbieżności?

Użyte polecenie:

ddrescue -m [image2.log] [image2] [image1] [image1.log]

Zrzut ekranu:

Zauważyłem, że pliki obrazów na obu partycjach miał „rozmiar na dysku” ^{2} odpowiadające ilości danych, które zostały faktycznie zapisane, bardzo daleko od całkowitego rozmiaru (1 TB lub 931,5 GB), mimo że nie korzystałem z -S switch („używaj rzadkich zapisów dla plików wyjściowych”). Obraz 2 (po uzupełnieniu o dodatkowe uratowane obszary z obrazu 1) ma „rozmiar na dysku” 308,5 GB, podczas gdy obraz 1 ma „rozmiar na dysku” 259,8 GB. Czy może to być związane z niską szybkością kopiowania, jeśli sterownik Linux NTFS w jakiś sposób ma problem z rzadkimi pismami? I jak to się stało, że cały rozmiar nie został przydzielony, gdy tylko napisano sektory na końcu, biorąc pod uwagę, że tego nie użyłem -S przełącznik?

Próbowałem użyć -p switch („preallocate”) na samym początku procesu, myśląc, że byłoby „czystsze”, prostsze, łatwiejsze do rozwiązania w przypadku, gdyby coś poszło nie tak (jeśli odzyskiwanie wymaga odzyskania ...), ale Musiałem przestać, bo było zbyt długo i chciałem zacząć jak najszybciej. Wtedy pomyślałem, że używając -R tymczasowo przełącza („odwrotnie”), zapisuje ostatnie sektory do pliku wyjściowego, przypisując w ten sposób pełny rozmiar zgodnie z moim zamiarem; zaowocowało to zwiększeniem rozmiaru pliku wyjściowego do 931,5 GB, ale „rozmiar na dysku” był w rzeczywistości znacznie niższy (zauważyłem to później, gdy korzystałem z dysku twardego używanego do odzyskiwania w systemie Windows i widząc nienormalnie dużą ilość wolnego przestrzeń).
________________
{1} Nadal nie rozumiem, w jaki sposób druga próba odzyskania może dać o wiele lepszy wynik dla pierwszych 100 GB lub mniej, mimo że stan zdrowia dysku twardego spadł w międzyczasie.

{2} Przy okazji, słowo „dysk” powinno zostać zastąpione zarówno w systemach Windows, jak i Linux, ponieważ istnieją jednostki przechowywania danych, które nie są „dyskami” ...

1. Możesz najpierw skopiować obraz dysku dd dowództwo

   sudo dd bs = [rozmiar_bloku] liczba = [NofBlocks] if = [w_pliku] z = [plik_wyłączony]

gdzie

[in_file] - może być uszkodzony dysk, powiedzmy / dev / sdd2

[out_file] - lokalizacja wyjściowego pliku obrazu.

2. Zamontuj obraz i spróbuj go odzyskać.