Jak oszacować pętle / czas ukończenia GNU ddrescue (1.18.1) przy użyciu aktualnego statusu?

9

Tło / kontekst:

Obecnie korzystam z GNU ddrescue 1.18.1, aby odzyskać dane z USB, który doświadczył rozłączenia kabla podczas zapisywania obrazu dysku wirtualnego na partycji disk2s1. Początkowo odzyskuję drugą partycję (disk2s2) i zauważam, że doszedłem do trzeciej fazy (dzielenie). Umieszczam obraz w pamięci sieciowej.

Pytanie:

Zauważyłem, że ta faza zapętla się. Czy istnieje sposób, aby obliczyć liczbę pętli, które prawdopodobnie wystąpią, biorąc pod uwagę mój obecny status (pokazuję tylko dwa błędy)?

Status:

status

Zaktualizuj / Edytuj:

Dlatego nadal bardzo interesuje mnie, w jaki sposób można oszacować pętle / czas ukończenia za pomocą narzędzia ddrescue. Zgodnie z komentarzami dodam ocenę pliku dziennika dla mojej partycji disk2s1, która jest aktualnie uruchomiona (disk2s2 zakończyło się po 14,5 godzinach, z jedną przerwą dla użytkownika na około 6 godzin).

part1-log

Uzupełniony dziennik partycji

W przypadku partycji, która właśnie się zakończyła, oto wynik inspekcji dziennika.

dziennik zdjęć

Odniesienie (uwagi na temat algorytmu ddrescue):

4 Algorytm


GNU ddrescue nie jest pochodną dd, ani nie jest w żaden sposób związany z dd, z wyjątkiem tego, że oba mogą być użyte do kopiowania danych z jednego urządzenia na drugie. Kluczową różnicą jest to, że ddrescue używa zaawansowanego algorytmu do kopiowania danych z uszkodzonych dysków, powodując jak najmniejsze dodatkowe szkody.

Ddrescue skutecznie zarządza stanem trwającego ratowania i najpierw próbuje uratować dobre części, planując odczyty w złych (lub wolnych) obszarach na później. Maksymalizuje to ilość danych, które można ostatecznie odzyskać z uszkodzonego dysku.

Standardowego narzędzia dd można używać do zapisywania danych z uszkodzonego dysku, ale odczytuje dane sekwencyjnie, co może zużyć dysk bez ratowania czegokolwiek, jeśli błędy wystąpią na początku dysku.

Inne programy odczytują dane sekwencyjnie, ale przełączają się na odczyty małych rozmiarów, gdy znajdą błędy. Jest to zły pomysł, ponieważ oznacza spędzanie więcej czasu w obszarach błędów, niszczenie powierzchni, głowic i mechaniki napędu, zamiast wydostawania się z nich tak szybko, jak to możliwe. Takie zachowanie zmniejsza szanse na uratowanie pozostałych dobrych danych.

Algorytm ddrescue jest następujący (użytkownik może przerwać proces w dowolnym momencie, ale należy pamiętać, że zły dysk może blokować ddrescue przez długi czas, dopóki jądro się nie podda):

1) Opcjonalnie przeczytaj plik dziennika opisujący stan wieloczęściowego lub wcześniej przerwanego ratowania. Jeśli nie podano pliku dziennika, jest on pusty lub nie istnieje, zaznacz całą domenę ratunkową jako niespróbowaną.

2) (Pierwsza faza; Kopiowanie) Odczytaj niespróbowane części pliku wejściowego, zaznaczając uszkodzone bloki jako nie przycięte i pomijając je. Pomiń także wolne obszary. Pominięte obszary są wypróbowywane później w dwóch dodatkowych przejściach (przed przycięciem), odwracając kierunek po każdym przejściu, aż do wypróbowania całej domeny ratunkowej. Trzecie przejście to zamiatanie z wyłączonym pomijaniem. (Celem jest szybkie ograniczenie dużych błędów, utrzymanie małego pliku dziennika i uzyskanie dobrych punktów początkowych do przycinania). Tylko niespróbowane obszary są odczytywane w dużych blokach. Przycinanie, dzielenie i ponawianie odbywa się sektor po sektorze. Każdy sektor jest sprawdzany co najwyżej dwa razy; pierwszy w tym kroku (zwykle jako część odczytu dużego bloku, ale czasami jako odczyt pojedynczego sektora), drugi w jednym z poniższych kroków jako odczyt pojedynczego sektora.

