Odpowiedzi:
ddrescue można wznowić, ale aby to zrobić, wymaga pliku dziennika. Plik dziennika zapisze postępy poczynione do tej pory przez ddrescue, a ponowne uruchomienie ddrescue odczyta plik dziennika i rozpocznie się tam, gdzie go przerwał.
Plik dziennika byłby trzecim parametrem:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
Jeśli uruchomiłeś już ddrescue bez pliku dziennika i anulujesz go, następnym razem, gdy uruchomi się ddrescue, rozpocznie się na początku, ponieważ nie ma zapisu tego, co zostało już odzyskane.
Nawet jeśli zapomniałeś podać plik dziennika, może być nadzieja:
Więc nie przeczytałeś samouczka i zacząłeś ddrescue bez pliku dziennika. Teraz dwa dni później komputer się zawiesił i nie możesz wiedzieć, ile danych ddrescue udało się zaoszczędzić. Co gorsza, nie można wznowić ratowania; musisz go zrestartować od samego początku.
A może zacząłeś kopiować dysk dd conv=noerror,synci jesteś teraz w takiej samej sytuacji, jak opisano powyżej. W takim przypadku pamiętaj, że nie możesz użyć kopii wykonanej przez dd, chyba że została wywołana z syncargumentem konwersji.
Nie rozpaczaj (jeszcze). Ddrescue może w niektórych przypadkach wygenerować przybliżony plik dziennika z pliku wejściowego i (częściowej) kopii, który jest prawie tak dobry, jak dokładny plik dziennika. Robi to po prostu zakładając, że sektory zawierające wszystkie zera nie zostały uratowane.
Jeśli jednak miejscem docelowym kopii był dysk lub partycja (lub nie był wymagany istniejący zwykły plik i obcięcie), najprawdopodobniej będziesz musiał ponownie uruchomić ddrescue od samego początku. (Tym razem oczywiście z plikiem dziennika). Powodem jest to, że na dysku mogą znajdować się stare dane, które nie zostały jeszcze nadpisane, a zatem mogą być niespróbowane, ale niezerowe.
Na przykład, jeśli najpierw wypróbowałeś jedno z tych poleceń:
ddrescue infile outfile
lub
dd if=infile of=outfile conv=noerror,sync
możesz wygenerować przybliżony plik dziennika za pomocą tego polecenia:
ddrescue --generate-mode infile outfile logfile
Jak powiedzieli inni, zawsze należy podać plik dziennika jako trzeci parametr, który pozwoli na wznowienie. Ponieważ tego nie zrobiłeś, nie pomoże ci to tutaj. Jeśli wiesz w przybliżeniu, do którego punktu dotarł proces, możesz użyć parametrów --input-positioni --output-position, aby rozpocząć od tego punktu (upewnij się, że oba parametry mają taką samą wartość, w przeciwnym razie dane wyjściowe zostaną uszkodzone).
Ponieważ nie określono pliku dziennika jako trzeciego parametru, wznowienie nie może być wykonane automatycznie. Możesz ręcznie utworzyć plik dziennika, jeśli znasz już uratowane sektory, składnia jest łatwa. Po prostu uruchom kolejny atrapa ratunkowa do innego pliku, określając dziennik i pozwól mu czytać różne obszary. Następnie edytuj dziennik, aby reprezentował już uratowane obszary w pierwszym pliku. Teraz ponownie uruchom poprzednie polecenie, ale podaj nazwę pliku dziennika jako trzeci parametr. ddrescue zostanie wznowiony w pierwszym niespróbowanym sektorze.
Według https://wiki.archlinux.org/index.php/Disk_cloning wydaje się, że w przypadku conv=noerror,syncprzełącznika ddw rzeczywistości dodaje zera na końcu bloku, niezupełnie tam, gdzie wystąpiły błędy odczytu. Jest to sprzeczne z informacjami zawartymi w odpowiedzi Milesa Wolbe z 29.08.2013.
Na przykład, jeśli poprawna sekwencja jest, 198123283a na środku jest błąd odczytu 198283000, zapisuje , a nie 198000283.
Tak więc w przypadku, gdy rzeczywiście wystąpiły błędy odczytu, proponowana metoda nie będzie dokładna - pojawią się obszary, które byłyby możliwe do odczytania, które ostatecznie zostaną wypełnione zerami, ale będą uważane za „uratowane”.
Nawiasem mówiąc, dobrą praktyką jest rozpoczęcie takiej próby odzyskiwania, wypełniając docelowy dysk zerami (lub przynajmniej wolnym miejscem, co można zrobić na przykład za pomocą WinHex).