Использование ddrescue для восстановления сломанного диска. Могу ли я проверить ход выполнения до завершения запуска?

Question

Теоретически вы можете завершить ( ctrl+ C) ddrescueи запустить его позже с тем же файлом журнала, чтобы он продолжился, а не начинался заново. Я видел несколько сообщений, утверждающих, что этот метод не всегда работает – в этих случаях ddrescueигнорировалась предыдущая работа и начинался с начала по неизвестной причине.

Попробуйте смонтировать целевой раздел только для чтения:

sudo mount -o ro /dev/sdc2 /mnt/foo

Как только для чтения, он не должен мешать ddrescueработе. Существует риск, что важные для файловой системы данные еще не восстановлены, в этом случае mountпроизойдет сбой. При некоторой удаче вы сможете смонтировать, а затем прочитать нужные вам файлы, но файлы могут быть повреждены, даже если вы не получите никаких ошибок от mountи (например) cp. Проверьте их или их копии. Не завершайте работу, ddrescueпока не убедитесь, что файлы действительны и не содержат невосстановленных/испорченных фрагментов внутри.

В случае возникновения каких-либо проблем вы можете подождать, ddrescueчтобы восстановить больше данных (если таковые имеются). Я бы не стал дожидаться, пока неповрежденные файлы появятся в точке монтирования, поскольку система может кэшировать метаданные или сами файлы и т. д. Сделайте это umount, дождитесь восстановления большего количества данных, mountснова и проверьте файлы.

Редактировать: отвечаю на дополнительные вопросы.

Есть ли способ указать ddrescue определенную папку?

Нет. Инструмент работает на уровне блоков. Он ничего не знает о файловой системе и файлах. Ваше утверждение "ddrescuelog сообщает, что 99,73% моих файлов были восстановлены" должно означать "99,73% блоков".

Также, возможно ли, что данные были восстановлены, поскольку он говорит, что 99,73% восстановлено, но они слишком повреждены, чтобы распознаваться как файлы? Если это так, есть ли какая-то программа для просмотра поврежденных файлов, возможно, я смогу восстановить часть из них вручную.

Возможный сценарий: содержимое файла восстановлено, но соответствующая запись файловой системы — нет (примечание: в общем случае обратное тоже возможно, но, очевидно, это не ваш случай). Вы сказали, что вся папка исчезла. Я думаю, что некоторые файлы могут появиться позже lost+found( fsckили похожим образом в зависимости от вашей файловой системы — я не знаю, что это такое).

Более подробная информация здесь:Каково назначение папки lost+found в Linux и Unix?

Эта fsckоперация не только для чтения, ее не следует выполнять во время ddrescueработы. Завершение ddrescue, запуск fsckи возобновление ddrescueтакже плохая идея. Лучше дождаться ddrescueзавершения. Это может занять некоторое время – читайтеэтотиэтот.

В общем, вам следует работать с fsck(или любым другим инструментом, не предназначенным только для чтения) над копией восстановленных данных. Хороший способ, для справок в будущем:

Запись в файл, а не на устройство. Используйте файловую систему скопирование при записи (COW)особенность.
ДелатьКОРОВАкопировать с помощью cp --reflink=always. Вы можете сделать это во время ddrescueработы. Эта копия — как снимок вашего целевого файла.
Используйте любые инструменты для копирования, включая те, которые не предназначены только для чтения.
В случае сбоя у вас все еще будет исходный целевой файл (возможно, с большим количеством восстановленных данных, если ddrescueон все еще работает), чтобы начать все заново с другимКОРОВАкопировать (возможно, и другими инструментами).

Вы также можете попробовать найти удаленные файлы и восстановить их. Выбор инструмента зависит от файловой системы.

Еще один совет: возможно, ваше программное обеспечение использовало временные файлы где-то еще в иерархии файловой системы. Проверьте /tmp/, /var/tmp/.

Редактировать, отвечая на дополнительный вопрос.

Когда ddrescuelog говорит, что 99,73% блоков были спасены, что это значит? Похоже, что я должен ожидать каких-то результатов, а не пустого домашнего диска.

Примечание: приведенный ниже пример не призван охватить все проблемы и сценарии файловой системы и не позволяет отличить секторы диска от единиц распределения файловой системы; он предназначен только для ответа на вопрос.