3) (Druga faza; Przycinanie) Odczytaj jeden sektor na raz od krawędzi wiodącej najmniejszego nie przyciętego bloku, aż zostanie znaleziony zły sektor. Następnie odczytaj jeden sektor wstecz od krawędzi końcowej tego samego bloku, aż do znalezienia uszkodzonego sektora. Dla każdego nie przyciętego bloku zaznacz uszkodzone sektory znalezione jako zły sektor i zaznacz resztę tego bloku jako nierozdzielony, nie próbując go odczytać. Powtarzaj, aż nie będzie już nie przyciętych bloków. (Duże bloki nie przycięte powstają w wyniku połączenia mniejszych bloków, dlatego ich ułamek dobrych danych na krawędziach jest mniejszy).

4) (Trzecia faza; Podział) Odczytaj jeden sektor na raz od centrum największego bloku niepodzielonego, aż do znalezienia uszkodzonego sektora. Następnie, jeśli znaleziony uszkodzony sektor nie jest pierwszym próbowanym, odczytaj jeden sektor wstecz od środka tego samego bloku, aż do znalezienia uszkodzonego sektora. Jeśli plik dziennika jest większy niż „--logfile-size”, czytaj kolejno największe niepodzielone bloki, aż liczba wpisów w pliku dziennika spadnie poniżej „--logfile-size”. Powtarzaj, aż wszystkie pozostałe nierozdzielone bloki będą miały mniej niż 7 sektorów. Następnie odczytaj kolejno pozostałe nierozdzielone bloki.

5) (czwarta faza; ponawianie) Opcjonalnie spróbuj ponownie odczytać uszkodzone sektory, aż do osiągnięcia określonej liczby powtórzeń. Każdy zły sektor jest sprawdzany tylko raz przy każdym przejściu. Ddrescue nie może wiedzieć, czy zły sektor jest niemożliwy do odzyskania, czy też zostanie w końcu odczytany po kilku próbach.

6) Opcjonalnie napisz plik dziennika do późniejszego wykorzystania.

Całkowity rozmiar błędu („errsize”) jest sumą rozmiarów wszystkich bloków niepoprawionych, niepodzielonych i uszkodzonych sektorów. Zwiększa się podczas fazy kopiowania i może się zmniejszyć podczas przycinania, dzielenia i ponownej próby. Zauważ, że gdy ddrescue dzieli uszkodzone bloki, zmniejszając je, całkowity rozmiar błędu może się zmniejszyć, a liczba błędów wzrośnie.

Plik dziennika jest okresowo zapisywany na dysku, a także po zakończeniu lub przerwaniu programu ddrescue. Więc w razie awarii możesz wznowić ratunek z niewielkim kopiowaniem. Odstęp między zapisami wynosi od 30 sekund do 5 minut w zależności od wielkości pliku dziennika (większe pliki dziennika są zapisywane w dłuższych odstępach czasu).

Tego samego pliku dziennika można także użyć do wielu poleceń kopiujących różne obszary pliku wejściowego oraz do wielu prób odzyskiwania różnych podzbiorów. Zobacz ten przykład:

Najpierw uratuj najważniejszą część dysku. ddrescue -i0 -s50MiB / dev / hdc plik dziennika hddage ddrescue -i0 -s1MiB -d -r3 / dev / hdc plik dziennika hdimage

Następnie uratuj niektóre kluczowe obszary dysków. ddrescue -i30GiB -s10GiB / dev / hdc hdimage logfile ddrescue -i230GiB -s5GiB / dev / hdc hdimage logfile

Teraz uratuj resztę (nie kopiuje tego, co już zrobiono). ddrescue / dev / hdc hdimage logfile ddrescue -d -r3 / dev / hdc hdimage logfile

