Разгребаем руины. Как восстановить удаленные файлы на разделах NTFS

На­деж­ность NTFS — это одно, а оши­боч­но уда­лен­ные фай­лы — сов­сем дру­гое. Фай­ловая сис­тема, даже такая мощ­ная, как NTFS, бес­силь­на защитить поль­зовате­ля от себя самого. Прек­расно, если уда­лен­ный файл сох­ранил­ся в "Кор­зине", но что делать, если там его не ока­жет­ся? Как пос­тупить, если ты слу­чай­но уда­лил нуж­ное фай­ло, а теперь в отча­янье куса­ешь лок­ти и про­чие час­ти тела? Глав­ное — не панико­вать, а о том, как спра­вить­ся с этой бедой, я сей­час рас­ска­жу.

ПАКЕТ FILE_DISPOSITION_INFORMATION

IRP_MJ_SET_INFORMATION/FILE_DISPOSITION_INFORMATION — это пакеты, посыла­емые драй­веру при уда­лении фай­ла (имей это в виду при дизас­сем­бли­рова­нии). Что­бы уметь вос­ста­нав­ливать уда­лен­ные фай­лы, необ­ходимо отчетли­во пред­став­лять, что про­исхо­дит в про­цес­се уда­ления фай­ла с раз­дела NTFS. Вот пос­ледова­тель­ность выпол­няемых при этом дей­ствий.

1. Кор­ректи­рует­ся файл /$MFT:$BITMAP, каж­дый бит которо­го опре­деля­ет "занятость" соот­ветс­тву­ющей фай­ловой записи (FILE Record) в MFT (зна­чение 0 говорит о том, что запись не исполь­зует­ся).
2. Кор­ректи­рует­ся файл /$BITMAP, каж­дый бит которо­го опре­деля­ет "занятость" соот­ветс­тву­юще­го клас­тера (зна­чение 0 говорит о том, что клас­тер не исполь­зует­ся).
3. Фай­ловые записи, соот­ветс­тву­ющие фай­лу, помеча­ются как уда­лен­ные (поле FLAG, находя­щееся по сме­щению 16h от начала фай­ловой записи, сбра­сыва­ется в нуль).
4. Ссыл­ка на файл уда­ляет­ся из дво­ично­го дерева индексов. Тех­ничес­кие под­робнос­ти это­го про­цес­са здесь не рас­смат­рива­ются, пос­коль­ку вос­ста­новить таб­лицу индексов вруч­ную смо­жет толь­ко "гуру". Кро­ме того, в таком вос­ста­нов­лении нет необ­ходимос­ти. Ведь в NTFS индексы игра­ют вспо­мога­тель­ную роль, и гораз­до про­ще пере­индекси­ровать каталог заново, чем вос­ста­нав­ливать сба­лан­сирован­ное дво­ичное дерево (B-tree).
5. Обновля­ется атри­бут $STANDART_INFORMATION катало­га, в котором хра­нит­ся уда­ляемый файл (вре­мя пос­ледне­го дос­тупа и т. д.).
6. В фай­ле /$LogFile обновля­ется поле Sequence Number (изме­нения, про­исхо­дящие в жур­нале тран­закций, здесь не рас­смат­рива­ются).
7. Поля Update Sequence Number сле­дующих фай­ловых записей уве­личи­вают­ся на еди­ницу: сам уда­ляемый файл, текущий каталог, $MFT, /$MFT:$BITMAP, /$BITMAP, /$BOOT, /$TRACKING.LOG.

Ка­тало­ги уда­ляют­ся прак­тичес­ки так же, как и фай­лы. В этом нет ничего уди­витель­ного, так как с точ­ки зре­ния фай­ловой сис­темы каталог тоже пред­став­ляет файл осо­бого вида, содер­жащий внут­ри себя дво­ичное дерево индексов (B-tree).

Ни в том, ни в дру­гом слу­чае физичес­кого уда­ления фай­ла не про­исхо­дит, и он может быть лег­ко вос­ста­нов­лен. Лег­кое и быс­трое вос­ста­нов­ление воз­можно до тех пор, пока не будет затер­та фай­ловая запись (FILE Record), при­над­лежащая это­му фай­лу и хра­нящая его резиден­тное тело или спи­сок отрезков (run-list) нерези­ден­тно­го содер­жимого. Утра­та фай­ловой записи край­не неп­рият­на, пос­коль­ку в этом слу­чае файл при­дет­ся собирать по клас­терам. При этом сто­ит заметить, что чем силь­нее был фраг­менти­рован уда­лен­ный файл, тем слож­нее будет эта задача. К счастью, в отли­чие от FAT, NTFS не затира­ет пер­вого сим­вола име­ни фай­ла, что зна­читель­но упро­щает вос­ста­нов­ление.

АВТОМАТИЧЕСКОЕ ВОССТАНОВЛЕНИЕ УДАЛЕННЫХ ФАЙЛОВ

Ути­литы, вос­ста­нав­лива­ющие уда­лен­ные фай­лы, не вхо­дят в стан­дар­тный ком­плект пос­тавки Windows. Разуме­ется, это явный недос­таток — вспом­ни, ведь в MS-DOS такая ути­лита была! Сле­дова­тель­но, эти средс­тва при­ходит­ся при­обре­тать отдель­но. Одна из авто­мати­чес­ких ути­лит для вос­ста­нов­ления уда­лен­ных фай­лов — GetDataBack. Опа­саясь раз­рушить фай­ловую сис­тему окон­чатель­но, боль­шинс­тво таких ути­лит избе­гает пря­мой записи на диск. Вмес­то это­го поль­зовате­лю пред­лага­ется счи­тать уда­лен­ный файл и перепи­сать его в дру­гое мес­то, но толь­ко не на сам вос­ста­нав­лива­емый раз­дел. Не слиш­ком‑то удач­ное решение. А если на осталь­ных дис­ках сво­бод­ного мес­та нет, или если вос­ста­нав­лива­емый диск име­ет все­го лишь один логичес­кий раз­дел?

Пред­положим, нам необ­ходимо вос­ста­новить базу дан­ных объ­емом в нес­коль­ко гигабайт. Мож­но, конеч­но, под­клю­чить вто­рой вин­честер, ско­пиро­вать ее туда, а затем обратно. Одна­ко подумай, сколь­ко же это зай­мет вре­мени, не говоря уже о том, что сер­вер луч­ше не вык­лючать, а "горячую" замену под­держи­вают далеко не все жес­ткие дис­ки!