Представьте, что ваш раздел — это книга — энциклопедия, а не роман с сюжетом. Файлы — это статьи внутри. Блок диска (или сектор) — это страница в книге. Файловая система — это общий способ размещения статей на страницах. Некоторые страницы содержатСодержание (ToC)что на нашем рисунке является проблемой файловой системы и может выглядеть примерно так:

статья №289: страницы 2076, 2077, 2078, 402, 403.

Обратите внимание, что эта статья фрагментирована, как и любой файл. На другой странице, но все еще внутриОглавлениеу нас есть что-то вроде структуры папок:

…
people/: видетьОглавлениена странице 43.
…
(страница 43)
mathematicians/: см.Оглавлениена стр. 80.
famous Poles/: см.Оглавлениена странице 82.
Adam and Eve: см. статью № 14.
…
(страница 80)
Euclid: см. статью № 289.
Banach Stefan: см. статью № 4380.
…
(страница 82)
Banach Stefan: см. статью № 4380.
Kościuszko Tadeusz: см. статью № 2208.
…

Эта структура является примером файлов с жесткими ссылками. Существует по крайней мере два пути, которые указывают на одну статью: ./people/mathematicians/Banach Stefanи ./people/famous Poles/Banach Stefan. Здесь я поставил точку в начале каждого пути, потому что мой пример намеренно скрывает информацию: people/к какому разделу принадлежит раздел? (это может быть также /people/или /full articles/people/или /stubs/people/или /foo/bar/people/).

TheОглавлениеможет также иметь раздел, который гласит:

«пустые» страницы: 567, 568, 569, 2070, 2071…

На данной странице есть текст (т.е. данные), даже если он не принадлежит ни к одной статье, существующей в данный момент. Это происходит потому, что процесс удаления статьи влияет только наОглавление.Оглавлениеявляется единственным надежным способом определить, принадлежит ли данная страница статье, какой статье, или ее можно считать пустой и перезаписанной. Более того: нет способа обнаружить "пустую страницу" безОглавление. Странно, что в энциклопедии пустая страница является частью статьи, но сектор, полный букв 0s или пробелов, или чего-то еще, может быть частью файла. Все дело вОглавление.

Некоторые из ваших страниц (блоков) не были спасены (пока). Любая из них может быть страницей с данными статьи илиТок-метаданные. Возможности:

Отсутствующий блок — это блок данных (например, страница 2078). Вы знаете путь к статье о Евклиде и на каких страницах она находится, но одна из страниц пуста, хотя не должна быть. Статья недействительна.
Отсутствующий блок — это блок метаданных. Некоторые сценарии:
- Вы потеряли счет свободного места.
- Вы знаете, что есть ./people/mathematicians/Euclidпуть, но у вас нет информации, на каких страницах находится статья. Невозможно найти статью, если вы уже не знаете о ней что-то (например, запись о человеке, скорее всего, содержит слово "born"; файлы PDF начинаются с "%PDF").
- Вы знаете, что на таких-то страницах есть одна статья, но нет полного пути к ней. В таком случае вы можете поместить ее под lost+foundи это то, что fsckнужно. На нашей картинке есть возможности (среди прочих):
  - Отсутствует страница 80: вы знаете (со страницы 43), что есть mathematiciansраздел (папка), но вы не знаете, что статья № 289 должна быть в нем под названием «Евклид».
  - Отсутствует страница 43: вы не знаете, что должна быть статья № 14 об Адаме и Еве, а также разделы с математиками и знаменитыми поляками; но вы можете видеть (на странице 80), что есть раздел со статьями об Евклиде и Банахе, и есть другой раздел (страница 82) со статьями о Банахе и Костюшко.Вот что может происходить с вашим /home.Статьи (файлы) там и могут быть действительными. Они не могут быть достигнуты по пути, потому что у вас нетТоквашей /home.
Любая комбинация вышеперечисленных проблем может возникнуть, если несколько блоков не были восстановлены.
Отсутствующий блок может быть помечен как пустой. В этом случае вы ничего не теряете.

Answer 1