Tommie C.
źródło
czy dysk nadal jest podłączony pod tą samą nazwą urządzenia? Powinieneś także potrzebować ddrescuetylko wtedy, gdy dysk ma złe bloki, co nie byłoby spowodowane „odłączeniem kabla”. Jeśli masz problemy z kablem, po prostu spróbuj innego kabla ...
frostschutz
@TommieC. możesz spróbować ddrescuelog -t YourLog.txtw innym terminalu?
Simply_Me
@Simply_Me Zobacz zaktualizowane pytanie odzwierciedlające dwa wyniki.
Tommie C.
@frostschutz Więcej informacji można znaleźć w zaktualizowanym pytaniu. Utrata połączenia kablowego wystąpiła podczas zapisywania dysku i spowodowała problemy z tablicą partycji. Sam kabel jest nieuszkodzony.
Tommie C.,
Odłączenie kabla zwykle powoduje błędy logiczne (tzn. Dane na dysku nie są w 100% poprawne), ale nie powoduje fizycznych problemów z napędem - chyba że upuścisz go w tym samym czasie. ddrescuemoże jedynie próbować rozwiązać problemy fizyczne i nie pomoże w ogóle w logicznych błędach. W przypadku tych drugich spróbujcie fsckjednakowo ...
Udo G

Odpowiedzi:

6

Mimo że pytanie zostało zadane 10 miesięcy temu, odpowiedź może być trafna, ponieważ cykl odzyskiwania może nadal działać w zależności od kilku czynników! Gra słów nie przeznaczona.

Powodem jest to, że oszacowanie czasu jest prawie niemożliwe, jednak czasami można uzyskać przybliżony pomysł w następujący sposób. Jednym z najbardziej oczywistych powodów jest to, że nie można przewidzieć, ile czasu zajmie dysku odczytanie uszkodzonego sektora, a jeśli chcesz, aby ddrescue czytał i ponawiał każdy z nich, może to zająć bardzo dużo czasu. Na przykład obecnie uruchamiam odzyskiwanie na małym dysku o pojemności 500 GB, który trwa od ponad 2 tygodni i prawdopodobnie zostało mi kilka dni. Ale moja jest bardziej skomplikowaną sytuacją, ponieważ dysk jest zaszyfrowany i aby cokolwiek pomyślnie odczytać, upewniłem się, że otrzymałem wszystkie sektory, które mają tabele partycji, sektory rozruchowe i inne ważne części dysku. Oprócz ddrescue używam technik, aby zwiększyć swoje szanse na wszystkie złe sektory. IOW,

Oszacowując „pętle”, jeśli masz na myśli liczbę ponownych prób, określasz to na podstawie parametrów, których używasz. Jeśli masz na myśli „całkowitą liczbę przejść”, łatwo to ustalić, czytając o algorytmie tutaj .. > man ddrescue </ Algorytm: Jak ddrescue odzyskuje dane

Będę konkretnie rozmawiał z liczbami na zrzutach ekranu, które podałeś. W innych sytuacjach mogą obowiązywać inne czynniki, dlatego te informacje należy traktować jako ogólną wskazówkę.

W podanym przez Ciebie przykładzie spójrz na ekran stanu działania ddrescue. Otrzymujemy całkowitą „ocenę” problemu (domenę ratunkową) przez „błąd”. Jest to ilość danych, które „należy jeszcze przeczytać”. W próbce jest to 345 GB. Następny wiersz poniżej po prawej to „średnia stawka”. W próbce wynosi 583 kb / s

Jeśli „średnia stawka” pozostanie na stałym poziomie, oznacza to, że masz jeszcze 7 dni do końca. 345 GB / (583 kb * 60 * 60 * 24) = 7,18 Jednak problemem jest to, że nie można polegać na 583 kb / s. W rzeczywistości, im głębiej wchodzisz w tryb odzyskiwania, dysk staje się wolniejszy, ponieważ odczytuje coraz trudniejsze obszary i wykonuje więcej prób. Czas wykładniczo wzrasta. Wszystko to zależy od stopnia uszkodzenia dysku.

Podany przez Ciebie przykład pokazuje, że „pomyślny odczyt” miał miejsce ponad 10 godzin temu. To znaczy, że tak naprawdę nie pobiera niczego z dysku przez ponad 10 godzin. To pokazuje, że twój dysk może mieć 345 GB (lub część) danych. To dla ciebie bardzo zła wiadomość.

Natomiast mój drugi dysk o pojemności 500 GB, który właśnie zaczął powodować błędy „SMART”, został skopiowany z dysku na dysk (z plikiem dziennika na innym dysku), a cała operacja zajęła około 8–9 godzin. Ostatnia część zwolniła. Ale to wciąż znośne. Chociaż bardzo zły dysk, jak wspomniano powyżej, minął już 2 tygodnie, pracując na 500 GB i nadal ma około 4-5% do odzyskania.

HTH i YMMV

LMSingh
źródło