Дру­гой недос­таток подоб­ных ути­лит — слиш­ком мед­ленная работа. Вмес­то того что­бы най­ти один‑единс­твен­ный файл, имя которо­го нам извес­тно, они про­водят пол­номас­штаб­ные "манев­ры", ска­нируя весь раз­дел целиком. При работе с боль­шими дис­ками на это ухо­дит от одно­го до нес­коль­ких часов, при­чем это вре­мя фак­тичес­ки тра­тит­ся впус­тую.

С дру­гой сто­роны, ути­литы, вно­сящие изме­нения непос­редс­твен­но в струк­туру NTFS, рис­куют серь­езно пов­редить дис­ковый том, пос­ле чего ему не помогут даже про­фес­сиона­лы. Нас­тоящие хакеры не доверя­ют никако­му коду, кро­ме соз­данно­го лич­но ими, осо­бен­но, если исходные тек­сты недос­тупны, а докумен­тация туман­на и двус­мыслен­на. Раз­личные вер­сии NTFS отли­чают­ся друг от дру­га. Пос­ледние радикаль­ные изме­нения про­изош­ли в Windows XP (NTFS вер­сии 3.1) — мас­сив пос­ледова­тель­нос­тей обновле­ния (Update Sequence Number-n-Array) перемес­тился на шесть бай­тов впе­ред, а его мес­то было отда­но под вырав­нивание и поле номера текущей фай­ловой записи (Number of this MFT Record). С тех пор фор­мат фай­ловой сис­темы не пре­тер­пел каких‑либо сущес­твен­ных архи­тек­турных изме­нений.

На­конец, воз­можна и такая ситу­ация, ког­да ути­лит вос­ста­нов­ления прос­то не ока­жет­ся под рукой в тот момент, ког­да вам сроч­но пот­ребу­ется вос­ста­новить какой‑нибудь цен­ный файл. Законов Мэр­фи еще ник­то не отме­нял! В этом слу­чае вам при­дет­ся рас­счи­тывать толь­ко на свои силы.

РУЧНОЕ ВОССТАНОВЛЕНИЕ ОШИБОЧНО УДАЛЕННЫХ ФАЙЛОВ

Нач­нем с прос­тей­шего. Файл толь­ко что уда­лен, и при­над­лежащая ему фай­ловая запись еще не затер­та. Как най­ти его на дис­ке? Сущес­тву­ет два спо­соба — "теоре­тичес­кий" и "прак­тичес­кий". Теоре­тичес­кий метод исклю­читель­но надежен, но тре­бует допол­нитель­ных опе­раций, выпол­нения которых мож­но избе­жать, при­няв ряд прак­тичес­ких допуще­ний.

Те­оре­тичес­ки гра­мот­ный и пра­виль­ный под­ход сос­тоит в сле­дующем. Извле­каем из заг­рузоч­ного сек­тора ука­затель на MFT, извле­каем из нее пер­вую запись (она опи­сыва­ет $MFT), находим атри­бут $DATA (80h), декоди­руем спи­сок отрезков (data runs) и пос­ледова­тель­но чита­ем все записи в MFT, ана­лизи­руя содер­жимое атри­бута $FILE_NAME (30h) — имя фай­ла. Обра­ти вни­мание, что таких атри­бутов у фай­ла может быть нес­коль­ко. Этот же атри­бут хра­нит ссыл­ку на родитель­ский каталог. Поэто­му, если нес­коль­ко одно­имен­ных фай­лов были уда­лены из раз­личных катало­гов, то необ­ходимо выяс­нить, какой имен­но из них дол­жен быть вос­ста­нов­лен.

Прак­тичес­кий под­ход выг­лядит сле­дующим обра­зом. В девяти слу­чаях из десяти файл $MFT не фраг­менти­рован и рас­полага­ется в самом начале дис­ка. Име­на фай­лов хра­нят­ся по сме­щению EAh от начала сек­тора, в начале которо­го рас­положе­на сиг­натура FILE0. Поэто­му мож­но прос­то запус­тить любой дис­ковый редак­тор, ввес­ти имя вос­ста­нав­лива­емо­го фай­ла в кодиров­ке UNICODE и дать редак­тору ука­зание искать его по сме­щению F0h от начала сек­тора.

Ког­да же иско­мая стро­ка будет най­дена, необ­ходимо про­верить, находит­ся ли в начале сек­тора сиг­натура FILE0. Если такой сиг­натуры в начале сек­тора нет, сле­дует про­дол­жить поиск. Двух­бай­товое поле по сме­щению 16h от начала сек­тора содер­жит фла­ги записи: 00h — запись не исполь­зует­ся или была уда­лена, 01h — запись исполь­зует­ся, 02h — запись исполь­зует­ся и опи­сыва­ет каталог. Встре­чают­ся и дру­гие зна­чения, нап­ример, 04h, 08h. Эти зна­чения не докумен­тирова­ны. Воз­можно, что имен­но ты смо­жешь про­лить свет на этот воп­рос?

Ис­прав­ляем 00h на 01h, записы­ваем изме­нения и… Ничего не выходит?! А что же ты хотел! Ведь помимо это­го необ­ходимо выпол­нить еще нес­коль­ко дей­ствий. Во‑пер­вых, сле­дует сооб­щить фай­лу /$MFT:$BITMAP, что дан­ная запись MFT вновь исполь­зует­ся. Во‑вто­рых, необ­ходимо исклю­чить из фай­ла /$BITMAP номера клас­теров, при­над­лежащие вос­ста­нав­лива­емо­му фай­лу. Наконец, необ­ходимо перес­тро­ить дво­ичное дерево индексов, хра­нящее содер­жимое катало­га.

Пер­вые два пун­кта не пред­став­ляют серь­езной проб­лемы, но вот над пос­ледней задачей при­дет­ся повозить­ся. Хотя ее мож­но сущес­твен­но упростить, прос­то запус­тив chkdsk с клю­чом /F. Ути­лита chkdsk самос­тоятель­но най­дет "потерян­ный" файл и вне­сет все необ­ходимые изме­нения в фай­ловую сис­тему. От вас пот­ребу­ется толь­ко уста­новить флаг по сме­щению 16h в еди­ницу, а все осталь­ное сде­лает chkdsk. Пос­ле этих нехит­рых манипу­ляций вос­ста­нов­ленный файл ока­жет­ся в сво­ем род­ном катало­ге.

INFO

