Восстанавливаем виртуальные машины с ошибочно инициализированного Datastore. История одной глупости с хэппи-эндом

    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 раздел:

    image

    В режиме 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 гипервизора грохнутые файлы дисков были подключены к свеже-созданной виртуальной машине. Диски подхватились. Потери данных замечено не было.

    Share post

    Similar posts

    Comments 8

      0
      Зависать то перестал?
        0
        Неа. После запуска машина повисла через 15 минут. После чего виртуалка была перенесена в ту самую времянку, которую раскатал для просмотра мастера.
        На новом месте пока полет нормальный.
        Но это еще ничего ни о чем не говорит.
        0
        а причину зависаний-то, нашли чи нет?
          0
          Выше уже ответил, что нет. Пока просто наблюдаю.
          0
          По зависанию. Может поможет. На практике были такие же проблемы и были связаны:
          — При миграции на новую версию ESXI, обязательно надо сделать Upgrade Hardware и обновить vmware tools, такие же непонятные зависания были вплоть до розового экрана.
          — Как вариант, были проблемы с почтовыми серверами и файлопомойками. Тоже долго искали в чем косяк и помогло… Переход от сетевки E1000 на VMXNET3, сразу глюки прекратились. И в целом посмотрите на сетевые настройки гостевой ОС, именно здесь никто не ищет, но проблема там, проведите необходимый тюнинг.
            0
            — При миграции на новую версию ESXI, обязательно надо сделать Upgrade Hardware и обновить vmware tools, такие же непонятные зависания были вплоть до розового экрана.

            Миграции не было. Была чистая установка ESXi, создавалась с нуля машина и в нее ставилась чистая винда.
            Переход от сетевки E1000 на VMXNET3, сразу глюки прекратились.

            Спасибо! Попробую.
            0
            Всем привет.

            Т.е. ТС вместо НАТИВНОЙ для Vmware VMXNET3, к-ая РЕКОМЕНДУЕТСЯ самой Vmware пользовал все это время E1000?
            Сказать, что это печально — это не сказать ничего (

            Ув ТС.
            Крайне рекомендую пользовать для NAS открытые и ГОТОВЫЕ решения.
            Это FreeNAS, XigmaNAS (ex-NAS4Free — в гугле по фразе «2гуся нас4фри» ), OpenMediaVault.
            Умеют жить на флешках.
            Первые два умеют ZFS «из-коробки», для 3-го поддержка ZFS реализована с пом. плагина.
            О том, ПОЧЕМУ ZFS вы можете поискать в Сети.

            Зы. VmWare — одна из самых титулованных компаний в сфере вирт-ции. Но ее подход к железу «не для нищебродов» (HCL Vmware ESXI в гугле) оттолкнул многих.
            И по этому — KVM.
            ИМХО. Для небольших инсталляций — Proxmox VE (https://forum.netgate.com/topic/120102/proxmox-ceph-zfs-pfsense/), для остального — таже Opennebula (в телеге есть хороший рус. яз. чат-канал)

            З.ы. ZFS обновилась на днях до вер. 0.8 Оч. и оч. много «вкусного» )
              0
              Но ее подход к железу «не для нищебродов» (HCL Vmware ESXI в гугле) оттолкнул многих.

              Отчасти. Я с серверами sun столкнулся с бедой, что не мог когда-то версию vmware выше определённой ставить. не поддерживалось. Что характерно, hyper-v 2012 отлично налез. К слову, потом я даже 2016 версию натянул — работает до сих пор.
              Отчасти — это потому что я столкнулся с неприятностью в виде того, что vmware нормально у меня, в своё время, не стартанул на одном из новейших делловских паверэджей. Просто о таком железе ещё не знал. Тоже было грустно. Всё время с vmware у меня не складывается.
              А титулованность давно уже штука неоднозначаная.

            Only users with full accounts can post comments. Log in, please.