Disclaimer: Заметка носит развлекательный характер. Удельная плотность полезной информации в ней мала. Была написана «для себя».
Лирическое вступление
Файловая помойка в нашей организации крутится на виртуальной машине VMware ESXi 6 под Windows Server 2016. И это не просто помойка. Это сервер файлового обмена между структурными подразделениями: тут и совместная работа, и проектная документация, и папки с сетевых сканеров. В общем, тут вся производственная жизнь.
И вот это вместилище всей производственной жизни стало виснуть. Причем гость мог тихо повиснуть сам, не затрагивая остальных. Мог повесить вслед за собой весь хост и, соответственно, все остальные гостевые машины. Мог повиснуть сам и повесить клиентские службы vSphere: то есть процессы остальных гостей живы, машины исправно работают и отвечают, а вот файлопомойка нет и vSphere Client к хосту не цепляется. В общем, никакой системы выявить не удавалось. Зависания могли произойти днем во время слабой загрузки. Могли ночью во время нулевой нагрузки. Могли ночью во время дифференциального резервного копирования и средней загрузки. Могли в выходные во время полного резервного копирования и высокой нагрузки. И наблюдалась явная деградация ситуации. Сначала это было раз в год, потом раз в полгода. Под конец моего терпения — дважды в неделю.
Я грешил на оперативную память. Но остановить помойку даже в выходные и прогнать Memtest мне не давали. Ждали майских праздников. В майские праздники я прогнал Memtest и… ошибок найдено не было.
Я впал в изумление и решил сходить в отпуск. Пока я был в отпуске — у помойки не было ни одного зависания. А когда в понедельник вышел первый день на работу — помойка висела. Вытерпела полное резервное копирование и аккурат по его окончании повисла. Такая теплая встреча из отпуска подтолкнула меня к решению физически перетащить диски с гостевой машиной в другой хост.
И, хотя давно известно, что в первый день после отпуска нельзя делать ничего серьезного, хотя я всю дорогу на работу настраивал себя не работать, мое возмущение очередным зависанием выбило из головы и настрой, и зароки…
Физические диски были переставлены в другой хост. Подключение на горячую. В настройках хранилищ на вкладке Drives появляются диски. На вкладке Datastores хранилища на этих дисках — нет. Refresh — не появляются. Ну и, разумеется, первый порыв — Add Storage. Мастер добавления рассказывает, что он поддерживает. Конечно поддерживает и VMFS. Я и не сомневался. Беглый просмотр сообщений мастера на каждом шаге: Next, Next, Next, Finish. Взгляд даже близко не зацепился за маленький желтый кружок с восклицательным знаком внизу окна одного из шагов мастера.
По окончании мастера свежий Datastore появился в списке… а вместе с ним и Datastores с остальных физических дисков.
Перехожу к навигации по только что добавленному Datastore, а он… пуст. Разумеется, я вновь впал в изумление. 8 утра на часах, первые 15 минут на работе после отпуска, даже сахар в кофе еще не размешал. И тут такое. Первая мысль была — не тот диск из «родного» хоста вытянул. Посмотрел, присутствует ли искомый Datastore в «родном» хосте: нет, не присутствует. Вторая мысль была: «бля#ь!». Не уверен, но мне кажется, что третья, четвертая и как минимум пятая мысль была такая же.
Чтобы развеять сомнения, по-быстрому установил на пробу свежий ESXi, взял левый диск и, уже вчитываясь, прошелся по шагам мастера. Да. При добавлении Datastore с помощью мастера происходит потеря всех данных на диске без возможности отката операции и восстановления данных. Позже я прочитал на одном из форумов оценку такого дизайна мастера: shitsome crap. И прямо вот очень согласился.
Начиная с шестой — мысли потекли в более конструктивном русле. Ладно. Инициализация занимает считанные секунды даже для 3Tb-диска. Значит, это высокоуровневое форматирование. Значит, просто была переписана таблица разделов. Значит, данные все еще там. Значит, сейчас поищем какой-нибудь unformat и voila.
Гружу машину с загрузочного образа Strelec… И выясняю, что программы восстановления разделов знают все, кроме VMFS. Разметку разделов Synology, например, знают, а вот VMFS — нет.
Перебор программ не утешителен: в лучшем случае GetDataBack и R.Saver находят NTFS-разделы с живой структурой каталогов и живыми именами файлов. Но меня это не устраивает. Мне нужны два vmdk-файла: с диском системы и диском файлов помойки.
И тут я понимаю, что, похоже, сейчас буду ставить винду и раскатываться из файлового бэкапа. И одновременно с этим вспоминаю, что у меня там был корень DFS. А еще совершенно дикая по объему и разветвленности система прав доступа к папкам подразделений. Не вариант. Единственный приемлемый по времени вариант — восстановление состояния системы и диска с данными и всеми правами.
Снова гуглинг, форумы, KB'шки и снова плач Ярославны: VMware ESXi не предусматривает механизма восстановления данных. Все ветки обсуждений имеют два финала: кто-то восстановился с помощью не дешевой DiskInternals VMFS Recovery или кому-то помог активно продвигающий свои услуги специалист по vmfs-tools и dd. Вариант с покупкой лицензии DiskInternals VMFS Recovery за $700 — не вариант. Допуск постороннего лица с «территории потенциального противника» к корпоративным данным — тоже не вариант. Зато было нагуглено, что VMFS разделы умеет читать так же еще UFS Explorer.
DiskInternals VMFS Recovery
Была скачана и установлена триальная версия. Программа успешно увидела пустой VMFS раздел:
В режиме Undelete (Fast Scan) так же нашла и потертый Datastore c папками виртуальных машин с дисками внутри:
Предпросмотр показал, что файлы живые:
Монтирование раздела в систему было успешным, но по непонятной причине во всех трех папках была одна и та же виртуалка. Конечно, по закону подлости — не та, что требуется.
Три строчки стыда
Предпринятая попытка бессовестно запиратить софтину закончилась провалом. Зато запиратился UFS Explorer.
Я находился в катастрофическом положении и вовсе не гордился теми мерами, к которым прибег.
Я крайне отрицательно отношусь к воровству ПО. Ни в коем случае не призываю к использованию средств обхода защиты от нелицензированного использования.
Я находился в катастрофическом положении и вовсе не гордился теми мерами, к которым прибег.
UFS Explorer
Сканирование диска показало наличие 7 нод. Количество нод «удивительным образом» совпало с количеством *-flat.vmdk файлов, обнаруженных VMFS Recovery:
Сравнение размеров файлов и размеров нод показало так же совпадение до байта. Заодно были восстановлены имена *-flat.vmdk файлов и, соответственно, принадлежность их к виртуальным машинам.
Вообще, vmdk-диски с точки зрения ESXi состоят из двух файлов: это файл с данными (<имя машины>-flat.vmdk) и файл «физической» разметки диска (<имя машины>.vmdk). Если с локальной машины в Datastore залить *-flat.vmdk файл, то ESXi его не распознает как валидный файл диска. В базе знаний VMware есть статья о том, как вручную создать файл дескриптора диска: kb.vmware.com/s/article/1002511, но мне делать этого не пришлось, я просто скопипастил содержимое соответствующих файлов из области предпросмотра содержимого файла в DiskInternals VMFS Recovery:
Спустя 4 часа выгрузки 2,5Тб нода из UFS Explorer'a и 20 часов загрузки в Datastore гипервизора грохнутые файлы дисков были подключены к свеже-созданной виртуальной машине. Диски подхватились. Потери данных замечено не было.