В Windows 10 ути­литу chkdsk мож­но запус­тить из коман­дной стро­ки (cmd.exe) или из кон­соли PowerShell. Пом­ни, что выпол­нение chkdsk тре­бует наличия сис­темных при­виле­гий, поэто­му кон­соль сле­дует запус­кать от име­ни Адми­нис­тра­тора. Если ты пыта­ешь­ся выпол­нить про­вер­ку сис­темно­го раз­дела, на котором рас­полага­ется текущая вер­сия ОС, прог­рамма не смо­жет про­верить диск, так как том ока­жет­ся заб­локиро­ван­ным. В этом слу­чае тебе будет пред­ложено выпол­нить про­вер­ку при сле­дующей заг­рузке Windows.

ВОССТАНАВЛИВАЕМ РУИНЫ

Рас­смот­рим более слож­ный слу­чай вос­ста­нов­ления, а имен­но — ситу­ацию, ког­да фай­ловая запись уже затер­та. Если уда­лен­ный файл был резиден­тным (хра­нил свое тело в MFT), то вос­ста­нав­ливать уже нечего. Даже если на ранее занима­емом им мес­те соз­дан нерези­ден­тный файл (а фай­ловая запись нерези­ден­тно­го фай­ла закан­чива­ется там, где начина­ется резиден­тное тело), опе­раци­онная сис­тема забот­ливо запол­нит оставший­ся "хвост" нулями, и для вос­ста­нов­ления ори­гиналь­ного содер­жимого при­дет­ся при­бег­нуть к дорогос­тояще­му обо­рудо­ванию, чита­юще­му повер­хность жес­тко­го дис­ка на физичес­ком уров­не.

С нерези­ден­тны­ми фай­лами, хра­нящи­ми свое тело вне MFT, ситу­ация обсто­ит не так пла­чев­но, хотя и здесь проб­лем тоже хва­тает. Порядок раз­мещения фай­ла на дис­ке хра­нит­ся в спис­ке отрезков (run-list) внут­ри фай­ловой записи в MFT. При этом, пос­коль­ку фай­ловая запись уже затер­та, воз­можен лишь кон­текс­тный поиск по содер­жимому. Запус­каем дис­ковый редак­тор, вво­дим пос­ледова­тель­ность, заведо­мо содер­жащу­юся в уда­лен­ном фай­ле, но не встре­чающуюся во всех осталь­ных, и даем редак­тору коман­ду начать поиск. Для уско­рения поис­ка мож­но искать толь­ко в сво­бод­ном дис­ковом прос­транс­тве (за это отве­чает файл /$BITMAP).

Вос­ста­нов­ление неф­рагмен­тирован­ных фай­лов осу­щест­вля­ется эле­мен­тарно. Дос­таточ­но прос­то выделить груп­пу сек­торов и записать ее содер­жимое на диск.

WARNING

Пов­торяю еще раз — ни в коем слу­чае не записы­вай фай­лы на сам вос­ста­нав­лива­емый том!

Единс­твен­ная проб­лема зак­люча­ется в опре­деле­нии ори­гиналь­ной дли­ны. Некото­рые типы фай­лов допус­кают при­сутс­твие "мусора" в сво­ем хвос­те. В этом слу­чае мож­но сле­довать пра­вилу, гла­сяще­му, что перебор луч­ше недобо­ра. Одна­ко это спра­вед­ливо не для всех фай­лов! Если конец фай­ла не уда­ется опре­делить визу­аль­но (нап­ример, pdf-фай­лы завер­шают­ся сиг­натурой %%EOF), про­ана­лизи­руй заголо­вок фай­ла. Как пра­вило, наряду с про­чей полез­ной информа­цией там при­сутс­тву­ет и раз­мер фай­ла. В дан­ном слу­чае все зависит от струк­туры кон­крет­ного фай­ла, и уни­вер­саль­ных рекомен­даций дать невоз­можно.

Ес­ли вос­ста­нав­лива­емый файл фраг­менти­рован, то ситу­ация осложня­ется. По прав­де говоря, она прак­тичес­ки без­надеж­на, пос­коль­ку, что­бы соб­рать раз­рознен­ные цепоч­ки клас­теров воеди­но, необ­ходимо хорошо знать содер­жимое уда­лен­ного фай­ла. В этом смыс­ле NTFS вос­ста­нав­лива­ется нам­ного хуже, чем FAT. Пос­ледова­тель­ность фраг­ментов фай­ла, хра­няща­яся в FAT в виде одно­нап­равлен­ного спис­ка, очень живуча. Если спи­сок не пов­режден, дос­таточ­но лишь най­ти его пер­вый эле­мент (а сде­лать это про­ще прос­того, пос­коль­ку он будет ука­зывать на заголо­вок фай­ла с впол­не пред­ска­зуемым содер­жимым). Даже если спи­сок "раз­рубить" на нес­коль­ко час­тей, они про­дол­жат жить собс­твен­ной жизнью, и оста­нет­ся лишь подоб­рать ком­бинацию, в которой их необ­ходимо скле­ить воеди­но. Спи­сок гиб­нет лишь при пол­ном затира­нии FAT, что слу­чает­ся, пря­мо ска­жем, не час­то.

В NTFS же порядок фраг­ментов фай­ла хра­нит­ся в кро­хот­ных спис­ках отрезков, и их гибель — обыч­ное дело, пос­ле чего мы оста­емся один на один с мил­лионом бес­порядоч­но раз­бро­сан­ных клас­теров. С тек­сто­выми фай­лами еще мож­но работать, но что делать, если файл пред­став­лял собой элек­трон­ную таб­лицу, гра­фичес­кое изоб­ражение или архив? Без зна­ния стра­тегии выделе­ния дис­кового прос­транс­тва вос­ста­новить такой файл невоз­можно. Порядок, в котором драй­вер фай­ловой сис­темы находит под­ходящие сво­бод­ные фраг­менты, не пре­доп­ределен. Он варь­иру­ется в зависи­мос­ти от мно­жес­тва обсто­ятель­ств, одна­ко некото­рые законо­мер­ности в нем все же при­сутс­тву­ют.

В ходе ана­лиза спис­ков отрезков силь­но фраг­менти­рован­ных дис­ков мне уда­лось уста­новить сле­дующие законо­мер­ности. Сна­чала запол­няют­ся самые боль­шие "дыры", при­чем запол­нение про­исхо­дит в нап­равле­нии от кон­ца зоны MFT к кон­цу дис­ка. Затем драй­вер фай­ловой сис­темы воз­вра­щает­ся назад и начина­ет запол­нять "дыры" помень­ше. Так про­дол­жает­ся до тех пор, пока файл не ока­зыва­ется на дис­ке целиком. В пос­леднюю оче­редь запол­няют­ся "дыры" раз­мером в один клас­тер.

