Восстановление массивно фрагментированных файлов с частичным изображением и списком их секторов

Question

В попытке восстановить как можно больше данных с неисправного жесткого диска емкостью 3 ТБ я сделал следующее:

• Я сделал поверхностное сканирование с помощью HD Sentinel, в котором были обнаружены две небольшие поврежденные области и около 100 поврежденных секторов (до этого количество было 16).
• Затем я определил, какие файлы были повреждены плохими секторами, используя различные методы.
• Я переместил эти файлы (шесть больших видеофайлов) в специальную папку и скопировал остальные файлы и папки, уменьшив порядок их важности; все было успешно скопировано, кроме одного незначительного файла .eml, который оказался рядом с уже определенными поврежденными секторами.
• Затем я решил, что самый безопасный способ получить максимальную отдачу от оставшихся файлов (телевизионные трансляции, которые больше не находятся в сети и для которых у меня нет резервной копии), - это использовать ddrescue - но поскольку единственный пустой жесткий диск, который у меня был, был емкостью 500 ГБ. Я не мог представить все. Некоторые из этих файлов сильно фрагментированы (от 6000 до 12000 фрагментов каждый - они были загружены одновременно, я думаю, именно поэтому они были записаны «чересстрочным» шаблоном, вызывающим такой уровень фрагментации, поскольку в противном случае на жестком диске было много свободного места), поэтому Я не мог восстановить их, просто извлекая занятые ими сектора, но я думал, что, создав образы первых 10 ГБ, обычно содержащих весь MFT и все другие системные файлы, а также четыре области, где были расположены эти файлы, я смог бы извлечь их легко из изображения, используя WinHex или R-Studio.

Но, к сожалению, я не получил весь MFT: некоторые из них (как я позже узнал, просматривая полный список nfi.exe того раздела, который я сделал ранее) расположены вокруг отметки 200 ГБ, а третий блок расположен в самый конец раздела, близкий к отметке 3 ТБ. Я не думал, что состояние жесткого диска ухудшится так быстро во время попытки восстановления (теперь у него более 12000 перераспределенных секторов плюс 9000 ожидающих секторов, всего несколько часов спустя! ...), и я не принял меры предосторожности чтобы сохранить MFT из WinHex, когда я мог. Теперь, когда ddrescue стал мучительно медленным, я, вероятно, не получу весь MFT. Кроме того, если я открываю этот частичный образ с помощью WinHex, он использует тот же моментальный снимок тома, который был создан при проверке физического устройства, нужные файлы отображаются в списке с их правильным размером и датами, если я нажимаю на них, сначала отображается правильный сектор, но он по-прежнему не может извлечь их (извлекаются только 0-байтовые файлы), очевидно, что моментальный снимок тома не содержит всех необходимых данных, относящихся к выделенным секторам, WinHex, кажется, полагается на MFT в этот момент, так что выиграл тоже не работает.

Но я восстановил значительную часть фрагментов данных, содержащих эти шесть файлов, и у меня есть для каждого из них подробный список секторов / кластеров, которые они занимают (полученные с помощью трех разных инструментов: nfi.exe, Recuva, HD Sentinel), Теперь, как я могу восстановить эти файлы с этой информацией, используя автоматический скрипт? (Это было бы невозможной задачей сделать это вручную.)

С помощью ddrescue я мог бы использовать ключи -i (позиция ввода) -o (позиция вывода) и -s (размер ввода), но как мне автоматизировать процесс и запускать эти тысячи команд одновременно?

В Windows я знаю инструмент командной строки dsfo, который может извлекать данные из любого источника в файл назначения с помощью команды, подобной этой:

dsfo [source] [offset] [size] [destination]

Я мог бы отредактировать свой список секторов / кластеров, используя комбинацию Calc и TEDNotepad, чтобы создать список команд dsfo, но это создаст тысячи фрагментов, к которым мне потом придется как-то присоединиться. Есть ли лучший способ сделать это за один шаг?

---

---

РЕДАКТИРОВАТЬ :

Итак, я взял список кластеров / секторов для одного из этих файлов, созданных HD Sentinel, который представлен так:

