Як оцінити цикли / час для завершення GNU ddrescue (1.18.1), використовуючи поточний стан?

Фон / контекст:

В даний час я запускаю GNU ddrescue 1.18.1 для відновлення даних з USB, який зазнав відключення кабелю під час запису віртуального диска на розділ disk2s1. Спочатку я відновляю свій другий розділ (disk2s2) і помічаю, що я досяг третьої фази (Розщеплення). Я розміщую зображення на мережевому сховищі.

Питання:

Я помітив, що ця фаза петлює. Чи є спосіб обчислити кількість циклів, які я, мабуть, зазнаю, враховуючи мою інформацію про поточний стан (я показую лише дві помилки)?

Статус:

Оновлення / редагування:

Тож мене все ще дуже цікавить, як можна оцінити цикли / час завершення за допомогою інструмента ddrescue. Відповідно до коментарів, я додаю оцінку файлу журналу для мого розділу2 disk2s1, який зараз працює (disk2s2 завершився через 14.5 годин, з одним перервою користувача протягом приблизно 6 годин).

Завершений журнал розділів

Щойно завершений розділ, ось результат перевірки журналу.

Довідка (примітки алгоритму відновлення):

4 Алгоритм

GNU ddrescue не є похідною від dd, і жодним чином не пов'язаний з dd, за винятком того, що обидва можуть використовуватися для копіювання даних з одного пристрою на інший. Ключова відмінність полягає в тому, що ddrescue використовує складний алгоритм для копіювання даних з несправних дисків, завдаючи їм якомога менше додаткових збитків.

Ddrescue ефективно керує статусом аварійної порятунку та намагається спочатку врятувати хороші частини, плануючи зчитування в поганих (або повільних) областях на потім. Це максимально збільшує кількість даних, які можна остаточно відновити з несправного накопичувача.

Стандартна утиліта dd може використовуватися для збереження даних з несправного накопичувача, але вона читає дані послідовно, що може зношувати диск, не врятуючи нічого, якщо помилки знаходяться на початку диска.

Інші програми читають дані послідовно, але переходять на читання невеликих розмірів, коли знаходять помилки. Це погана ідея, оскільки означає витрачати більше часу на місцях помилок, пошкоджуючи поверхню, голови та механіку приводу, замість того, щоб якнайшвидше виходити з них. Така поведінка зменшує шанси на порятунок решти хороших даних.

Алгоритм ddrescue полягає в наступному (користувач може перервати процес в будь-який момент, але пам’ятайте, що поганий диск може тривалий час блокувати ddrescue, поки ядро ​​не здасться):

1) За бажанням прочитайте файл журналу, що описує стан багатокористувацької або попередньо перерваної аварійної роботи. Якщо файл журналу не вказаний або порожній або не існує, позначте весь рятувальний домен як неперевірений.

2) (Перша фаза; Копіювання) Прочитайте неперевірені частини вхідного файлу, позначивши невдалі блоки як не обрізані та пропускаючи їх за межі. Пропускайте також за межі повільних областей. Пропущені області намагаються пізніше через два додаткові проходи (перед обрізкою), змінюючи напрямок після кожного проходу, поки не буде спробувано весь рятувальний домен. Третій прохід - розгорнутий пропуск, із пропуском відключений. (Метою є швидке розмежування великих помилок, збереження журналу файлів невеликим та створення хороших вихідних точок для обрізки). Лише пробні області читаються великими блоками. Обрізання, розщеплення та повторне пробування здійснюються по секторах. Кожен сектор випробовується не більше двох разів; перший на цьому кроці (як правило, у складі читання великого блоку, але іноді як зчитування одного сектору), другий на одному з етапів нижче, як прочитаний окремий сектор.

3) (Друга фаза; Обрізка) Читайте вперед по одному сектору за один раз від переднього краю найменшого не обрізаного блоку, поки не буде знайдено поганий сектор. Потім читайте назад по одному сектору за часом від крайнього краю того ж блоку, поки не буде знайдено поганий сектор. Для кожного не обрізаного блоку позначте погані сектори як поганий сектор, а решту цього блоку позначте як нерозщеплений, не намагаючись прочитати його. Повторюйте, поки не буде більше необрізаних блоків. (Великі не обрізані блоки утворюються шляхом об'єднання менших, і частка їх хороших даних у краях менша).

4) (Третя фаза; Розщеплення) Прочитайте вперед по одному сектору за часом від центру найбільшого нерозщепленого блоку, поки не буде знайдено поганий сектор. Потім, якщо знайдений поганий сектор не вперше спробували, читайте по одному сектору за часом від центру того ж блоку, поки не буде знайдений поганий сектор. Якщо файл журналу більший за "--loglog-size", читайте послідовно найбільші нерозбиті блоки, поки кількість записів у файлі журналу не опуститься нижче "-logfile-size". Повторіть, поки всі інші нерозщеплені блоки не матимуть 7 секторів. Потім читайте решта нерозщеплених блоків послідовно.