Теоретически вы можете завершить ( ctrl+ C) ddrescueи запустить его позже с тем же файлом журнала, чтобы он продолжился, а не начинался заново. Я видел несколько сообщений, утверждающих, что этот метод не всегда работает – в этих случаях ddrescueигнорировалась предыдущая работа и начинался с начала по неизвестной причине.

Попробуйте смонтировать целевой раздел только для чтения:

sudo mount -o ro /dev/sdc2 /mnt/foo

Как только для чтения, он не должен мешать ddrescueработе. Существует риск, что важные для файловой системы данные еще не восстановлены, в этом случае mountпроизойдет сбой. При некоторой удаче вы сможете смонтировать, а затем прочитать нужные вам файлы, но файлы могут быть повреждены, даже если вы не получите никаких ошибок от mountи (например) cp. Проверьте их или их копии. Не завершайте работу, ddrescueпока не убедитесь, что файлы действительны и не содержат невосстановленных/испорченных фрагментов внутри.

В случае возникновения каких-либо проблем вы можете подождать, ddrescueчтобы восстановить больше данных (если таковые имеются). Я бы не стал дожидаться, пока неповрежденные файлы появятся в точке монтирования, поскольку система может кэшировать метаданные или сами файлы и т. д. Сделайте это umount, дождитесь восстановления большего количества данных, mountснова и проверьте файлы.

Редактировать: отвечаю на дополнительные вопросы.

Есть ли способ указать ddrescue определенную папку?

Нет. Инструмент работает на уровне блоков. Он ничего не знает о файловой системе и файлах. Ваше утверждение "ddrescuelog сообщает, что 99,73% моих файлов были восстановлены" должно означать "99,73% блоков".

Также, возможно ли, что данные были восстановлены, поскольку он говорит, что 99,73% восстановлено, но они слишком повреждены, чтобы распознаваться как файлы? Если это так, есть ли какая-то программа для просмотра поврежденных файлов, возможно, я смогу восстановить часть из них вручную.

Возможный сценарий: содержимое файла восстановлено, но соответствующая запись файловой системы — нет (примечание: в общем случае обратное тоже возможно, но, очевидно, это не ваш случай). Вы сказали, что вся папка исчезла. Я думаю, что некоторые файлы могут появиться позже lost+found( fsckили похожим образом в зависимости от вашей файловой системы — я не знаю, что это такое).

Более подробная информация здесь:Каково назначение папки lost+found в Linux и Unix?

Эта fsckоперация не только для чтения, ее не следует выполнять во время ddrescueработы. Завершение ddrescue, запуск fsckи возобновление ddrescueтакже плохая идея. Лучше дождаться ddrescueзавершения. Это может занять некоторое время – читайтеэтотиэтот.

В общем, вам следует работать с fsck(или любым другим инструментом, не предназначенным только для чтения) над копией восстановленных данных. Хороший способ, для справок в будущем:

Запись в файл, а не на устройство. Используйте файловую систему скопирование при записи (COW)особенность.
ДелатьКОРОВАкопировать с помощью cp --reflink=always. Вы можете сделать это во время ddrescueработы. Эта копия — как снимок вашего целевого файла.
Используйте любые инструменты для копирования, включая те, которые не предназначены только для чтения.
В случае сбоя у вас все еще будет исходный целевой файл (возможно, с большим количеством восстановленных данных, если ddrescueон все еще работает), чтобы начать все заново с другимКОРОВАкопировать (возможно, и другими инструментами).

Вы также можете попробовать найти удаленные файлы и восстановить их. Выбор инструмента зависит от файловой системы.

Еще один совет: возможно, ваше программное обеспечение использовало временные файлы где-то еще в иерархии файловой системы. Проверьте /tmp/, /var/tmp/.

Редактировать, отвечая на дополнительный вопрос.

Когда ddrescuelog говорит, что 99,73% блоков были спасены, что это значит? Похоже, что я должен ожидать каких-то результатов, а не пустого домашнего диска.

Примечание: приведенный ниже пример не призван охватить все проблемы и сценарии файловой системы и не позволяет отличить секторы диска от единиц распределения файловой системы; он предназначен только для ответа на вопрос.

