Восстановление базы MS SQL Server после вируса-шифровальщика (ransomware)

В прошлом посте я публиковал информацию о восстановлении данных из поврежденного файла базы MS SQL, в котором оказались пропущенные блоки из-за интервального шифрования бэкапа. Как выяснилось в комментариях и вопросах в Telegram, не все DBA, системные администраторы и другие специалисты верно поняли кратко описанный мною метод восстановления поврежденных баз данных с использованием файлов БД и резервных копий, имеющих повреждения.

Полагаю, будет не лишним рассказать о методике восстановления баз данных в условиях лаборатории восстановления данных, в которой специалисты вовлечены в R&D-разработку программного обеспечения для этой сферы. Основной принцип: работа только с копиями. Результирующий файл восстанавливаемой БД - это исключительно новый объект, в который вносятся данные из нескольких файлов с контролем как физической целостности базы, так и логической целостности объектов.

Резервные копии баз MS SQL Server бывают двух видов:

1. Несжатые, где первые 4 байта — сигнатура «TAPE» (0x54, 0x41, 0x50, 0x45), и после небольшого заголовка идут последовательно страницы базы данных, а в конце располагаются завершающие служебные данные контейнера.

2. Сжатые, где первые 8 байт — сигнатура «MSSQLBAK» (0x4D, 0x53, 0x53, 0x51, 0x4C, 0x42, 0x41, 0x4B), и после служебного заголовка следует первый сжатый фрейм с данными контейнера несжатого бэкапа, снова служебные данные сжатого контейнера, а за ними поток сжатых фреймов, содержащих в себе экстенты базы данных.

Для работы с поврежденными базами постоянно пишется и совершенствуется наш лабораторный инструмент HDD Masters DB & Backup Tool for MS-SQL, в котором реализовано множество инструментов для восстановления физической целостности баз данных SQL.В задаче, где файлы бэкапов частично зашифрованы от начала, а по телу признаки шифрования выявлены с определенным интервалом, есть путь решения.

Стандартные средства восстановления такие бэкапы не анализируют, а сразу отвергают. Множество коммерческих утилит при отсутствии начала также отказываются сканировать сжатое пространство.

Рис. 1 Попытка восстановления из частично шифрованного бэкапа средствами SSMS.

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

Рис. 2. Анализ частично зашифрованного сжатого файла резервной копии

Анализ на приведенном примере показывает, что из поврежденного бэкапа добыто более 90% страниц. Мы исходим из соотношения неопределенных зон и зон с подтвержденными корректными экстентами. С несжатыми бэкапами работа проще, так как там достаточно только валидации сохраненных внутри контейнера страниц базы данных.

После такой реконструкции мы получим файл базы из поврежденной копии, где пропущено множество страниц. Сама по себе эта копия неработоспособна и не может быть обработана средствами MS SQL Server, так как отсутствуют ключевые страницы в самом начале. Однако такая извлеченная база является отличным донором для восстановления поврежденной базы, особенно если расхождения между ними невелики.

Большинство страниц объектов будут на одних и тех же позициях. Например, в случае SQL-баз с 1С, по нашим наблюдениям за большими базами, речь идет о сходстве баз более чем на 99% страниц. Большинство объектов растет инкрементально, то есть происходит только добавление новых записей, а не полное изменение всех существующих.Имея на руках копию БД, извлеченную из виртуального диска, который, в свою очередь, извлечен из поврежденного Veeam Backup (где есть некоторые пропуски), и имея бэкапы самой базы в виде частично зашифрованных данных за несколько дней до и несколько дней после инцидента, мы получаем материал, из исследования которого можно собрать работоспособную БД.

Рис. 3 Окно реконструкции БД с оценкой статичности страниц.

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

Рис. 4 Замена поврежденных статичных страниц версиями из резервных копий.

Далее нужно переходить к анализу логической целостности базы данных. Необходимо анализировать записи служебных таблиц, таких как sysallocunits, sysschobjs, sysrowsets и др., и исследовать цепочки страниц объектов по различным видам карт: next_page, r_page (индексы), IAM_page. Тройной механизм построения карт обычно позволяет собрать полные карты объектов и получить представление о полном размере объекта (здесь очень хорошую помощь оказывают IAM-страницы).

Получив полные карты объектов, можно понимать, какие объекты пусты, какие содержат данные, какие повреждены и сколько реально страниц потеряно. Контроль целостности на физическом уровне не дает полной картины, так как до разбора системных таблиц неизвестно, сколько страниц используется в БД, а сколько свободно.

Рис. 5. Карта системного объект sysschobjs БД MS-SQL

Проблемы логического восстановления обычно кроются в том, что некоторые страницы перемещены в другие места (например, из смешанных экстентов). Тогда предстоит анализировать положение объектов по разным цепочкам и сверять не только положение страницы, контрольную сумму и номер объекта, но и содержимое страниц. Это нужно, чтобы распознать одинаковые фрагменты объектов, перенесенные в разные места, и выполнить копирование недостающих страниц с контролем статичности данных и правкой заголовков в цепочках next/previous pages с пересчетом контрольной суммы.

Также в некоторых ситуациях возникают проблемы, когда в каком-либо объекте обнаруживается нехватка данных для полной реконструкции. Тогда в ход идут методы частичного спасения БД. Один из них - установка страниц-заглушек с пустыми слотами и правильным номером объекта, со связями в механизме next page, чтобы дальнейшие процедуры проверки базы не разрывали объекты и не отсекали все данные после первой ошибки в цепочке.

Кроме этого, дорабатывается метод разбора всех уцелевших страниц на слоты с данными с учетом полей и создание файла для инъекции данных объекта в новую БД (пока этот инструмент находится в стадии альфа-тестирования).

Описанные методики восстановления баз данных не являются исчерпывающими, но существенно увеличивают шансы получения данных из поврежденных БД MS-SQL.