Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Опровержение: Бележката е с развлекателна цел. Специфичната плътност на полезна информация в него е ниска. Беше написано „за себе си“.

Лирично въведение

Файловият дъмп в нашата организация работи на виртуална машина VMware ESXi 6, работеща под Windows Server 2016. И това не е просто боклук. Това е сървър за обмен на файлове между структурни подразделения: има сътрудничество, проектна документация и папки от мрежови скенери. Като цяло целият производствен живот е тук.

И този контейнер от целия производствен живот започна да виси. Освен това гостът може тихо да се обеси, без да засегне останалите. Можеше да свали целия хост и съответно всички останали машини за гости. Мога да се обеся и да окача клиентските услуги на vSphere: тоест процесите на другите гости са живи, машините работят правилно и отговарят, но няма устройство за измиване на файлове и клиентът на vSphere не се придържа към хоста. Като цяло не може да се идентифицира система. Замръзване може да се случи през деня при ниско натоварване. Можеха да го правят през нощта, когато нямаше натоварване. Може през нощта по време на диференциално архивиране и средно натоварване. Може през уикендите по време на пълно архивиране и голямо натоварване. И имаше явно влошаване на ситуацията. Отначало беше веднъж годишно, а след това веднъж на шест месеца. В края на търпението ми - два пъти седмично.
Имах проблем с паметта. Но не ми позволиха да спра купчината боклук дори през уикендите и да стартирам Memtest. Чакахме майските празници. През майските празници пуснах Memtest и... не се откриха грешки.

Бях изумен и реших да отида на почивка. Докато бях на почивка, нямаше нито едно прекъсване на сметището. И когато се върнах на работа за първия ден в понеделник, имаше купчина боклук. Издържах пълно архивиране и увиснах веднага след като приключи. Такова топло посрещане от ваканцията ме тласна към решението физически да преместя дисковете с машината за гости на друг хост.

И въпреки че отдавна се знае, че не можеш да правиш нищо сериозно в първия ден след ваканцията, въпреки че се готвех да не работя докрай, възмущението ми от поредното замръзване срина и настроението, и обети от главата ми...

Физическите дискове са преместени на друг хост. Топла връзка. В настройките за съхранение в раздела Дискове появяват се дискове. В раздела Хранилища за данни На тези дискове няма място за съхранение. Обновяване - не се появяват. Е, разбира се, първият импулс - Добавяне на хранилище. Съветникът за добавяне обяснява какво поддържа. Разбира се, поддържа и VMFS. Не се съмнявах в това. Бърз преглед на съобщенията на съветника на всяка стъпка: Напред, Напред, Напред, Край. Окото дори не се доближи до малкото жълто кръгче с удивителен знак в долната част на прозореца на едно от стъпалата на господаря.

В края на съветника новото хранилище за данни се появи в списъка... и заедно с него хранилищата за данни от останалите физически дискове.

Преминавам към навигация в новодобавеното Datastore и то е... празно. Разбира се, отново изпаднах в изумление. 8 сутринта е, първите 15 минути на работа след ваканцията, дори още не съм разбъркал захарта в кафето си. И ето го. Първата мисъл беше, че изтеглих грешния диск от „родния“ хост. Погледнах дали необходимото Datastore присъства в „родния“ хост: не, не присъства. Втората мисъл беше: "Майната му!" Не съм сигурен, но ми се струва, че третата, четвъртата и поне петата мисъл бяха еднакви.

За да разсея съмненията, бързо инсталирах нов ESXi за тестване, взех левия диск и, вече го четейки, преминах през стъпките на съветника. да Когато добавите Datastore с помощта на съветника, всички данни на диска се губят без възможност за връщане назад на операцията и възстановяване на данните. По-късно прочетох в един от форумите оценка на този дизайн от майстор: глупости. И наистина се съгласих.

Започвайки от шестия, мислите потекоха в по-конструктивна посока. ДОБРЕ. Инициализацията отнема няколко секунди дори за 3Tb диск. Така че това е форматиране на високо ниво. Това означава, че таблицата на дяловете е просто пренаписана. Така че данните все още са там. И така, сега ще потърсим някакъв неформат и готово.

