Нестандартная система хранения данных в виртуальных машинах

Комментарий заказчика:

Наш сисадмин работает вне штата. Он некомпетентен! Конфигурацию не знаю — я не админ. Знаю, что все диски у нас дублировались, чтобы предотвратить потерю данных. Системный администратор говорит, что два диска перестали работать и какие-то нули показывают. Вроде как данные есть, но они все открываются нулевыми значениями. Вроде бы вылетели два диска и теперь ничего не включается и не работает. Вылетели два диска, которые были отдельно. Один диск вылетел две недели назад, система работала без одного диска. Потом из этого же массива выпал второй диск.

Описание проблемы системным администратором:

Был RAID1— зеркало. Один из дисков начал шалить: то видно его, то нет. Его вынули из зеркала и стали работать в degrade-режиме, данные были доступны. Новый диск покупать отказались, чтобы сэкономить. Так продолжалось примерно две недели.

После этого ушел в offline второй диск из этого зеркала. Вместо того чтобы поставить туда новый, решили опять сэкономить — взяли первый диск, с помощью diskpart удалили разделы, отформатировали Акронисом, обнулили, проверили smart — диск живой и чистый.

Дальше вставили диск на сервер, зашли в меню биос raid-контроллера, он подхватывает этот диск как новый диск массива и начинает процесс ребулда (rebuild). Диск «ребулднулся» часов за 8 (на ночь оставляли) и стал в статусе оптимал (optimal), собрался, но после этого все перестало работать.

Результаты самодиагностики:

Структура файлов видна, но файлы не читаются — ошибка чтения. Начали разбираться — открыли hex-редактором файлы и увидели, что все файлы внутри — нули (сигнатура 0x00). На дисках находятся виртуальные машины VMware. ESXi грузится нормально, все датасторы (datastore) определяет хорошо, но машины не грузятся.

Реконструкция процесса потери данных

• Первичная проблема возникла на 0-м уровне абстракции — начал сбоить диск.
• Во время ребилда что-то пошло не так на 1-м уровне абстракции и вместо синхронизации актуальных данных прошел обратный процесс — данные с чистого диска были записаны на диск с данными. Что необычно: перезаписан 0x00 не весь диск, а примерно 80 %. Неповрежденным остался участок 20–40 % диска. Начало и конец — полностью перезаписаны 0x00 на обоих дисках.
• VMFS (уровень абстракции — 2) остались в полной сохранности файловые структуры и часть данных. Из-за этого виртуальные машины видны, но почти на 90 % содержат 0x00 вместо данных.
• Часть данных в виртуальных машинах и на NTFS (3-й и 4-й уровни) полностью уничтожена, но большая часть подлежит восстановлению, несмотря на частичную потерю файловых структур и повреждения на всех уровнях.

Реализована нестандартная система хранения данных.

• Нулевой уровень абстракции — диски, 8 штук + raid-контроллер, 1 штука.
• Первый уровень абстракции — на raid-контроллере собраны 4 raid1: 3tb + 3tb + 3tb + 2tb.
• Второй уровень абстракции — на каждом raid1 созданы vmware Datastore и файловая система VMFS.
• Третий уровень абстракции — на VMFS созданы виртуальные диски VMDK. На datastore размером 2 Tb созданы виртуальные машины Windows Server.
• Четвертый уровень абстракции — к виртуальной машине Windows Server подключены все виртуальные диски. Из этих дисков средствами Windows Logical Disk Manager собран один раздел на 10 Tb, который отформатирован в NTFS. На нем и лежат данные.

Больше всего интересовала база Microsoft SQL 1с, которая лежала на системном диске виртуальной машины. Она не подлежала восстановлению, потому что попала в перезаписанную область. К счастью, в области данных иногда вручную делались резервные копии этой базы — они были успешно восстановлены, как и второстепенные данные (графические файлы на 9 Тб).