Відповіді:
ddrescue може бути відновлений, але для цього потрібен файл журналу. Файл журналу запише прогрес, досягнутий дотепер ddrescue, і при перезапуску ddrescue прочитає файл журналу і почне там, де він зупинився.
Файл журналу буде третім параметром:
ddrescue /dev/sdd1 ./bye1t.dd_rescue.image ~/sdd1.log
Якщо ви вже розпочали запуск ddrescue без файлу журналу та скасуєте його, наступного разу, коли буде запущено ddrescue, він запуститься на початку, оскільки в ньому немає записів про те, що вже було відновлено.
Примітка : ddrescue та dd_rescue - це різні програми.
Навіть якщо ви забули вказати файл реєстрації, може бути надія:
Таким чином, ви не прочитали підручник і почали ddrescue без logfile. Тепер, через два дні, ваш комп'ютер вийшов з ладу, і ви не можете знати, скільки даних вдалося зберегти. І ще гірше, ви не можете відновити порятунок; вам доведеться перезапустити його з самого початку.
Або, можливо, ви почали копіювати накопичувач dd conv=noerror,syncі зараз перебуваєте в тій же ситуації, що описана вище. У цьому випадку зауважте, що ви не можете використовувати копію, зроблену dd, якщо вона не була викликана syncаргументом перетворення.
Не впадайте у відчай (поки що). Ddrescue може в деяких випадках генерувати приблизний файл файлів із вхідного файлу та (часткової) копії, що майже так само добре, як і точний файл журналу. Це робиться просто припускаючи, що сектори, що містять усі нулі, не були врятовані.
Однак якщо призначенням копії був диск або розділ (або існуючий звичайний файл та усікання не запитували), швидше за все, вам потрібно буде перезапустити ddrescue з самого початку. (Цього разу з лог-файлом, звичайно). Причина полягає в тому, що в накопичувачі, які ще не були перезаписані, можуть бути старі дані, які можуть бути неперевіреними, але не нульовими.
Наприклад, якщо ви вперше спробували одну з цих команд:
ddrescue infile outfile
або
dd if=infile of=outfile conv=noerror,sync
Ви можете створити приблизний файл файлів за допомогою цієї команди:
ddrescue --generate-mode infile outfile logfile
Як уже говорили інші, завжди слід вказати журнал файлів як третій параметр, що дозволить відновити його. Оскільки ви цього не зробили, це вам не допоможе. Якщо ви приблизно знаєте, до якого пункту дійшов процес, ви можете використовувати параметри --input-positionта --output-positionпараметри, щоб почати з цієї точки (переконайтесь, що обидва ці параметри встановлені на одне і те ж значення, інакше вихід буде пошкоджений).
Оскільки ви не вказали файл журналу як третій параметр, відновлення не можна зробити автоматично. Ви можете створити лог-файл вручну, якщо знаєте вже врятовані сектори, синтаксис простий. Просто запустіть ще одне рятування фіктивних файлів до іншого файлу, вказавши журнал, і дозвольте йому читати різні області. Потім відредагуйте журнал, щоб представити вже врятовані області у вашому першому файлі. Тепер перезапустіть попередню команду, але вкажіть ім'я файлу журналу як третій параметр. Потім відновлення відновиться на першому неперевіреному секторі.
Згідно https://wiki.archlinux.org/index.php/Disk_cloning, схоже, що за допомогою conv=noerror,syncперемикача ddнасправді додаються нулі в кінці блоку, не точно там, де сталися помилки читання. Це суперечить інформації у відповіді Майлза Вулба від 2013-08-29.
Наприклад, якщо правильна послідовність 198123283і в середині є помилка читання, вона запише 198283000, а не 198000283.
Тож, якщо помилки читання дійсно були, запропонований метод не буде точним - з'являться області, які можна було б прочитати, які в кінцевому підсумку заповняться нулями, але вважатимуться "врятованими".
До речі, добре починати таку спробу відновлення, заповнивши диск призначення нулями (або принаймні вільним простором, що можна зробити, наприклад, з WinHex).