Приступая к делу: testdisk может перемещаться по файловой системе и иерархии (по-видимому, как будто она не повреждена) и восстанавливать файлы по отдельности . Есть ли способ сделать так, чтобы все они выполнялись автоматически?
История:
Я работаю от клона dd неизменяемого клона gddrescue (от сектора к сектору) на ненадежном внешнем USB-накопителе емкостью 3 ТБ, который использовался на ~ 2016 rPI до октября 2017 года. Я считаю, что он содержал 2 раздела: 6 ГБ и ~ 3 ТБ (??). 6GB был восстановлен и установлен. При клонировании ddrescue не смог очистить ~ 1 МБ (всего) по 25 областям диска.
Моя цель - спасти как можно большую организацию файлов раздела, файлов и времени модификации. Прежде всего был использован, но теряет организацию (большая часть стоимости).
Сейчас я работаю с Ubuntu 16.04.03LTS, таблица разделов неизменяемого клона имеет неправильные границы, и я использовал testdisk, чтобы записать вероятный диск на диск восстановления - и восстановил файловую систему первого небольшого раздела. Интересно, что fdisk сообщает о типе метки диска как DOS и упоминает ограничение (2 ^ 32 сектора?), А большой раздел, написанный testdisk, отображается как только 2 ТБ. С помощью parted, я изменил его на GPT, и теперь его полный ~ 3 ТБ как ~ 5.86Gsectors.
С файловой системой 2-го раздела можно работать с помощью testdesk, и я могу индивидуально сохранять файлы. Но там, вероятно, более миллиона.
Вопрос: это говорит мне о том, что некоторая файловая система присутствует и частично не повреждена - но я не знаю, как использовать testdisk для автоматического захвата структуры файлов и файлов, которые присутствуют.
Может ли testdisk сделать это? Или есть другой инструмент, который может использовать то, что хорошо в файловой системе? Возможно, добавление кода в testdisk для автоматического выполнения этого - разумный подход?
Другой подход: после «исправления» таблицы разделов с помощью testdisk, e2fsck в разделе 2 (~ 3 ТБ) сообщает:
"" Размер файловой системы (в соответствии с суперблоком) составляет 730993525 блоков. Физический размер устройства составляет 536870911 блоков. Возможно, поврежден суперблок или таблица разделов!«»
Запуск mke2fs -S, за которым следует e2fsck, повсеместно приводит к ошибкам и ничего не оставляет.
Вполне вероятно, что в октябре 2017 года mke2fs -S был запущен на втором разделе, но с использованием исходной таблицы поврежденных разделов.
Третий подход: Testdisk довольно непрозрачен для меня, поэтому я написал программу для поиска суперблоков, проверил их последнюю точку монтирования и т.д. Таким образом, я уверен, что диск содержит неповрежденные суперблоки от большого раздела. Если у меня есть один из этих суперблоков, могу ли я использовать его так, чтобы остальное смог сделать e2fsck? Однако я полагаю, что суперблок будет иметь только адрес блока относительно начала раздела. Поскольку суперблок должен был находиться в одном из нескольких мест (и имеет известный шаблон пропуска), возможно, я мог бы использовать эту информацию, чтобы назначить правильное начало расположения раздела?
ТИА!