Прос­матри­вая кар­ту дис­ка, пред­став­ленную фай­лом /$BITMAP, мы можем в точ­ности вос­ста­новить порядок раз­мещения фраг­ментов уда­лен­ного фай­ла, нас­коро соб­рав их воеди­но. Во вся­ком слу­чае, теоре­тичес­ки такая воз­можность сущес­тву­ет. На прак­тике же на этом пути нас ждут ковар­ные пре­пятс­твия. Дело в том, что с момен­та соз­дания вос­ста­нав­лива­емо­го фай­ла кар­та сво­бод­ного дис­кового прос­транс­тва мог­ла радикаль­но изме­нить­ся. Вся­кая опе­рация уда­ления фай­лов выс­вобож­дает одну или нес­коль­ко "дыр", хаотич­но переме­шива­ющих­ся с "дырами" вос­ста­нав­лива­емо­го фай­ла. Как это­му про­тивос­тоять? Ска­ниру­ем MFT в поис­ках записей, помечен­ных как уда­лен­ные, но еще не затер­тых. Декоди­руем спис­ки отрезков и вычер­кива­ем соот­ветс­тву­ющие им фраг­менты из спис­ка кан­дидатов на вос­ста­нов­ление. Это сущес­твен­но сужа­ет круг поис­ка, хотя количес­тво ком­бинаций, в которые мож­но соб­рать фраг­менти­рован­ный файл, по‑преж­нему оста­ется велико. Но это не самое глав­ное.

Са­мое "инте­рес­ное" начина­ется, ког­да на диск одновре­мен­но записы­вают­ся нес­коль­ко фай­лов (нап­ример, ска­чива­емых из интерне­та), или ког­да раз­мер неко­его фай­ла пос­тепен­но уве­личи­вает­ся (это про­исхо­дит с докумен­тами Word при наборе тек­ста), и одновре­мен­но с этим на диск записы­вают­ся дру­гие фай­лы. Ког­да к сущес­тву­юще­му фай­лу дописы­вает­ся кро­шеч­ная пор­ция дан­ных, фай­ловая сис­тема находит наимень­шую "дыру", затем сле­дующую наимень­шую "дыру" и т. д., вплоть до тех пор, пока малень­кие "дыры" не исчерпа­ются. Ког­да это про­исхо­дит, нас­тупа­ет черед "дыр" боль­шего раз­мера. В резуль­тате файл силь­но фраг­менти­рует­ся. Кро­ме того, файл запол­няет­ся не от боль­ших дыр к мень­шим, а наобо­рот (т. е. про­исхо­дит инверсия стра­тегии раз­мещения). Таким обра­зом, малень­кие фраг­менты одно­го фай­ла переме­шива­ются с малень­кими фраг­мента­ми дру­гих фай­лов.

Ху­же все­го под­дают­ся вос­ста­нов­лению докумен­ты, соз­данные в Microsoft Office. Так про­исхо­дит, потому что при­ложе­ние соз­дает боль­шое количес­тво резер­вных копий редак­тиру­емо­го фай­ла, как в текущем катало­ге, так и в катало­ге %TEMP%. Разоб­рать­ся с тем, какой фраг­мент какому фай­лу при­над­лежит, очень нелег­ко!

Про­ще все­го вос­ста­нав­ливать ZIP-архи­вы. Для это­го тебе даже не пот­ребу­ется запус­кать дис­ковый редак­тор. Открой вре­мен­ный файл на запись, сде­лай seek на раз­мер сво­бод­ного дис­кового прос­транс­тва, зак­рой файл. А теперь обра­ботай его ути­литой pkzipfix.exe (или вос­поль­зуйся ути­литой ZIP Repair). В "исправ­ленном" фай­ле вол­шебным обра­зом появят­ся все уце­лев­шие ZIP-архи­вы! Внут­ренняя струк­тура ZIP-архи­ва такова, что pkzipfix лег­ко рас­позна­ет даже пере­упо­рядо­чен­ные бло­ки, поэто­му высокая сте­пень фраг­мента­ции ему не помеха.

ВОССТАНОВЛЕНИЕ РАЗДЕЛОВ NTFS ПОСЛЕ ФОРМАТИРОВАНИЯ

Пред­ставь себе, что слу­чилось самое страш­ное: ты потерял весь раз­дел NTFS целиком. Воз­можно, ты слу­чай­но отформа­тиро­вал его или пережил раз­рушитель­ный дис­ковый сбой. Где‑то там оста­лись мил­лиар­ды бай­тов бес­ценных дан­ных, теперь уже недос­тупных опе­раци­онной сис­теме. Как вер­нуть информа­цию к жиз­ни? До сих пор мы рас­смат­ривали лишь нез­начитель­ные дис­ковые сбои и лег­кие раз­рушения дан­ных наподо­бие оши­боч­но уда­лен­ных фай­лов. Теперь нас­тал черед рас­смот­реть вос­ста­нов­ление пос­ле тяжелых пов­режде­ний, при которых преж­нее содер­жимое тома ста­новит­ся недос­тупно опе­раци­онной сис­теме. При­чиной это­му может быть, нап­ример, неп­редумыш­ленное фор­матиро­вание или иска­жение глав­ной фай­ловой таб­лицы. Но не падай духом! Из любых переде­лок NTFS выходит с минималь­ными потеря­ми, и во всех этих слу­чаях воз­можно пол­ное вос­ста­нов­ление дан­ных, если к делу подой­ти пра­виль­но.

Про­ще все­го начать с фор­матиро­вания. Для экспе­римен­тов нам пот­ребу­ется ути­лита format.com, вхо­дящая в стан­дар­тный ком­плект пос­тавки Windows, а так­же дис­ковый раз­дел, не содер­жащий никакой цен­ной информа­ции.

WARNING

Луч­ше все­го про­водить экспе­римен­ты на вир­туаль­ной машине — VirtualBox или VMWare, эму­лиру­ющей жес­ткий диск и уско­ряющей про­цеду­ру фор­матиро­вания в сот­ни раз. Ведь вре­мя — это не толь­ко день­ги, но и бес­цель­но про­житые годы, про­веден­ные за созер­цани­ем инди­като­ра прог­ресса.

INFO

