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

Під час спроби відновити якомога більше даних із жорсткого диска 3TB, що триває, я працював так:

• Я зробив сканування на поверхні за допомогою HD Sentinel, який ідентифікував дві невеликі пошкоджені ділянки і близько 100 поганих секторів (до того, як підрахунок становив 16).
• Потім Я визначив, на які файли впливають погані сектори використання різні методи .
• Я перемістив ці файли (шість великих відеофайлів) у спеціальну папку і скопіював інші файли та папки за порядком зменшення важливості; все було успішно скопійовано, за винятком одного неважливого .eml-файлу, який опинився поруч із вже виявленими поганими секторами.
• Тоді я зрозумів, що найбезпечніший спосіб отримати максимальну віддачу від решти файлів (телевізійних передач, які більше не є онлайн і для яких у мене немає резервної копії) буде використовувати ddrescue - але так як єдиний порожній жорсткий диск у мене був 500 Гб , Я не міг все зображення. Деякі з цих файлів масово фрагментовані (від 6000 до 12000 фрагментів кожен - вони були завантажені одночасно, я думаю, тому вони були написані в "переплетеному" шаблоні, що викликає такий рівень фрагментації, оскільки в іншому випадку на жорсткому диску було багато вільного місця), Я не міг відновити їх просто шляхом вилучення секторів, які вони займали, але я думав, що, переглядаючи перші 10 Гб, які зазвичай містять весь MFT і всі інші системні файли, а також чотири області, де ці файли знаходилися, я міг би їх легко витягти з зображення, використовуючи WinHex або R-Studio.

Але, на жаль, я не отримав цілий MFT: деякі з них (як я пізніше виявив, що вивчають повний список nfi.exe цього розділу, який я зробив раніше), розташовані приблизно на позначці 200 Гб, а третій - на самий кінець розділу, близький до позначки 3TB. Я не думав, що стан жорсткого диска погіршиться так швидко під час спроби відновлення (тепер він має більше 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, але він створив би тисячі блоків, які мені тоді доведеться якось приєднати. Чи є кращий спосіб зробити це за один крок?

EDIT:

Тому я взяв список кластерів / секторів для одного з цих файлів, створених 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

Перше поле, мабуть, означає "Віртуальний номер кластера" (детального опису в інтегрованій довідці не знайдено). Друге значення має бути "Номер логічного кластера" і номер кластера щодо початку розділу (див. Нижче, спочатку я помилився, думаючи, що це значення було відносно всього пристрою). Третя величина являє собою довжину кожного фрагмента, що також вимірюється в кластерах. Ці три цінності повинні бути достатніми для моїх намірів і цілей.

Я імпортував цей файл у блокнот TED і використовував "Інструменти" & gt; "Лінії" & gt; Функція «Стовпці, числа», виділені стовпці 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-мережі, тому це дозволить мені перевірити, чи працює цей метод бездоганно, і якщо це так, щоб оцінити рівень пошкодження. фрагментований, тому я міг би витягти його як один фрагмент даних: біля кінця є багато порожніх секторів, але все інше читається.

Тому я виконав ці скрипти 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)

- Але, звичайно, є пошкоджені частини, оскільки в цьому частковому зображенні були нечитані сектори. Як я можу знати, де, швидко і надійно? Добре...
У мене була ідея використовувати режим generis ddrescue, який створює лог-файли (або файли mapfiles так, як вони зараз називаються) шляхом аналізу виводу і враховуючи, що абсолютно порожні сектори є непрочитаними секторами, позначеними як "?" ”. Оскільки ddrescue очікує вхідного файлу та вихідного файлу, але в цьому режимі фактично проаналізовано лише вихідний файл, я створив фіктивні вхідні файли з цією командою, яка копіює лише 1 Мб, але розширює розмір до розміру вихідних файлів (лише для заощаджуйте час і простір):

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

Потім я запустив команду "generate":

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

Потім я відкрив ці файли з ddrescueview:

(Три з шести файлів серйозно пошкоджені, як перший вище, з великими шматками порожніх даних, у трьох інших є лише декілька корумпованих секторів, як другий. з однією командою ddrescue.)

А потім я потиснув себе по спині однією рукою, в той час, як я ляпав обличчям іншим за те, що використовував цей 3TB HDD щодня протягом місяців без резервного копіювання ... (Спочатку він повинен був зберігати тільки тимчасові речі, Я б зробив місце на інших жорстких дисках, але це зайняло більше часу, ніж очікувалося, і мені не вистачило місця для зберігання таких відео, і навіть мої особисті фотографії та відео в якийсь момент це могло стати великою катастрофою, але “це лише глюк », як би сказав Дік Джонс.)