R:\fichiers corrompus\2017_07_2223_58 - Arte - Pink Floyd - The Dark Side of the Moon Live.mp4
Total Size: 883 787 365 bytes   Position: 0     Attributes: Arc
Number of file fragments: 6040
VCN: 0  LCN: 516530293  Length: 4288    sectors: 4132506536 - 4132540839
VCN: 4288   LCN: 516534613  Length: 16  sectors: 4132541096 - 4132541223
VCN: 4304   LCN: 516534645  Length: 64  sectors: 4132541352 - 4132541863
VCN: 4368   LCN: 516534725  Length: 16  sectors: 4132541992 - 4132542119
VCN: 4384   LCN: 516534757  Length: 48  sectors: 4132542248 - 4132542631
VCN: 4432   LCN: 516534853  Length: 32  sectors: 4132543016 - 4132543271
VCN: 4464   LCN: 516534901  Length: 16  sectors: 4132543400 - 4132543527
VCN: 4480   LCN: 516534933  Length: 48  sectors: 4132543656 - 4132544039
VCN: 4528   LCN: 516535013  Length: 16  sectors: 4132544296 - 4132544423
...
VCN: 215760 LCN: 568126709  Length: 9   sectors: 4545277864 - 4545277935

Первое поле, вероятно, обозначает «Номер виртуального кластера» (подробное описание в интегрированной справке не найдено), в любом случае, это значение, очевидно, представляет номер кластера относительно начала файла. Второе значение должно быть «Logical Cluster Number» и является номером кластера относительно начала раздела (см. Ниже, я сначала ошибся, думая, что это значение было относительно всего устройства). Третье значение представляет длину каждого фрагмента, также измеренную в кластерах. Эти три значения должны быть достаточными для моих намерений и целей.

Я импортировал это в блокнот TED и использовал функцию «Инструменты»> «Линии»> «Столбцы, числа», выбрал столбцы 2, 3, 1 с вкладками в качестве разделителей, что привело к следующему выводу:

LCN: 516530293  Length: 4288    VCN: 0
LCN: 516534613  Length: 16  VCN: 4288
LCN: 516534645  Length: 64  VCN: 4304
LCN: 516534725  Length: 16  VCN: 4368
LCN: 516534757  Length: 48  VCN: 4384
LCN: 516534853  Length: 32  VCN: 4432
LCN: 516534901  Length: 16  VCN: 4464
LCN: 516534933  Length: 48  VCN: 4480
LCN: 516535013  Length: 16  VCN: 4528
...
LCN: 568126709  Length: 9   VCN: 215760 

Затем я импортировал это в Calc с табуляторами и пробелами в качестве разделителей, добавил столбец для вычисления входного смещения из номера кластера (= LCN * 8 * 512), другой для вычисления длины в байтах из длины в кластерах (= длина * 8 * 512) и, наконец, еще один, чтобы получить выходное смещение из значения VCN (= VCN * 8 * 512), вставил формулы во все остальные строки, удалил лишние столбцы, заменил «LCN:» на «ddrescue /media /sdb1 /ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i », заменил« Length:»на« -s », заменил« VCN:»на« -o »...
Теперь у меня есть это (кроме 6000-12000 строк для каждого файла):

ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115708080128 -s 17563648 -o 0
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115725774848 -s 65536 -o 17563648
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115725905920 -s 262144 -o 17629184
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115726233600 -s 65536 -o 17891328
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115726364672 -s 196608 -o 17956864
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115726757888 -s 131072 -o 18153472
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115726954496 -s 65536 -o 18284544
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115727085568 -s 196608 -o 18350080
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2115727413248 -s 65536 -o 18546688
...
ddrescue /media/sdb1/ST3000DM001-2.dd /media/sdb1/201707222358.mp4 -i 2327047000064 -s 36864 -o 883752960

Итак, как проще всего запустить эту огромную серию команд в реальной системе Knoppix? Что в Linux эквивалентно пакетному сценарию для командной строки в Windows?

