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


1

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


Z mojego doświadczenia wynika, że ​​zapis do NTFS jest rzeczywiście wolniejszy niż ext4.
Andrea Lazzarotto

Zgadzam się z komentarzem Andrei: pisanie do NTFS jest wolniejsze. Ale nie że powolny. Oczekuje się powolności ddrescue i wadliwy napęd. Widzieć ta odpowiedź i porównaj to pytanie .
Kamil Maciorowski

Dziękuję za te odpowiedzi. W drugim wątku połączonym ktoś donosi, że przełączenie z ExtFAT na Ext4 znacznie poprawiło szybkość kopiowania (7 MB / s nie jest dużo, ale wciąż 70 x lepiej niż 100 KB / s!). Jeśli mam nadzieję uzyskać podobny wynik, przechodząc z NTFS na Ext4, jak mogę to zrobić bezpiecznie, bez ryzyka utraty tego, co do tej pory odzyskano? Czy mogę przekonwertować partycję na miejsce i za pomocą której komendy? (Wciąż nowy w środowisku Linux.) Myślę, że rozsądnie byłoby najpierw wyrenderować partycję NTFS, na wypadek gdyby się nie powiodła. W jaki sposób mogę uzyskać dostęp do partycji Ext4 w systemie Windows?
GabrielB

Aby odpowiedzieć na moje pytanie ... Zrobiłem to: 1) zarchiwizuj zawartość partycji NTFS, aby ją zabezpieczyć 2) zmniejsz partycję NTFS i utwórz partycję Ext4 z partycją 3) skopiuj pliki z NTFS do Ext4 4) wznowione odzyskiwanie ddrescue - właściwie musiałem zacząć wszystko od nowa, ponieważ podgląd (przełącznik -P) nie pokazywał niczego poza 00, nie wiem dlaczego ... (Bardzo ważne, aby to włączyć!) A teraz jest niesamowicie szybki z średnia stopa 90 MB / s! O_o (Dwa razy lepsza niż kiedykolwiek wcześniej, i jak dotąd dziwny brak błędów, 100 GB). Nigdy nie będę próbował odzyskać na woluminie NTFS.
GabrielB

1
Uwagi formalne: (1) Powyższy komentarz nie jest odpowiedzią. Aby naprawdę odpowiedzieć na własne pytanie, wpisz odpowiedź w polu odpowiedzi. Myślę, że twoja ostateczna odpowiedź może być „nie była tego warta”, ponieważ teraz szybko czytasz drugi raz a później przeczytasz tak samo wolno jak to było przed przerwaniem. (2) Aby odpowiedzieć komuś na komentarz za pomocą własnego komentarza, zadzwoń do osoby takiej jak @ KamilMaciorowski, w ten sposób zostanie on powiadomiony. Autor pytania / odpowiedzi, pod którym napisano komentarz, otrzymuje powiadomienie niezależnie od tego, więc nie muszę dzwonić do ciebie w ten sposób.
Kamil Maciorowski

Odpowiedzi:


2

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:
ddrescueview 1st attempt NTFS partition

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:
ddrescueview 2nd attempt Ext4 partition

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:
ddrescueview ddru_ntfsbitmap log file

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:
ddrescue copy rescued areas image 2 to image 1

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:
ddrescue copy rescued areas image 1 to image 2

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


Przeczytałem ten wątek rok później: to, co napisałem o wzorze „paski”, najprawdopodobniej się myli - z tego, czego dowiedziałem się później, jest to obserwowane, gdy jedna lub więcej główek napędu zaczyna się ) nie powiodło się (ponieważ dane rejestrują naprzemiennie „uderzenia” o kilka GB na powierzchni każdego talerza, rozmiar każdego „skoku” jest ustalany dla każdego modelu).
GabrielB

Jeśli chodzi o powodzenie odzyskiwania, uszkodzonych zostało tylko około 120 plików z osobistych plików właściciela, a ponieważ było wiele duplikatów, udało mi się naprawić około 100 plików (w kilku przypadkach dwa duplikaty zostały uszkodzone w różnych miejscach, więc mogłem wypełnić dziury w jednym z drugim za pomocą WinHex), pozostawiając około 20 uszkodzonych plików. Doskonały wynik dla odzyskiwania tylko oprogramowania, biorąc pod uwagę, że napęd klikał jak szalony, kiedy go dostałem!
GabrielB

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

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

1
-1. Pytanie dotyczy NTFS vs ext4, ta odpowiedź wcale nie odpowiada na pytanie. Oprócz ddrescue został stworzony do obsługi wadliwych urządzeń; z dd możesz użyć conv=noerr ale wciąż ddrescue dzięki obsłudze plików dziennika i specjalistycznym opcjom jest w tym przypadku lepszym wyborem.
Kamil Maciorowski

Najpierw musisz stworzyć obraz, reszta jest nieistotna. „ddrescue bardzo wolno, pisanie do NTFS” to bardzo dziwne twierdzenie, musi być szybsze, ponieważ pomija złe bloki, chyba że NTFS nie jest poprawnie zamontowany, przetestuj go najpierw, a następnie spróbuj odzyskać na nim.
Alex

@Alex Czy przeczytałeś to, co napisałem? Szybkość kopiowania podczas pisania nowy plik od partycji Ext4 do partycji NTFS jest w przybliżeniu normalna (trochę powolna, ale nie tak straszna): skopiowałem 2. odzyskiwanie (z ddrescue i przełącznikiem -S tym razem, aby zaoszczędzić miejsce) od Ext4 do NTFS (oba na zdrowym dysku 2 TB ) średnio 30-40 MB / s. Ale przedtem, kiedy próbowałem kompletny pierwszy plik obrazu już na miejscu (i prawdopodobnie fragmentaryczny), z dodatkowymi odzyskanymi obszarami z drugiego pliku obrazu, szybkość spadła do około 0,6 MB / s. Co w tym przypadku oznaczałoby „nieprawidłowy montaż”?
GabrielB
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.