Восстановление Виртуальных Машин Из Ошибочно Инициализированного Хранилища Данных. История Одной Глупости Со Счастливым Концом

Отказ от ответственности: Заметка носит развлекательный характер.
Удельная плотность полезной информации в нем невысока.
Это было написано «для себя».

Лирическое вступление
Дамп файлов в нашей организации выполняется на виртуальной машине VMware ESXi 6 под управлением Windows Server 2016. И это не просто дамп мусора.
Это сервер обмена файлами между структурными подразделениями: там и совместная работа, и проектная документация, и папки со сканеров сети.
В общем, вся производственная жизнь здесь.
И этот контейнер всей производственной жизни стал зависать.
Более того, гость мог спокойно повеситься, не затрагивая остальных.
Он мог вывести из строя весь хост и, соответственно, все остальные гостевые машины.
Я мог бы повеситься и повесить клиентские сервисы vSphere: то есть процессы остальных гостей живы, машины работают нормально и отвечают, но файловой мойки нет и vSphere Client не цепляется за хост. В общем, ни одну систему определить не удалось.
Подвисания могли возникать в течение дня при низкой нагрузке.
Могли это делать ночью, во время холостого хода.
Может ночью при дифференциальном резервном копировании и средней нагрузке.
Мог по выходным при полном резервном копировании и высокой нагрузке.
И произошла явная деградация ситуации.
Сначала это было раз в год, потом раз в полгода.
На исходе моего терпения - два раза в неделю.
У меня была проблема с памятью.
Но мне не дали даже в выходные остановить помойку и запустить Memtest. Мы ждали майских праздников.
На майских праздниках прогнал Memtest и.
ошибок не обнаружено.
Я был поражен и решил поехать в отпуск.
Пока я был в отпуске, на помойке не было ни одного зависания.
И когда я вернулся на работу в первый день в понедельник, там была куча мусора.
Перенес полный бэкап и завис сразу после его завершения.
Столь теплый прием из отпуска подтолкнул меня к решению физически перетащить диски с гостевой машины на другой хост. И, хотя давно известно, что в первый день после отпуска нельзя делать ничего серьезного, хотя я всю дорогу до работы готовилась не работать, возмущение очередным заморозком сбило и настроение, и мою клятвы вылетели из головы.
Физические диски были перенесены на другой хост. Горячее соединение.
В настройках хранилища на вкладке Диски диски появляются.
На вкладке Хранилища данных На этих дисках нет места для хранения данных.
Обновить - не появляйся.
Ну, конечно, первый порыв - Добавить хранилище .
Мастер добавления объясняет, что он поддерживает. Конечно, он также поддерживает VMFS. Я не сомневался в этом.
Краткий обзор сообщений мастера на каждом этапе: Далее, Далее, Далее, Готово.
Глаз даже не приблизился к тому, чтобы уловить маленький желтый кружок с восклицательным знаком внизу окна одной из хозяйских ступенек.
По завершении работы мастера в списке появился свежий датастор.
а вместе с ним и датасторы с оставшихся физических дисков.
Я перехожу к навигации по недавно добавленному хранилищу данных, а оно.
пусто.
Конечно, я снова впал в изумление.
Сейчас 8 утра, первые 15 минут на работе после отпуска, я еще даже сахар в кофе не размешала.
И вот оно.
Первая мысль была, что я выдернул не тот диск с «родного» хоста.
Я посмотрел, присутствует ли нужный Datastore на «родном» хосте: нет, его не было.
Вторая мысль была: «Бля!» Не уверен, но мне кажется, что третья, четвёртая и как минимум пятая мысль были одинаковыми.
Чтобы развеять сомнения, я быстро установил для тестирования свежий ESXi, взял левый диск и, уже прочитав его, прошёлся по шагам мастера.
Да.
При добавлении хранилища данных с помощью мастера все данные на диске теряются без возможности отката операции и восстановления данных.
Позже прочитал на одном из форумов оценку этой конструкции мастера: хрень хреновая.
И я действительно согласился.
Начиная с шестого мысли потекли в более конструктивном направлении.
ХОРОШО.
Инициализация занимает считанные секунды даже для диска объемом 3Тб.
Итак, это форматирование высокого уровня.
Это означает, что таблица разделов была просто переписана.
Так что данные все еще есть.
Итак, теперь будем искать какой-нибудь неформат и вуаля.
Загружаю машину с загрузочного образа Стрелец.
И обнаруживаю, что программы восстановления разделов знают все, кроме VMFS. Например, они знают структуру разделов Synology, но не VMFS. Поиск по программам не обнадеживает: в лучшем случае GetDataBack и R.Saver находят NTFS-разделы с живой структурой каталогов и живыми именами файлов.
Но меня это не устраивает. Мне нужны два файла vmdk: с системным диском и диск с мусорными файлами.
И тут я понимаю, что похоже сейчас буду устанавливать винду и выкатывать из файлового бэкапа.
И при этом помню, что у меня там был рут DFS. А еще совершенно дикая по своим возможностям и разветвлениям система прав доступа к папкам отделов.
Не вариант. Единственный приемлемый по времени вариант — восстановить состояние системы и диска с данными и всеми правами.
Опять гугл, форумы, КБ'шки и снова плач Ярославны: VMware ESXi не предоставляет механизма восстановления данных.
Все обсуждения имеют два финала: кого-то восстановили с помощью дорогостоящей программы DiskInternals VMFS Recovery, либо кому-то помог специалист по программному обеспечению, активно продвигающий свои услуги.
vmfs-инструменты И дд .
Возможность приобретения лицензии DiskInternals VMFS Recovery за 700 долларов США невозможна.
Давать доступ к корпоративным данным постороннему человеку с «территории потенциального противника» — тоже не выход. Но погуглилось, что разделы VMFS можно читать и через UFS Explorer.