(Я мог бы найти этот конкретный файл в сети P2P, поэтому он позволит мне проверить, работает ли этот метод безупречно, и, если да, оценить уровень ущерба. Нет такой удачи для пяти других. Один из них не фрагментирован, поэтому я мог бы извлечь его как один кусок данных: в конце есть много пустых секторов, но остальные могут быть прочитаны. Таким образом, осталось четыре файла для извлечения таким образом.)

Answer 1

Поэтому я запустил эти сценарии ddrescue (сначала сделал их исполняемыми с помощью команды «chmod +x», затем вызвал их с помощью ./name_of_the_script):

- Сначала команды не работали, ddrescue выдавал только ошибки, мне пришлось снова редактировать сценарии, чтобы параметры помещались перед именами входных и выходных файлов. Затем команды выглядели так:

ddrescue -P -i 2115843346432 -s 17563648 -o 0  ST3000DM001-2.dd 201707222358.mp4
ddrescue -P -i 2115861041152 -s 65536 -o 17563648  ST3000DM001-2.dd 201707222358.mp4
ddrescue -P -i 2115861172224 -s 262144 -o 17629184  ST3000DM001-2.dd 201707222358.mp4
ddrescue -P -i 2115861499904 -s 65536 -o 17891328  ST3000DM001-2.dd 201707222358.mp4
ddrescue -P -i 2115861630976 -s 196608 -o 17956864  ST3000DM001-2.dd 201707222358.mp4
ddrescue -P -i 2115862024192 -s 131072 -o 18153472  ST3000DM001-2.dd 201707222358.mp4
...
ddrescue -P -i 2327182266368 -s 36864 -o 883752960  ST3000DM001-2.dd 201707222358.mp4

(Total size of that file : 883787365, or 883789824 with the slack space.)
(“-P” stands for “preview”, “-i” for “input position”, “-s” for “size”, “-o” for “output position”.)
(The paths could be omitted as the scripts, the image file and the expected output files were all in the same directory.)

- Затем с первой попытки был получен нечитаемый файл без правильного заголовка MP4. Зачем ? Поскольку список, предоставленный Hard Disk Sentinel, содержит физические / абсолютные номера секторов, но номера логических кластеров (я подтвердил, открыв файл образа с WinHex), поэтому мне пришлось добавить 264192x512 к расчету входного смещения (смещение раздела равно 264192 секторы, или 129 МБ).

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

(Я сделал все это на дополнительном компьютере, работающем в Knoppix, с карты памяти и использовал TeamViewer для управления им со своего основного компьютера в Windows 7, а также для простой передачи файлов сценариев. Может быть, есть более простая установка для таких целей, но, ну, это работает! :^ Р)

- Но, конечно, есть поврежденные части, поскольку в этом частичном изображении были нечитаемые сектора. Как я мог узнать где, быстро и надежно? Что ж...
У меня была идея использовать режим ddrescue «генерировать», который создает лог-файлы (или файлы-карты, как они теперь называются), анализируя выходные данные и учитывая, что полностью пустые сектора являются непрочитанными секторами, помеченными «?», Остальные отмечены «+» ». Поскольку ddrescue ожидает входной файл и выходной файл, но в этом режиме фактически анализируется только выходной файл, я создал фиктивные входные файлы с помощью этой команды, которая копирует только 1 МБ, но увеличивает размер до размера выходных файлов (только для сэкономить время и пространство):

ddrescue -s 1048576 -x 883789824 201707222358.mp4 201707222358copy.mp4

Затем я запустил команду «generate»:

ddrescue -G 201707222358copy.mp4 201707222358.mp4 201707222358-generate.log

А затем я открыл эти файлы с помощью ddrescueview:

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

А потом я похлопал себя по спине одной рукой, в то время как я шлепал себя по лицу другой за то, что использовал этот жесткий диск 3 ТБ каждый день в течение нескольких месяцев без какой-либо резервной копии ... (Сначала предполагалось хранить только временные данные, в то время как я собирался освободить место на других жестких дисках, но это заняло больше времени, чем ожидалось, и у меня не хватило места для хранения таких видео и даже моих личных фотографий и видео в какой-то момент , это могло быть серьезной катастрофой, но «это всего лишь сбой», как сказал бы Дик Джонс.)