Представьте, что ваш раздел — это книга — энциклопедия, а не роман с сюжетом. Файлы — это статьи внутри. Блок диска (или сектор) — это страница в книге. Файловая система — это общий способ размещения статей на страницах. Некоторые страницы содержатСодержание (ToC)что на нашем рисунке является проблемой файловой системы и может выглядеть примерно так:

статья №289: страницы 2076, 2077, 2078, 402, 403.

Обратите внимание, что эта статья фрагментирована, как и любой файл. На другой странице, но все еще внутриОглавлениеу нас есть что-то вроде структуры папок:

…
people/: видетьОглавлениена странице 43.
…
(страница 43)
mathematicians/: см.Оглавлениена стр. 80.
famous Poles/: см.Оглавлениена странице 82.
Adam and Eve: см. статью № 14.
…
(страница 80)
Euclid: см. статью № 289.
Banach Stefan: см. статью № 4380.
…
(страница 82)
Banach Stefan: см. статью № 4380.
Kościuszko Tadeusz: см. статью № 2208.
…

Эта структура является примером файлов с жесткими ссылками. Существует по крайней мере два пути, которые указывают на одну статью: ./people/mathematicians/Banach Stefanи ./people/famous Poles/Banach Stefan. Здесь я поставил точку в начале каждого пути, потому что мой пример намеренно скрывает информацию: people/к какому разделу принадлежит раздел? (это может быть также /people/или /full articles/people/или /stubs/people/или /foo/bar/people/).

TheОглавлениеможет также иметь раздел, который гласит:

«пустые» страницы: 567, 568, 569, 2070, 2071…

На данной странице есть текст (т.е. данные), даже если он не принадлежит ни к одной статье, существующей в данный момент. Это происходит потому, что процесс удаления статьи влияет только наОглавление.Оглавлениеявляется единственным надежным способом определить, принадлежит ли данная страница статье, какой статье, или ее можно считать пустой и перезаписанной. Более того: нет способа обнаружить "пустую страницу" безОглавление. Странно, что в энциклопедии пустая страница является частью статьи, но сектор, полный букв 0s или пробелов, или чего-то еще, может быть частью файла. Все дело вОглавление.

Некоторые из ваших страниц (блоков) не были спасены (пока). Любая из них может быть страницей с данными статьи илиТок-метаданные. Возможности:

Отсутствующий блок — это блок данных (например, страница 2078). Вы знаете путь к статье о Евклиде и на каких страницах она находится, но одна из страниц пуста, хотя не должна быть. Статья недействительна.
Отсутствующий блок — это блок метаданных. Некоторые сценарии:
- Вы потеряли счет свободного места.
- Вы знаете, что есть ./people/mathematicians/Euclidпуть, но у вас нет информации, на каких страницах находится статья. Невозможно найти статью, если вы уже не знаете о ней что-то (например, запись о человеке, скорее всего, содержит слово "born"; файлы PDF начинаются с "%PDF").
- Вы знаете, что на таких-то страницах есть одна статья, но нет полного пути к ней. В таком случае вы можете поместить ее под lost+foundи это то, что fsckнужно. На нашей картинке есть возможности (среди прочих):
  - Отсутствует страница 80: вы знаете (со страницы 43), что есть mathematiciansраздел (папка), но вы не знаете, что статья № 289 должна быть в нем под названием «Евклид».
  - Отсутствует страница 43: вы не знаете, что должна быть статья № 14 об Адаме и Еве, а также разделы с математиками и знаменитыми поляками; но вы можете видеть (на странице 80), что есть раздел со статьями об Евклиде и Банахе, и есть другой раздел (страница 82) со статьями о Банахе и Костюшко.Вот что может происходить с вашим /home.Статьи (файлы) там и могут быть действительными. Они не могут быть достигнуты по пути, потому что у вас нетТоквашей /home.
Любая комбинация вышеперечисленных проблем может возникнуть, если несколько блоков не были восстановлены.
Отсутствующий блок может быть помечен как пустой. В этом случае вы ничего не теряете.

Использование ddrescue для восстановления сломанного диска. Могу ли я проверить ход выполнения до завершения запуска?

решение1

Редактировать: отвечаю на дополнительные вопросы.

Редактировать, отвечая на дополнительный вопрос.

Связанный контент