Ко­ман­да format в Windows 10 работа­ет с одной инте­рес­ной осо­бен­ностью, которую впол­не мож­но наз­вать багом: она не поз­воля­ет отформа­тиро­вать том, если поль­зователь не ука­зал его мет­ку, выдавая ошиб­ку: "ука­зана недопус­тимая мет­ка дис­ка". Что­бы испра­вить эту ошиб­ку, сде­лай сле­дующее. Перей­ди в Коман­дной стро­ке на диск, который ты хочешь отформа­тиро­вать, и набери коман­ду vol. В окне Коман­дной стро­ки отоб­разит­ся информа­ция об име­ни мет­ки и серий­ном номере тома. Затем, наб­рав коман­ду format с име­нем дис­ка, по зап­росу прог­раммы format.exe вве­ди получен­ную на пре­дыду­щем шаге мет­ку тома. Если том в нас­тоящее вре­мя исполь­зует­ся, сог­ласись с пред­ложени­ем опе­раци­онной сис­темы раз­монти­ровать его.

"Живой" вин­честер луч­ше не тро­гать, во вся­ком слу­чае, до тех пор, пока ты не научишь­ся его вос­ста­нав­ливать.

Действия, выполняемые при форматировании

Фор­матиро­вание дис­ка — это слож­ная мно­гос­тупен­чатая опе­рация, нам­ного более слож­ная и нам­ного более мно­гос­тупен­чатая, чем это может показать­ся на пер­вый взгляд. Свои иссле­дова­ния мы нач­нем с изу­чения неп­редумыш­ленно перефор­матиро­ван­ного тома NTFS.

При выпол­нении коман­ды format X: /U /FS:NTFS в фай­ловой сис­теме дис­ка X: про­исхо­дят сле­дующие изме­нения (фор­матиро­вание дис­ка ути­литой GUI, вызыва­емой из кон­текс­тно­го меню "про­вод­ника", осу­щест­вля­ется по ана­логич­ной схе­ме):

1. Фор­миру­ется заг­рузоч­ный сек­тор NTFS.
2. Генери­рует­ся новый серий­ный номер тома, который затем записы­вает­ся в заг­рузоч­ный сек­тор по сме­щению 48h бай­тов от его начала.
3. Рас­счи­тыва­ется новая кон­троль­ная сум­ма заг­рузоч­ного сек­тора, которая затем записы­вает­ся по сме­щению 50h от его начала. Соз­дает­ся новый файл $MFT, содер­жащий све­дения обо всех фай­лах на дис­ке. Как пра­вило, он записы­вает­ся поверх ста­рого фай­ла $MFT. Исклю­чения из это­го пра­вила быва­ют, но они край­не ред­ки. Обыч­но они про­исхо­дят, если преж­ний файл $MFT был заб­лагов­ремен­но переме­щен деф­рагмен­татором, или если при перефор­матиро­вании был наз­начен новый раз­мер клас­тера. Во всех осталь­ных слу­чаях пер­вые 24 фай­ловых записи (FILE Record) погиба­ют без­воз­врат­но. Эти записи содер­жат непос­редс­твен­но сам файл $MFT, $MFTMirr, кор­невой каталог, /$LogFile — файл тран­закций, /$BITMAP — кар­ту сво­бод­ного прос­транс­тва, /$Secure — дес­крип­торы безопас­ности, а так­же ряд дру­гих слу­жеб­ных фай­лов.
4. Ини­циали­зиру­ется файл $MFT:$DATA — наз­нача­ются новая дли­на фай­ла (ини­циали­зиру­ются $MFT:$30.AllocatedSize, $MFT:$30.RealSize, $MFT:$80.AllocatedSize, $MFT:$80.RealSize, $MFT:$80.CompressionSize, $MFT:$80.InitializedSize и $MFT:$80.LastVCN), дата и вре­мя соз­дания и пос­ледней модифи­кации (ини­циали­зиру­ются $MFT:$10.FileCreationTime, $MFT:$10.FileAlertedTime, $MFT:$10.FileReadTime, $MFT:$30.FileCreationTime, $MFT:$30.FileAlertedTime, $MFT:$30.MFTChangeTime и $MFT:$30.FileReadTime) и, самое глав­ное, соз­дает­ся новый спи­сок отрезков (data-runs), необ­ратимо затира­ющий ста­рый. Это зна­чит, что собирать фраг­менти­рован­ный файл $MFT нам при­дет­ся по час­тям.
5. Соз­дает­ся новый файл /$MFT:$BITMAP, отве­чающий за занятость фай­ловых записей в MFT. При этом все ста­рые записи помеча­ются как сво­бод­ные, одна­ко их фак­тичес­кого уда­ления не про­исхо­дит (поле FileRecord.flags оста­ется нет­ронутым), бла­года­ря чему про­цеду­ра вос­ста­нов­ления замет­но упро­щает­ся. Чаще все­го $MFT:$BITMAP рас­полага­ется на том же самом мес­те, что и ста­рый (т. е. меж­ду заг­рузоч­ным сек­тором и MFT), забивая преж­нее содер­жимое нулями, одна­ко с помощью ути­литы chkdsk его мож­но вос­ста­новить.
6. Соз­дает­ся новый файл /$BITMAP, отве­чающий за рас­пре­деле­ние дис­кового прос­транс­тва (сво­бод­ные и занятые клас­теры). Этот файл так­же записы­вает­ся поверх преж­него фай­ла /$BITMAP, который, тем не менее, может быть вос­ста­нов­лен с помощью chkdsk.
7. Соз­дает­ся новый файл жур­нала тран­закций — /$LogFile.
8. B заголо­вок фай­ловой записи $MFT заносит­ся новый LSN (LogFile Sequence Number).
9. $MFT наз­нача­ется новый номер пос­ледова­тель­нос­ти обновле­ния (Update Sequence Number).
10. Соз­дает­ся новое зер­кало $MFTMirr, необ­ратимо затира­ющее ста­рое (в текущих вер­сиях фай­ловых сис­тем оно рас­положе­но в середи­не раз­дела NTFS).
11. Соз­дают­ся новые /$Volume, /$AttrDef и дру­гие слу­жеб­ные фай­лы, игра­ющие сугубо вспо­мога­тель­ную роль и лег­ко вос­ста­нав­лива­емые ути­литой chkdsk. Сле­дует отме­тить, что хотя /$Volume и при­сутс­тву­ет в зер­каль­ной копии MFT, его цен­ность явно пре­уве­личе­на.
12. Осу­щест­вля­ется про­вер­ка целос­тнос­ти повер­хнос­ти дис­ка, и все обна­ружен­ные "пло­хие" клас­теры заносят­ся в файл /$BadClus.
13. Фор­миру­ется новый кор­невой каталог.
14. Ес­ли до фор­матиро­вания тома на нем при­сутс­тво­вал файл /System Volume Information, то он обновля­ется, в про­тив­ном слу­чае новый файл /System Volume Information соз­дает­ся толь­ко пос­ле перезаг­рузки.

