Отказ: Записката има развлекателен характер. Специфичната плътност на полезната информация в нея е ниска. Беше написана "за себе си".
Личен увод
Файлова сметището в нашата организация работи на виртуална машина VMware ESXi 6 под Windows Server 2016. И това не е просто сметището. Това е сървър за файлов обмен между структурни подразделения: тук има съвместна работа, проектна документация и папки от мрежови сканери. В общи линии, тук е целият производствен живот.
И така, това хранилище на целия производствен живот започна да се блокира. Проблемът беше, че гостът можеше тихо да се блокира сам, без да засяга другите. Можеше да блокира заедно с него целия хост и, съответно, всички останали гости. Можеше да се блокира сам и да блокира клиентските услуги на vSphere: тоест, процесите на другите гости остават живи, машините работят и отговарят, а файловото сметището не работи и клиентът vSphere не може да се свърже с хоста. В общи линии, нямаше ясна система, която да установи проблема. Блокирането можеше да се случи през деня при слаба натовареност. Можеше през нощта при нулево натоварване. Можеше през нощта по време на диференциално архивиране и средно натоварване. Можеше през уикенда по време на пълно архивиране и високо натоварване. И се наблюдаваше явно деградиране на ситуацията. Първоначално ставаше веднъж в година, после веднъж на полугодие. В края на моето търпение — два пъти на седмица.
Греших на оперативната памет. Но не ми позволяваха да спра сметището дори през уикендите и да пусна Memtest. Чакахме майските празници. По време на майските празници пуснах Memtest и… не бяха намерени грешки.
Попаднах в удивление и реших да отида на почивка. Докато бях в отпуск — сметището нямаше нищо блокирано. А когато в понеделник се върнах на работа — сметището беше блокирало. Издържа пълното архивиране и точно в края му се блокира. Такава топла среща след отпуска ме накара да реша физически да прехвърля дисковете с гостовата машина на друг хост.
И, въпреки че отдавна е известно, че в първия ден след отпуска не трябва да се прави нищо сериозно, въпреки че по пътя на работа се настройвах да не работя, моето възмущение от поредното блокиране ми изби от ума и настроението, и заклинанията…
Физическите дискове бяха преместени на друг хост. Свързване на горещо. В настройките на хранилищата на таба Дискове появяват се дискове. На таба Datastores хранилищата на тези дискове — няма. Освежи — не се появяват. А, разбира се, първият импулс е — Добави хранилище. Мастърът за добавяне казва, че поддържа. Разбира се, че поддържа и VMFS. Нито за миг не се съмнявах. Бърз преглед на съобщенията на мастъра на всяка стъпка: Следващ, Следващ, Следващ, Завърши. Погледът дори не закачи малкия жълт кръг с удивителен знак долу в прозореца на една от стъпките на мастъра.
В края на мастъра новият Datastore се появи в списъка… и заедно с него и Datastores от другите физически дискове.
Преминавам към навигацията в току-що добавения Datastore, а той… е празен. Разбира се, отново изпаднах в учудване. 8 часа сутринта, първите 15 минути на работа след отпуска, дори не бях разбъркал захарта в кафето. И изведнъж това. Първата мисъл беше — не този диск от „родния“ хост съм изтеглил. Проверих дали исканият Datastore присъства в „родния“ хост: не, не присъства. Втората мисъл беше: „бля#ь!“. Не съм сигурен, но ми се струва, че третата, четвъртата и поне петата мисъл бяха същите.
За да разсея съмненията, бързо инсталирах на проба нов ESXi, взех ляв диск и, вече четейки внимателно, преминах през стъпките на мастъра. Да. При добавянето на Datastore чрез мастъра се губят всички данни на диска без възможност за отмяна на операцията и възстановяване на данните. По-късно прочетох в един от форумите оценка на този дизайн на мастъра: shitsome crap. И съвсем искрено се съгласих с това.
Започвайки от шестата — мислите потекоха в по-конструктивна посока. Добре. Инициализацията отнема секунди дори за 3Tb-диск. Значи, това е високо ниво на форматиране. Значи, просто таблицата на дяловете е била презаписана. Значи, данните все още са там. Значи, сега ще търсим нещо unformat и voila.
Стартирам машината с загрузочния образ Strelec… И установявам, че програмите за възстановяване на дялове знаят всичко, освен VMFS. Разметката на дяловете на Synology, например, знаят, а VMFS — не.
Прегледът на програмите не е утешителен: в най-добрия случай GetDataBack и R.Saver намират NTFS-дялове с жива структура на каталогите и живи имена на файлове. Но мен това не ме устройва. Нужни са ми два vmdk-файла: с диска на системата и диска на файловете за боклук.
И тук осъзнавам, че изглежда, сега ще трябва да инсталирам Windows и да възстановям от файловия резервен план. И веднага си спомням, че там имах корен 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 с папки на виртуални машини с дискове вътре:
Предварителният преглед показа, че файловете са живи:
Монтирането на раздела в системата беше успешно, но по неясна причина, във всичките три папки имаше една и съща виртуалка. Разбира се, по закона на подлостта – не онази, която е необходима.
Три реда срамПредприетата опит да се пиратства софтуерът завърши с провал. Затова се пиратирах UFS Explorer.
Аз съм крайно негативно настроен към кражбата на софтуер. Никак не призовавам за използване на средства за заобикаляне на защити срещу неразрешено ползване.
Бях в катастрофално положение и никак не се гордеех с мерките, до които прибегнах.
UFS Explorer
Сканирането на диска показа наличието на 7 нода. Броят на нодовете „учудващо“ съвпадна с броя на *-flat.vmdk файловете, открити от VMFS Recovery:
Сравнението на размерите на файловете и размера на нодовете също показа съвпадение до байт. Заедно бяха възстановени имената на *-flat.vmdk файловете и, съответно, тяхната принадлежност към виртуалните машини.
Всъщност, vmdk дисковете от гледна точка на ESXi се състоят от два файла: файл с данни (<име на машината>-flat.vmdk) и файл с „физическата“ структура на диска (<име на машината>.vmdk). Ако се качи файл *-flat.vmdk от локалната машина в Datastore, ESXi няма да го разпознае като валиден файл на диск. В база знанията на VMware има статия за това как ръчно да създадете файл на описанието на диска: , но аз не се налагаше да го правя, просто копирах съдържанието на съответните файлове от прегледа на съдържанието на файла в DiskInternals VMFS Recovery:
След 4 часа извеждане на 2,5TB възел от UFS Explorer и 20 часа зареждане в Datastore, файловете на дисковете бяха свързани към новосъздадена виртуална машина. Дисковете се възстановиха. Загуби на данни не бяха забелязани.
Източник: habr.com
