Czy to polecenie ddrescue coś robi?

Podczas próby odzyskania danych z uszkodzonego dysku twardego uruchamiam polecenie ddrescue.

Polecenie działało od 9 dni i na podstawie dźwięku aktywności dysku pomyślałem, że może coś robi. Dane wyjściowe z wiersza poleceń wyglądały mniej więcej statycznie:

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

Jedyną częścią, która się zmienia, jest to, co mówi iposi opos. Obejście tego problemu zajęło 9 dni 500000 MB, czyli wielkość uszkodzonego napędu dyskowego. Kiedy jednak się tam dostał, opadł z powrotem na ziemię 0i znów zaczął się wznosić. Kiedy to piszę, 2580 MBzaczyna się i liczy.

Tworzony plik obrazu ma długość 0 bajtów.

Plik dziennika ma rozmiar około 3 MB i wygląda następująco:

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

Zaczynam się martwić, że to tylko strata czasu i żadne dane nie są odzyskiwane.

Czy z tego wyniku wynika, że ​​dzieje się coś pożytecznego?

Czy jest jakikolwiek powód, aby ddrescuepolecenie było kontynuowane bez zmian, czy powinienem je zatrzymać i zrobić coś innego?

To jest najnowsza zawartość /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

Nie wiem, czy nadal próbujesz wyodrębnić dane z tego dysku twardego, czy też już ci się udało, ale w przypadku, gdybyś nie odniósł sukcesu i chciałby spróbować, czy możesz odzyskać, być może utracony Bitcoiny lub cokolwiek innego. Wprowadziłem kilka modyfikacji ddrescueparametrów wiersza poleceń, dodałem następujące:

$ sudo ddrescue -d /dev/sdb /home/dave/RECOVERY/usb500.image \
     /home/dave/recovery_usb500.logfile --force -R

• -d, która mówi ddrescue, aby używał bezpośredniego dostępu do dysku,
• --force, który mówi ddrescue, aby siłą używał i odczytywał / zapisywał do twojego pliku dziennika na wypadek, gdyby narzekał, że nie może go użyć do celów odczytu / zapisu
• -R (tak, z CAPITAL R), który mówi, ddrescueaby wykonać operacje odzyskiwania w odwrotnej kolejności zamiast odczytywać uszkodzony dysk twardy w trybie do przodu. Czasami czytanie w odwrotnej kolejności pomaga, gdy uszkodzenie jest znaczne, ponieważ omija pamięć podręczną dysku twardego na wypadek problemów.

Obecnie używam tych poleceń (z wyjątkiem tego, że nie używam 3polecenia, ponieważ nie chcę [YET] ddrescueponawiać prób uszkodzonych sektorów, pozostawiam to na koniec, po zakończeniu pierwszego przeszukiwania i mam wielki sukces w ratowaniu) dane z mojego uszkodzonego dysku twardego Seagate o pojemności 1 TB, na którym ASSUME może mieć kilka bitcoinów, które mogłem wydobywać w latach 2009-2010, prawdopodobnie znalazłem od 1 do 3 bloków po 50 BTC każdy, mam nadzieję, że jest na tym dysku twardym, no cóż, Wykonanie operacji przy średniej prędkości odczytu wynoszącej 634 kb / s zajmie mi w sumie ponad 15 dni.