На самом деле про­цесс фор­матиро­вания про­тека­ет нам­ного слож­нее. Тем не менее, для вос­ста­нов­ления дан­ных с неп­редна­мерен­но перефор­матиро­ван­ных раз­делов при­веден­ной здесь информа­ции впол­не дос­таточ­но. Углублен­ное обсужде­ние этих тех­ничес­ких деталей тре­бует­ся толь­ко прог­раммис­ту, раз­рабаты­вающе­му собс­твен­ную нес­тандар­тную ути­литу фор­матиро­вания. Заин­тересо­ван­ные читате­ли могут самос­тоятель­но дизас­сем­бли­ровать ути­литу format.com (рекомен­дует­ся делать это с помощью IDA Pro).

Совет

Ути­лита format.com содер­жит лишь высоко­уров­невую надс­трой­ку, опи­рающуюся на биб­лиоте­ки fsutil.dll, untfs.dll, и непос­редс­твен­но на сам драй­вер фай­ловой сис­темы. Так что дизас­сем­бли­ровать при­дет­ся мно­го. Что­бы упро­сить себе работу, мож­но про­наб­людать за про­цес­сом фор­матиро­вания с помощью "шпи­онских" средств, нап­ример, ути­лит Мар­ка Рус­синови­ча Process Monitor (procmon.exe), Diskmon.exe, бес­плат­ные копии которых мож­но ска­чать с сай­та https://docs.microsoft.com/en-us/sysinternals/. Кро­ме того, не забывай о точ­ках оста­нова на основные фун­кции native API, такие как NtFsControlFile, NtDeviceIoControlFile и т. д.

Автоматическое восстановление диска после форматирования

Фор­матиро­вание не унич­тожа­ет фай­ловые записи поль­зователь­ских фай­лов, и их мож­но пол­ностью вос­ста­новить. Сущес­тву­ет мно­жес­тво ути­лит для вос­ста­нов­ления дан­ных, нап­ример, R-Studio, EasyRecovery, GetDataBack, и т. д. Тем не менее, пря­мых нас­ледни­ков ути­литы unformat сре­ди них не наб­люда­ется. Ути­лита unformat.exe вос­ста­нав­ливала весь том целиком, а все перечис­ленные сов­ремен­ные средс­тва все­го лишь извле­кают отдель­ные уце­лев­шие фай­лы и катало­ги, перепи­сывая их на новый носитель. Вот здесь мы стал­кива­емся с рядом проб­лем.

Во‑пер­вых, это выбор носите­ля, на который будут извле­кать­ся вос­ста­нав­лива­емые дан­ные. Запись на опти­чес­кие накопи­тели отпа­дает сра­зу же, так как количес­тво носите­лей, пот­ребное для сох­ранения содер­жимого жес­тко­го дис­ка объ­емом в терабай­ты, неп­рием­лемо велико, да и сама тех­нология пишущих опти­чес­ких при­водов сегод­ня фак­тичес­ки ушла в прош­лое. Наконец, ни одна из извес­тных мне ути­лит авто­мати­чес­кого вос­ста­нов­ления дан­ных не поз­воля­ет "раз­резать" боль­шие фай­лы на нес­коль­ко малень­ких. Если в тво­ем рас­поряже­нии есть локаль­ная сеть, мож­но перег­нать дан­ные по ней. Одна­ко самый прос­той вари­ант — под­клю­чение внеш­него жес­тко­го дис­ка, кар­ты памяти или флеш‑накопи­теля. Для извле­чения пары сотен осо­бо цен­ных фай­лов такая методи­ка впол­не под­ходит.

Про­демонс­три­руем тех­нику авто­мати­чес­кого вос­ста­нов­ления дан­ных на при­мере ути­литы R-Studio от ком­пании R-Tools Technology. Это доволь­но мощ­ный и в тоже вре­мя прос­той в управле­нии инс­тру­мент, на который мож­но положить­ся. Пос­ле запус­ка ути­литы на экра­не появит­ся окно Па­нель дис­ков, где перечис­лены все физичес­кие устрой­ства и логичес­кие раз­делы. Най­ди сре­ди них тот, который тре­бует­ся вос­ста­новить, и, нажав пра­вую кноп­ку мыши, выбери опцию Ска­ниро­вать.

Прог­рамма пред­ложит ука­зать началь­ный сек­тор для ска­ниро­вания (поле Старт), который по умол­чанию равен нулю. Это зна­чение сле­дует оста­вить без изме­нений. Раз­мер ска­ниру­емой области (поле Раз­мер) по умол­чанию раз­верты­вает­ся на весь раз­дел. Это гаран­тиру­ет, что ска­нер обна­ружит все уце­лев­шие фай­ловые записи, хотя сам поиск зай­мет зна­читель­ное вре­мя. Мож­но ли уско­рить этот про­цесс? Давай возь­мем руч­ку и под­счи­таем. Пред­положим, что вос­ста­нав­лива­емый раз­дел содер­жит сто тысяч фай­лов. Типич­ный раз­мер фай­ловой записи сос­тавля­ет 1 Кбайт. При усло­вии, что файл $MFT не фраг­менти­рован, дос­таточ­но прос­каниро­вать все­го око­ло 100 Мбайт от начала раз­дела. Если эта величи­на (раз­мер прос­транс­тва, зарезер­вирован­ного под MFT) не пре­выша­ет 10% от пол­ной емкости тома и диск никог­да не запол­нялся более чем на 90%, то, ско­рее все­го, все так и есть.

В про­тив­ном слу­чае файл $MFT фраг­менти­рован и "живопис­но" раз­бро­сан по все­му дис­ку. Впро­чем, в слу­чае ошиб­ки мы ничем не рис­куем. Вво­дим зна­чение N Кбайт, где N — пред­полага­емое количес­тво фай­лов (каталог так­же счи­тает­ся фай­лом), и выпол­няем ска­ниро­вание. Если один или нес­коль­ко фай­лов оста­нут­ся необ­наружен­ными, воз­вра­щаем­ся к нас­трой­кам по умол­чанию и пов­торя­ем про­цеду­ру ска­ниро­вания вновь (если количес­тво име­ющих­ся фай­лов заранее неиз­вес­тно, сле­дует ука­зать зна­чение, рав­ное 10% от емкости тома). В поле Фай­ловая сис­тема выбира­ем фай­ловую сис­тему NTFS (мож­но оста­вить нас­трой­ки по умол­чанию, фай­ловую сис­тему дис­ка прог­рамма опре­деля­ет кор­рек­тно). Затем наж­мите кноп­ку Ска­ниро­вание и ска­ниро­вание нач­нется.