Зареждам машината от изображението за стартиране на Strelec... И откривам, че програмите за възстановяване на дялове знаят всичко, освен VMFS. Например, те знаят оформлението на дяловете на Synology, но не и VMFS.

Търсенето в програми не е успокояващо: в най-добрия случай GetDataBack и R.Saver намират NTFS дялове със структура на директория на живо и имена на файлове на живо. Но това не ме устройва. Имам нужда от два vmdk файла: със системния диск и диска с кошчето.

И тогава разбирам, че изглежда, че сега ще инсталирам Windows и ще пусна от резервно копие на файл. И в същото време си спомням, че имах DFS root там. А също и система за права за достъп до папки на отдели, която е абсолютно дива по обхват и разклонения. Не е опция. Единственият приемлив във времето вариант е възстановяване на състоянието на системата и диска с данни и всички права.

Отново Google, форуми, KB'shki и отново плачът на Ярославна: VMware ESXi не предоставя механизъм за възстановяване на данни. Всички дискусионни теми имат два края: някой е бил възстановен с помощта на скъпото DiskInternals VMFS Recovery или някой е бил подпомогнат от софтуерен специалист, който активно рекламира услугите си vmfs-инструменти и dd. Опцията за закупуване на лиценз за възстановяване на DiskInternals VMFS за $700 не е опция. Разрешаването на външен човек от „територията на потенциален враг“ да има достъп до корпоративни данни също не е опция. Но беше гугъл, че VMFS дяловете могат да се четат и от UFS Explorer.

Възстановяване на VMFS на DiskInternals

Пробната версия беше изтеглена и инсталирана. Програмата успешно видя празния VMFS дял:

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

режимът Възстановяване на изтриването (бързо сканиране) Намерих и опърпан Datastore с папки на виртуални машини с дискове вътре:

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Прегледът показа, че файловете са живи:

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Монтирането на дяла в системата беше успешно, но по някаква неизвестна причина и трите папки съдържаха една и съща виртуална машина. Разбира се, според закона подлостта не е това, което се изисква.

Три реда срамОпитът за безсрамно заключване на софтуера завърши с неуспех. Но UFS Explorer е заключен.

Имам изключително негативно отношение към кражбата на софтуер. По никакъв начин не насърчавам използването на средства за заобикаляне на защитата срещу нелицензирана употреба.

Бях в катастрофално положение и изобщо не се гордеех с мерките, към които прибягнах.

UFS Explorer

Сканиране на диск показа наличието на 7 възела. Броят на възлите „изненадващо“ съвпадна с броя на файловете *-flat.vmdk, открити от VMFS Recovery:

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Сравнението на размерите на файловете и размерите на възлите също показа съвпадение до байта. В същото време имената на файловете *-flat.vmdk и съответно принадлежността им към виртуални машини бяха възстановени.

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Като цяло vmdk дисковете от гледна точка на ESXi се състоят от два файла: файл с данни (<име на машина>-flat.vmdk) и файл с „физическо“ оформление на диска (<име на машина>.vmdk). Ако качите файл *-flat.vmdk в Datastore от локална машина, ESXi няма да го разпознае като валиден дисков файл. В базата знания на VMware има статия за това как ръчно да създадете файл с дескриптор на диск: kb.vmware.com/s/article/1002511, но не трябваше да правя това, просто копирах съдържанието на съответните файлове от областта за преглед на съдържанието на файла в DiskInternals VMFS Recovery:

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

След 4 часа разтоварване на 2,5 TB възел от UFS Explorer и 20 часа зареждане в Datastore на хипервайзора, файловете на повредения диск бяха свързани към новосъздадената виртуална машина. Дисковете се вдигнаха. Не се наблюдава загуба на данни.

Възстановяване на виртуални машини от погрешно инициализирано Datastore. Историята на една глупост с щастлив край

Източник: www.habr.com

Добавяне на нов коментар