Восстановление файла без $MFT
 

Добрый день!
В одном из регионов нашей необъятной случилась ситуация при которой:
1. сервер с бекапами не выполнял свою функцию;
2. RAID-контроллер (9361-8i) подвергся воздействию "квалифицированных" специалистов (навтыкали вместо участников массива дисков из других массивов - по логам контроллера видно, что запускалась переиниализация);
3. тип RAID и состав дисков не известен, ФС развалена.
Осталось админов сжечь, тогда можно сказать, что вообще ничего не существовало.

Я не специалист по восстановлению данных, вывезти диски за пределы серверной не представляется возможным (не спрашивайте почему), поэтому копаем HEX в Read-only. Все попытки совместить диски, найти разделы, $MFT, файлы оказались безуспешны.
В ходе раскопок был выявлен начальный сектор mdf-файла (MS SQL база), из которого удалось извлечь примерно 70% информации. Как я понимаю, остальная конфигурация находится в других секторах, список которых хранится в $MFT.
Есть надежда, что $MFT был убит не полностью и мы сможем прочитать информацию по данному файлу. Но поиски пока ни к чему не привели.
Я понимаю, что это нетривиальная задача, но возможно кто-то сможет подсказать направление раскопок. Возможно, имеются иные признаки или ссылки между блоками секторов одного файла?

Не уверен, но есть высокая вероятность расположения файла на одном физическом носителе.

DruOleg,
Диски можно и не выносить, а вынести их посекторные образы.
Секретные и прочие конфедициальные данные DR фирмы могут делать под вашим контролем.
Прошли какой-то этап, забрали все диски, на следующий день снова принесли, чтобы продолжить.
Диски под копии и задачу, тоже предоствляете свои, сеть требуете отключить.

удобно разбираться в PC3000 DE Raid Edition.
Не видя дисков мало чем поможешь.
В целом делается черновой поиск по каждому участнику, поиск структур FS и сигнатур файлов, по их чередованию и целостности файлов выясняется структура массива. Размер страйпа, порядок чередование дисков и контрольных блоков. Собирается массив, и уже в нем идет анализ файловой структуры.
Другими программами не пользуюсь. Особо не подскажу.

Tomset, спасибо за ответ.
Тут никакие доводы не действуют, увы.
Судя по всему $MFT таблица потеряна окончательно. Нашел только пару записей FILE0, и те созданы при попытке восстановления загрузчика.

DruOleg,
По всем дискам нужно искать.
Вот так подобные задачи решаются в DE рейд эдишен:
http://blog.acelab.ru/opredeleniye-k...ii-raid-1.html
http://blog.acelab.ru/opredelenie-ko...ix-fajlov.html

Во всяких других сборщиках рейдов подобного даже близко нет.
Сидеть записывать адреса структур сбесишься.
Раз хотят сами, просите купить для вас комплекс. за полгодика разберетесь.
А потом продадите.

Вот пусть начальство и думает, порядка 200000р за комплекс и где-то год обучение.
Или на фирму сходить от 20 до 70 тысяч в зависимости от количества дисков и объема массива
И неделя работы опытного специалиста.

Опытным путем посмотрел на тестовом стенде хранение данных в $MFT на примере БД в 10 ГБ. Она состоит из двух кластеров, в начале каждого находится запись "INDX(" (49 4E 44 58 28 00).
Копаю в этом направлении. Надеюсь, верном.

Tomset,
спасибо за матчасть! Буду изучать.

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

Сжигать нужно того, кто не обеспечил бекапы. А в случае БД и того, кто не обеспечил реплики. Это азы же. Да, это требует дополнительных ресурсов, но зато спасает от неквалифицированных стрелочников.

От таких ни чего не спасает, они и бекап грохнут. )
Сотни тысяч людей обращаются в DR конторы имея и не один бекап.
Сложность в том, что постоянно работающие базы и задачи, в которых нет собственно механизма резервирования, не возможно на ходу резервировать, когда файлы не синхронно изменяются. А останавливать работу можно только по выходным или ночами. При восстановлении из бекапа теряется самая актуальная последняя информация.
За день могут вносится тысячи изменений сотнями пользователей.
Рейд только непрерывность процесса обеспечивает, но его надежность ниже чем у одного диска.
Это даже по формулам видно.

Всем спасибо за конструктивные советы.
Данные восстановить не удалось. Но удалось выяснить, что перед поломкой RAID отработал DiscCrypt (злоумышленникам привет).
Очень качественный провал.

У MS SQL есть механизмы репликации. Как и у любого enterprise-ready RDBMS движка. Но для этого нужен как минимум ещё один сервер, на котором собственно и должна крутиться реплика. Суть как раз в том, что на реплике всегда актуальная инфа, при падении мастера можно просто переключиться на реплику, в идеальном случае это происходит автоматически. Для минимизации последствий атаки на сам SQL часто используют реплики с задержкой, когда транзакции вносятся с задержкой скажем в два часа - иногда лучше потерять транзакции за последние пару часов, чем все.

Ну так о чем и пишу, не сервер, железо или программа бекапа репликацией занимается, а сама база.
Но порядок стоимости такого sql, гораздо выше, чем облегченный или бесплатный SQL, который чаще всего используют разработчики всяких баз.

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