Восстановление DiskInternals VMFS
Пробная версия была скачана и установлена.
Программа успешно увидела пустой раздел VMFS:

В режиме Восстановить (быстрое сканирование) Еще я нашел потрепанный Datastore с папками виртуальных машин с дисками внутри:

Предварительный просмотр показал, что файлы живые:

Монтирование раздела в систему прошло успешно, но по неизвестной причине во всех трех папках находилась одна и та же виртуальная машина.
Конечно, по закону подлость – это не то, что требуется.
Три линии стыда Попытка бесстыдно заблокировать ПО закончилась неудачей.
Но UFS Explorer завис.

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

Я находился в катастрофическом положении и нисколько не гордился теми мерами, к которым прибегнул.

УФС Эксплорер
Сканирование диска показало наличие 7 узлов.
Количество узлов «на удивление» совпало с количеством файлов *-flat.vmdk, обнаруженных VMFS Recovery:

Сравнение размеров файлов и размеров узлов также показало совпадение вплоть до байта.
При этом были восстановлены имена файлов *-flat.vmdk и, соответственно, их принадлежность виртуальным машинам.

В общем, диски vmdk с точки зрения ESXi состоят из двух файлов: файла данных ( -flat.vmdk) и «физический» файл разметки диска ( .
вмдк).
Если вы загрузите файл *-flat.vmdk в хранилище данных с локального компьютера, ESXi не распознает его как действительный файл на диске.
В базе знаний VMware есть статья о том, как вручную создать файл дескриптора диска: kb.vmware.com/s/article/1002511 , но мне этого делать не пришлось, я просто скопировал содержимое соответствующих файлов из области предварительного просмотра содержимого файлов в DiskInternals VMFS Recovery:

После 4 часов выгрузки узла объемом 2,5 ТБ из UFS Explorer и 20 часов загрузки в Datastore гипервизора файлы сбойного диска были подключены к вновь созданной виртуальной машине.
Диски подобрались.
Потери данных не наблюдалось.