Теоретически вы можете прекратить (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) .
- Сделайте копию COW с помощью
cp --reflink=always . Вы можете сделать это во время ddrescue операции. Эта копия похожа на снимок целевого файла.
- Используйте любые инструменты на копии, в том числе не только для чтения.
- В случае сбоя у вас все еще есть исходный целевой файл (возможно, с восстановлением большего количества данных, если
ddrescue все еще работает), чтобы начать заново с другой копией COW (и, возможно, с другими инструментами).
Вы также можете попытаться найти удаленные файлы и восстановить их. Выбор инструмента зависит от файловой системы.
Еще один совет: возможно, ваше программное обеспечение использовало временные файлы где-то еще в иерархии файловой системы. Проверьте /tmp/ , /var/tmp/ .
Редактировать, отвечая на дополнительный вопрос.
Когда ddrescuelog сообщает, что 99,73% блоков были спасены, что это значит? Похоже, я должен ожидать некоторые результаты, а не пустой домашний диск.
Примечание: приведенный ниже пример не предназначен для охвата всех проблем и сценариев файловой системы, а также для разграничения секторов диска и единиц выделения файловой системы; это ответить только на вопрос.
Представьте, что ваш раздел - книга, энциклопедия, а не роман с сюжетом. Файлы статьи внутри. Дисковый блок (или сектор) похож на страницу в книге. Файловая система - это общий способ размещения статей на страницах. Некоторые страницы содержат оглавление (ToC), которое является проблемой файловой системы на нашей картинке и может выглядеть примерно так:
статья № 289: страницы 2076, 2077, 2078, 402, 403.
Обратите внимание, что эта статья фрагментирована в виде файла. На другой странице, но все еще в ToC, у нас есть что-то вроде структуры папок:
...
people/: см. ToC на стр. 43.
...
(страница 43)
mathematicians/: см. ToC на стр. 80.
famous Poles/: см. ToC на стр. 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/).
В ToC также может быть раздел, который гласит:
"пустые" страницы: 567, 568, 569, 2070, 2071…
На данной странице есть текст (то есть данные), даже если она не принадлежит ни одной статье, существующей в то время. Это связано с тем, что процесс удаления статьи влияет только на оглавление. ToC является единственным определенным способом определить, относится ли данная страница к статье, к какой статье, или ее можно считать пустой и перезаписанной. Более того: невозможно найти "пустую страницу" без ToC. В энциклопедии кажется странным иметь пустую страницу в качестве части статьи, но сектор, полный 0 с, или пробелов, или чего-либо еще, может быть частью файла. Это все о ToC.
Некоторые из ваших страниц (блоков) не были спасены (пока). Любой из них может быть страницей с данными статьи или Toc- метаданными. Возможности:
- Отсутствующий блок - это блок данных (скажем, стр. 2078). Вы знаете путь к статье о Евклиде и о том, на каких страницах он находится, но одна из страниц пуста, хотя не должна. Статья недействительна.
- Отсутствующий блок - это блок метаданных. Некоторые сценарии:
- Вы потеряли трек о свободном пространстве.
- Вы знаете, что есть
./people/mathematicians/Euclid путь, но вам не хватает информации, на каких страницах статьи. Найти статью невозможно, если вы уже ничего о ней не знаете (например, запись о человеке, скорее всего, содержит слово "рожденный"; файлы PDF начинаются с «% PDF»).
- Вы знаете, что на таких-то страницах есть одна статья, но нет полного пути к ней. В этом случае вы можете поместить его в
lost+found и именно это сделает fsck . На нашей картине есть возможности (среди прочих):
- Отсутствует страница 80: вы знаете (со страницы 43), что есть раздел (папка) по
mathematicians , но вы не знаете, что статья № 289 должна быть в ней под названием "Евклид".
- Недостающая страница 43: вы не знаете, что должна быть статья № 14 об Адаме и Еве, ни разделы с математиками, ни с известными поляками; но вы можете видеть (на странице 80), что есть некоторый раздел со статьями о Евклиде и Банахе, и есть другой раздел (страница 82) со статьями о Банахе и Костюшко. Это то, что может происходить с вашим
/home . Статьи (файлы) есть и могут быть действительными. Они не могут быть достигнуты путем, потому что у вас нет Toc вашего /home .
- Любая комбинация вышеупомянутых проблем может возникнуть, если есть несколько блоков, которые не могут быть восстановлены.
- (РЕДАКТИРОВАТЬ) Отсутствующий блок может быть помечен как пустой. В этом случае вы ничего не потеряете.
