Восстановление данных в России и СНГ
Малая Пироговская, 18, офис 406
Пн-Пт 9:00 - 21:00, Сб-Вс 9:00 - 17:00
Круглосуточный телефон

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

Задача Частичное обнуление странной конструкции raid1 + raid1 + raid1 + raid1 + VMFS + Windows LDM
Оборудование

Виртуальные машины VMware

RAID контроллер Adaptec
Жесткие диски Восемь дисков Western Digital:
6 * 3Tb (WD3000FYYZ-01UL1B2 и WD3000FYYZ-01UL1B1)
2 * 2Tb ( WD20EFRX-68EUZN0 и WD20EURS-63S48Y0)
Режим работ Стандартный
Проблема заказчика

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

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

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

Был 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 Тб).

Закажите восстановление данных