Chciałbym również dodać, że możesz i najprawdopodobniej na podstawie twoich poprzednich osiągnięć z ponad 9 DNI „ostatniego czytania”, że napotkasz sytuację, w której dysk twardy po prostu odmówi dalszego czytania, w tym sytuacji, po prostu naciśnij CTRL + C, aby anulować, ponieważ używasz pliku dziennika, wyjmij kabel SATA z uszkodzonego dysku twardego, ale nie kontroler USB z portu USB (tak, użyj kontrolera USB SATA zamiast podłączać go do płyty głównej, aby nie blokowała całego komputera, zmuszając cię do ponownego uruchomienia komputera, a następnie ponownie podłącz zasilanie SATA, aby ponownie uruchomić dysk twardy, poczekaj 10 sekund, a następnie naciśnij strzałkę w górę lub w dół, aby ponownie załadować poprzedni terminal polecenie i uruchom ponownieddrescueoperacja, dzięki twojemu poprzedniemu logowi, będzie kontynuowana od ostatniego przerwania i nastąpi odczyt, a „ostatni udany odczyt” zawsze pozostanie na „0” (zero sekund) tam, gdzie powinien, wskazując, ddrescueże powodzenie w odczyt z dysku twardego, a jeśli kiedykolwiek zauważyć, że „ostatni odczyt z” rozpoczyna odliczanie sekund, po prostu wypowiedzieć po raz kolejny ddrescuez CTRL+ C, cykl zasilania dysk twardy i ponownie uruchomddrescue, nie ma sensu czekać, czy „ostatni odczyt z” samoczynnie wróci do zera, w oparciu o moje doświadczenie nigdy się nie wydarzy, będziesz czekał na wieczność. W sumie musiałem ponownie włączyć mój zły dysk twardy o pojemności 1 TB około 20 razy, minęło około 7 dni i jestem bardzo blisko osiągnięcia poziomu odzyskania 500 GB, w połowie drogi do końca, mam nadzieję, że nie napotkam żadnych poważnych awarii, ponieważ I prawie 100%, ponieważ bezbłędnie działało przez ostatnie 3 dni, ponownie przy prędkości ponad 634 kb / s.

Nie bądź też chciwy, próbując uzyskać większą szybkość odczytu przepustowości danych, ponieważ moja próba wypróbowania wielu parametrów i różnych rozmiarów bloków prawie pozostawiła mnie z całkowicie martwym twardym riverem, który przestanie działać w ciągu ponad 1 sekundy po włączeniu zasilania (to było 5 dni temu), ale na szczęście zaczęło się od nowa, pokazując oznaki życia, początkowo czytając przy 2000 bs (tak BYTES na sekundę) nieco mniej niż 2kbps, byłem bardzo rozczarowany, ale po anulowaniuddrescuez CTRL + C i ponownie uruchamiając go ponownie (w odwrotnej kolejności z dodanym parametrem -R), potem prędkość wróciła do 630, zanim przeczytałem do przodu przy 930 kb / s, przynajmniej jestem zadowolony, że robię 630 kb / s w odwrotnej kolejności i nie musisz rezygnować z 2kbps, więc jeśli odniesiesz sukces przy dowolnej prędkości odczytu, jak w przypadku zakresu 500 kbps trzymaj się go i nie próbuj niczego zwiększać prędkości, może to być Twoja ostatnia udana próba zdobycia dowolna prędkość odczytu.

Alternatywnie, jeśli nie ddrescuejest to dla ciebie dobre, ponieważ nie możesz odczytać niczego bez względu na to, jakie parametry spróbujesz, możesz rozważyć wymianę płyty logicznej z dysku twardego, ponieważ 90% czasu to płyta logiczna idzie źle, ale najpierw zdejmij płytę logiczną i wyczyść wszystkie kontakty, które nawiązują kontakty ze szpilkami dysku twardego, czasami te kontakty zawierają czarnawą lepką mieszankę, przerywając kontakt, który może być przyczyną twojej awarii. Ale pamiętaj, że jeśli musisz wymienić płytę logiczną dysku twardego, będziesz musiał uzyskać jedną tę samą markę, numer seryjny (blisko), numer modelu, numer wersji, ponieważ musi być tak blisko, jak oryginał tablica dawców do pracy.

Powinieneś być w stanie zatrzymać się, ddrescueponieważ używa pliku dziennika, aby móc ponownie uruchomić swoją operację (zamknąć) w miejscu, w którym ją opuścił. Sprawdziłbym jednak, czy plik dziennika został ostatnio zaktualizowany, sprawdzając znacznik czasu lub wykonując polecenie tail -f /home/dave/recovery_usb500.logfile.

To, że plik obrazu jest wciąż tak mały, może mieć związek z tym, że żadne bloki nie zostały jeszcze pomyślnie pobrane z dysku. Byłby to jednak zły wynik po tak długim czasie. Zakładając, że na urządzeniu jest tylko kilka wadliwych bloków i że nie ma ich na początku, status pierwszego wpisu będzie taki +. IIRC ddrescuerozpoczyna czytanie, dopóki nie znajdzie błędu, a następnie rozpoczyna dzielenie reszty dysku. Twoja płyta od samego początku wydaje się nie działać.

O ile +w dzienniku nie ma (wielu) wpisów, a rozmiar pliku nadal byłby taki 0, nie sądzę, że ddrescuejest źle. Nic nie +oznacza, że ​​nic z dysku nie można odzyskać. Może to oznaczać smażoną elektronikę lub złą głowę, ponieważ w przypadku awarii tylko kilku sektorów wyniki byłyby znacznie szybsze.

Co do robienia czegoś innego. Zakładam, że próbowałeś już przeczytać kilka bloków z normalnym dd. Czy na tej podstawie spojrzałeś na syslog i przejrzałeś znalezione tam wiadomości?

Wyszukiwanie „Wynik: hostbyte = nieprawidłowy driverbyte = DRIVER_SENSE” daje kilka interesujących odczytów (częściowo niemiecki) z kilkoma dodatkowymi sugestiami:

• Spróbuj podłączyć przez USB 1.1 zamiast 2.0
• Dysk może się nagrzewać, dlatego należy owinąć go w plastik i włożyć do lodówki na 10 minut, co daje pewien czas na odczytanie, zanim dysk ponownie się nagrzeje.
• przełącznik SMART w BIOS-ie (i połączenie z SATA).
• Upewnij się, że napęd USB ma wystarczającą moc (dodatkowe źródło zasilania)
• Jeśli odczyt po USB nie powiedzie się po pewnym czasie, użyj zdalnie sterowanego koncentratora USB, w którym programowo przełączasz zasilanie z koncentratora USB na dysk na kilka sekund.

Oprócz chłodzenia nieczytelnego dysku (sprayem chłodzącym) sam nie próbowałem żadnego z nich.