Восстановление массивно фрагментированных файлов с частичным изображением и списком их секторов
Пытаясь восстановить как можно больше данных с неисправного жесткого диска емкостью 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, поэтому он позволит мне проверить, работает ли этот метод безупречно, и, если да, оценить уровень ущерба. Нет такой удачи для пяти других. Один из них не фрагментирован, чтобы я мог извлечь его как один кусок данных: в конце есть много пустых секторов, но остальные читабельны. Таким образом, остается четыре файла для извлечения таким образом.)
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, а также для простой передачи файлов сценариев. Возможно, существует более простая настройка для такие цели, но, ну, это работает!:^p)
- Но, конечно, есть поврежденные части, поскольку в этом частичном изображении были нечитаемые сектора. Как я мог узнать где, быстро и надежно? Что ж...
У меня была идея использовать режим 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 ТБ без резервного копирования... (Сначала предполагалось, что он будет хранить только временные данные, а Я бы освободил место на других жестких дисках, но это заняло больше времени, чем ожидалось, и у меня не хватило места для хранения таких видео и даже моих личных фотографий и видео в какой-то момент, это могло бы стать серьезной катастрофой, но "это всего лишь глюк ", как сказал бы Дик Джонс.)