5) (Четверта фаза; Повторне намагання) Необов'язково спробуйте прочитати ще раз погані сектори, поки не буде досягнуто заданої кількості пропусків. Кожен поганий сектор випробовується лише один раз за кожен прохід. Ddrescue не може знати, чи поганий сектор не підлягає відновленню чи він буде зрештою прочитаний після деяких спроб.

6) За бажанням запишіть файл журналу для подальшого використання.

Загальний розмір помилок ("помилка") - це сума розмірів усіх блоків, що не обрізані, не розбиваються і не відповідають сектору. Він збільшується під час фази копіювання та може зменшуватися під час обрізання, розщеплення та повторного повторного повторного повторного повторного повторного повторного повторного огляду. Зауважте, що як ddrescue розбиває невдалі блоки, роблячи їх меншими, загальний розмір помилок може зменшуватися, тоді як кількість помилок збільшується.

Файл журналу періодично зберігається на диску, а також після завершення або переривання ddrescue. Тож у випадку аварії ви можете відновити порятунок з невеликим відшкодуванням. Інтервал між збереженнями змінюється від 30 секунд до 5 хвилин, залежно від розміру журналу файлів (більші журнали зберігаються з більш тривалими інтервалами).

Також один і той же журнал може використовуватися для декількох команд, що копіюють різні області вхідного файлу, і для декількох спроб відновлення для різних підмножин. Дивіться цей приклад:

Спочатку врятуйте найважливішу частину диска. ddrescue -i0 -s50MiB / dev / hdc журнал hdimage ddrescue -i0 -s1MiB -d -r3 / dev / hdc журнал файлів hdimage

Потім врятуйте деякі ключові області диска. ddrescue -i30GiB -s10GiB / dev / hdc журнал hdimage ddrescue -i230GiB -s5GiB / dev / hdc журнал hdimage

Тепер рятуйте решту (не відновлює те, що вже зроблено). ddrescue / dev / hdc файл журналу hdimage ddrescue -d -r3 / dev / hdc журнал hdimage

Незважаючи на те, що питання було задано 10 місяців тому, відповідь може бути актуальною, оскільки цикл відновлення все ще може працювати залежно від кількох факторів! Жоден каламбур не призначений.

Причина в тому, що оцінка часу майже неможлива, проте іноді ви можете скласти приблизне уявлення наступним чином. Однією з найбільш очевидних причин є те, що ви не можете передбачити, скільки часу знадобиться диск для зчитування поганого сектора, і якщо ви хочете, щоб ddrescue прочитав і повторив кожен окремий, то це може зайняти дуже багато часу. Наприклад, я зараз запускаю відновлення на невеликому накопичувачі 500 Гб, який триває понад 2 тижні, і, можливо, у мене залишилось кілька днів. Але моя ситуація є більш складною, тому що диск зашифрований і щоб прочитати що-небудь успішно, я переконався, що я отримав усі сектори, у яких є таблиці розділів, завантажувальні сектори та інші важливі частини диска. Я використовую методики на додаток до ddrescue, щоб поліпшити свої шанси на всі погані сектори. IOW,

За оцінкою "циклів", якщо ви маєте на увазі кількість повторень, то це те, що ви визначаєте за параметрами, які ви використовуєте. Якщо ви маєте на увазі "загальна кількість пропусків", це легко визначити, прочитавши тут алгоритм .. > man ddrescue </ Алгоритм: Як ddrescue відновлює дані

Я спеціально поговорю з цифрами на екрані, який ви вказали. В інших ситуаціях можуть бути застосовані й інші чинники, тому сприймайте цю інформацію як загальну інструкцію.

У наданому зразку подивіться на екран запущеного стану ddrescue. Ми отримуємо загальну "оцінку" проблеми (рятувальний домен) за допомогою "помилки". Це обсяг даних, який "ще слід прочитати". У вибірці він становить 345 Гб. Наступний рядок нижче праворуч - "середня ставка". У вибірці він становить 583 кб / с

Якщо "середня ставка" повинна залишатися близькою до постійної, це означає, що у вас є ще 7 днів. 345 ГБ / (583 кб * 60 * 60 * 24) = 7,18 Однак проблема полягає в тому, що ви не можете розраховувати на 583 кбіт / с. Насправді, чим глибше ви переходите до відновлення, диск стає повільніше, оскільки він читає все більш жорсткі ділянки та робить більше спроб. Тож час закінчувати експоненціально збільшується. Все це залежить від того, наскільки сильно пошкоджений привід.

Наведений вами зразок показує, що "успішне читання" було понад 10 годин тому. Це говорить про те, що насправді не виходить нічого з приводу протягом 10+ годин. Це показує, що на вашому накопичувачі може бути знято 345 ГБ (або частина) даних. Це дуже погана новина для вас.

На противагу цьому, мій другий накопичувач на 500 ГБ, який нещодавно почав створювати мені помилки "SMART", був скопійований диск на диск (з файлом журналу на іншому диску), і ця операція зайняла близько 8-9 годин. Остання її частина сповільнилася. Але це все-таки терпимо. Незважаючи на те, що дуже поганий диск, як зазначалося вище, за останні два тижні працював на 500 ГБ і все ще залишається приблизно 4-5% для відновлення.

HTH та YMMV