В про­цес­се ска­ниро­вания будут най­дены все уце­лев­шие фай­лы (как уда­лен­ные, так и нет). Кро­ме того, будет вос­ста­нов­лена струк­тура катало­гов, вклю­чая и кор­невой каталог. Пос­той­те! Как же так? Ведь, как ты пом­нишь, при фор­матиро­вании кор­невой каталог был унич­тожен и сфор­мирован заново! Но ничего уди­витель­ного в этом нет. Прос­то фай­ловая сис­тема NTFS еще раз доказа­ла свою живучесть — унич­тожить ее мож­но, ско­рее все­го, толь­ко динами­том. В отли­чие от FAT, в NTFS катало­ги явля­ются лишь вспо­мога­тель­ной струк­турой дан­ных, про­индекси­рован­ной для уско­рения отоб­ражения их содер­жимого. Вся­кая фай­ловая запись, незави­симо от сво­его про­исхожде­ния, содер­жит ссыл­ку на родитель­ский каталог, пред­став­ляющую собой номер записи в MFT. А запись кор­невого катало­га всег­да рас­полага­ется по одно­му и тому же адре­су!

Уда­лен­ные фай­ловые записи могут ссы­лать­ся на уже унич­тожен­ные катало­ги. R-Studio собира­ет их в пап­ку $$FolderXXX, где XXX — поряд­ковый номер катало­га. Поэто­му иерар­хия под­катало­гов в боль­шинс­тве слу­чаев успешно вос­ста­нав­лива­ется.

Прос­мотр вир­туаль­ного дерева обна­ружен­ных фай­лов осу­щест­вля­ется нажати­ем кноп­ки F5 или с помощью соот­ветс­тву­ющей коман­ды кон­текс­тно­го меню. Выб­рав файл (или даже целый каталог с боль­шим количес­твом вло­жен­ных под­катало­гов), наж­ми кла­вишу F2. При желании мож­но выпол­нить пред­варитель­ный прос­мотр или редак­тирова­ние (выб­рав из кон­текс­тно­го меню пункт Показать содер­жимое дис­ка). Это дос­таточ­но мощ­ный инс­тру­мент, отоб­ража­ющий содер­жимое вос­ста­нав­лива­емо­го фай­ла со все­ми его атри­бута­ми, спис­ками отрезков и т. д. в удо­бочи­таемом фор­мате. При желании мож­но вос­ста­новить все фай­лы за одну опе­рацию (Вос­ста­новить все) или выб­рать вос­ста­нов­ление по мас­ке.

Ручное восстановление жесткого диска после форматирования

На­шей целью будет руч­ное вос­ста­нов­ление все­го отформа­тиро­ван­ного раз­дела без исполь­зования допол­нитель­ных носите­лей информа­ции и дорогос­тоящих ути­лит от сто­рон­них про­изво­дите­лей. Все что для это­го пот­ребу­ется — любой редак­тор дис­ка (пред­почти­тель­нее все­го, конеч­но же, DiskExplorer от Runtime Software) в ком­бинации со встро­енной ути­литой chkdsk.

В про­цес­се фор­матиро­вания про­исхо­дит необ­ратимое раз­рушение боль­шого количес­тва клю­чевых струк­тур дан­ных, вос­ста­нав­ливать которые вруч­ную было бы слиш­ком зат­рудни­тель­но. К счастью, для извле­чения осо­бо цен­ных фай­лов это­го и не тре­бует­ся! Идея сос­тоит в том, что­бы вер­нуть раз­делу потерян­ные фай­ловые записи, а все осталь­ные вос­ста­нови­тель­ные опе­рации поручить ути­лите chkdsk.

Ди­зас­сем­бли­рова­ние показы­вает, что единс­твен­ной струк­турой дан­ных, без которой не может работать chkdsk, явля­ется атри­бут $DATA фай­ла $MFT. А раз так, все, что тре­бует­ся сде­лать, сво­дит­ся к вос­созда­нию преж­него фай­ла $MFT:$DATA и его раз­мещению поверх ста­рых фай­ловых записей. В прос­тей­шем слу­чае, если файл $MFT:$DATA не фраг­менти­рован, это дос­тига­ется так называ­емым спе­куля­тив­ным уве­личе­нием его дли­ны. Как это сде­лать?

За­пус­каем DiskExplorer, перехо­дим в начало MFT (Goto | Mft), выделя­ем файл $MFT, находим атри­бут $DATA (80h) и уве­личи­ваем поля Allocated Size, Real Size и Compressed Size на тре­буемую величи­ну, парал­лель­но с этим кор­ректи­руя спи­сок отрезков. Поле Last VCN тро­гать не нуж­но, так как оно будет исправ­лено ути­литой chkdsk. Как опре­делить дли­ну неф­рагмен­тирован­ного фай­ла MFT? Она рав­на раз­нице номеров пер­вого и пос­ледне­го сек­торов, в начале которых при­сутс­тву­ет сиг­натура FILE, умно­жен­ной на 512 бай­тов (исклю­чая сек­тора, при­над­лежащие $MFTMirr). Извес­тные мне дис­ковые редак­торы не под­держи­вают поис­ка пос­ледне­го вхож­дения, поэто­му соот­ветс­тву­ющую ути­литу при­ходит­ся писать самос­тоятель­но. К счастью, точ­ную дли­ну MFT опре­делять совер­шенно не обя­затель­но, и впол­не допус­тимо взять ее с запасом, так как лиш­нее все рав­но отсе­ет chkdsk. Дей­ствуй по прин­ципу — луч­ше переб­рать, чем недоб­рать.

Ути­лита DiskExplorer не поз­воля­ет редак­тировать поля в естес­твен­ном режиме отоб­ражения, зас­тавляя нас перек­лючать­ся в HEX-mode и искать сме­щения всех зна­чений самос­тоятель­но. Най­ти заголо­вок атри­бута $DATA очень прос­то — в его начале рас­положе­на пос­ледова­тель­ность 80 00 00 00 xx 00 00 00 01. Поле Real Size во всех вер­сиях NTFS рас­полага­ется по сме­щению 30h отно­ситель­но заголов­ка, а поля Allocated Size и Initialized Size, соот­ветс­твен­но, по сме­щени­ям 28h и 38h бай­тов, при­чем зна­чение Allocated Size дол­жно быть крат­но раз­меру клас­тера. Убе­дись, что при перефор­матиро­вании дис­ка раз­мер клас­тера не изме­нил­ся, в про­тив­ном слу­чае у вас ничего не получит­ся.

Как вос­ста­новить исходный раз­мер клас­тера? Да очень прос­то — наб­рать­ся мужес­тва и перефор­матиро­вать вос­ста­нав­лива­емый диск с клю­чом /A:x, где x — раз­мер клас­тера. А как его опре­делить? Возь­мем любой файл с извес­тным содер­жимым и про­ана­лизи­руем его спи­сок отрезков. Запус­каем кон­текс­тный поиск по все­му дис­ку, находим файл, запоми­наем (записы­ваем на бумаж­ке) его стар­товый сек­тор, пос­ле чего откры­ваем зак­реплен­ную за ним фай­ловую запись, декоди­руем спи­сок отрезков и вычис­ляем номер пер­вого клас­тера. Делим номер сек­тора на номер клас­тера и получа­ем иско­мую величи­ну.

Те­перь необ­ходимо сге­нери­ровать новый спи­сок отрезков. В общем виде он будет выг­лядеть так: 13 XX XX XX YY 00, где XX XX XX — трех­бай­товое зна­чение раз­мера $MFT в клас­терах, а YY — стар­товый клас­тер. Стар­товый клас­тер обя­затель­но дол­жен ука­зывать на пер­вый клас­тер MFT, в про­тив­ном слу­чае chkdsk не смо­жет работать. Если новый спи­сок отрезков длин­нее нынеш­него (ско­рее все­го, имен­но так и будет), то необ­ходимо скор­ректи­ровать дли­ну атри­бут­ного заголов­ка (она рас­положе­на по сме­щению 04h от его начала). Про­делав эту нехит­рую опе­рацию, запус­тим chkdsk с клю­чом /F и бла­жен­но отки­нем­ся на спин­ку крес­ла, созер­цая, как воз­рожда­ются наши милые пап­ки и фай­лы.

Единс­твен­ное, что не вос­ста­нав­лива­ется — так это дес­крип­торы безопас­ности. Всем фай­лам и пап­кам будут наз­начены пра­ва дос­тупа по умол­чанию. Во всех осталь­ных отно­шени­ях с отре­мон­тирован­ным таким обра­зом дис­ком впол­не мож­но будет работать, не опа­саясь, что он рух­нет окон­чатель­но. Фай­лы, ссы­лающиеся на несущес­тву­ющие катало­ги, скла­дыва­ются в пап­ку Found.xxx. Это — "дол­гожите­ли", пережив­шие нес­коль­ко цик­лов перефор­матиро­вания, в бук­валь­ном смыс­ле вытащен­ные из небытия.

Слож­нее вос­ста­новить том, MFT которо­го силь­но фраг­менти­рова­на. Преж­ний спи­сок отрезков при фор­матиро­вании был унич­тожен, зер­каль­ная копия так­же пос­тра­дала. Ничего дру­гого не оста­ется, как собирать все фраг­менты руками. К счастью, на прак­тике это ока­зыва­ется не так слож­но, как может показать­ся на пер­вый взгляд. В отли­чие от всех осталь­ных фай­лов дис­ка, файл $MFT име­ет замеча­тель­ную сиг­натуру FILE, при­сутс­тву­ющую в начале каж­дой фай­ловой записи. Поэто­му все, что нам тре­бует­ся сде­лать, сво­дит­ся к сле­дующим опе­раци­ям. Пос­ледова­тель­но ска­нируя раз­дел от пер­вого клас­тера до пос­ледне­го, выпиши­те начало и конец каж­дого из фраг­ментов, при­над­лежащих MFT. Затем из этой цепоч­ки необ­ходимо исклю­чить файл $MFTMirr. Его лег­ко узнать, так как он рас­положен в середи­не раз­дела и содер­жит копии фай­ловых записей $MFT, $MFTMirr, $LogFile и $Volume, при­чем $MFTMirr ссы­лает­ся на себя. В рас­смат­рива­емом при­мере наш спи­сок выг­лядит так: 08h — 333h, 669h — 966h, 1013 — 3210h. В гру­бом приб­лижении ему будет соот­ветс­тво­вать сле­дующий спи­сок отрезков: 2 2B 03 08 22 23 03 69 96 22 FD 21 13 10 00.

"В гру­бом приб­лижении" ска­зано потому, что мы не зна­ем, в какой пос­ледова­тель­нос­ти рас­полага­лись эти отрезки в фай­ле (порядок рас­положе­ния фраг­ментов на дис­ке далеко не всег­да сов­пада­ет с поряд­ком отрезков в спис­ке отрезков). Что про­изой­дет, если порядок сбор­ки фай­ла $MFT ока­жет­ся нарушен? Внут­ри MFT все фай­ловые записи ссы­лают­ся друг на дру­га по сво­им поряд­ковым номерам, пред­став­ляющим собой индексы мас­сива. Эти ссыл­ки необ­ходимы для вос­ста­нов­ления струк­туры катало­гов, орга­низа­ции жес­тких ссы­лок (hard links) и еще некото­рых слу­жеб­ных струк­тур. Ссыл­ки на родитель­ский каталог дуб­лиру­ются в индексах и вос­ста­нав­лива­ются эле­мен­тарно. Жес­ткие ссыл­ки теря­ются без­воз­врат­но (единс­твен­ный спо­соб вос­ста­новить их зак­люча­ется в пов­торении попыт­ки сбор­ки фай­ла $MFT в дру­гом поряд­ке). Одна­ко они прак­тичес­ки ниг­де и никак не исполь­зуют­ся, так что их потеря не столь уж сущес­твен­на. По‑нас­тояще­му туго при­ходит­ся силь­но фраг­менти­рован­ным фай­лам, занима­ющим нес­коль­ко фай­ловых записей, рас­кидан­ных по раз­ным фраг­ментам $MFT. Здесь выруча­ет толь­ко перес­танов­ка фраг­ментов. К счастью, количес­тво ком­бинаций обыч­но быва­ет невели­ко, и про­цеду­ра вос­ста­нов­ления занима­ет сов­сем нем­ного вре­мени. Хорошая новость — начиная с NTFS вер­сии 3.1, в MFT номера фай­ловых записей хра­нят­ся в явном виде (четырех­бай­товое поле, рас­положен­ное по сме­щению 2Ch от начала фай­ловой записи), что дела­ет задачу вос­ста­нов­ления три­виаль­ной.