Отказ от отговорност: Забележката е с развлекателен характер. Съдържанието на полезната информация в нея е малко. Написана е "за себе си".
Литературно въведение
Файловата смет на нашата организация върви на виртуална машина VMware ESXi 6 под Windows Server 2016. И това не е просто смет. Това е сървър за файлов обмен между структурни подразделения: тук е и съвместната работа, и проектната документация, и папки от мрежовите скенери. С една дума, тук е целият производствен живот.
И така, това хранилище на целия производствен живот започна да забавя. Гостът можеше да забави сам, без да докосва другите. Можеше да забави целия хост и, съответно, всички останали гостуващи машини. Можеше да забави сам и да спре клиентските услуги на vSphere: т.е. процесите на другите гости остават живи, машините работят добре и отговорят, а файловата смет не и vSphere Client не може да се свърже с хоста. Кратко казано, не можехме да установим система. Забавянията можеха да се случат през деня при слабо натоварване. Можеха да се случат през нощта при нулево натоварване. Можеха да се случат през нощта по време на диференциално архивиране и средно натоварване. Можеха да се случат през уикендите по време на пълно архивиране и високо натоварване. И беше забележима явна деградация на ситуацията. Първоначално това се случваше веднъж годишно, след това веднъж на шест месеца. В края на моето търпение — два пъти седмично.
Упреквах оперативната памет. Но не можех да спра сметта дори през уикенда и да пусна Memtest. Чакаха майските празници. По време на майските празници пуснах Memtest и... не бяха намерени грешки.
Попаднах в изумление и реших да отида в отпуск. Докато бях в отпуск — сметта не беше забавена нито веднъж. А когато в понеделник се върнах на работа — сметта беше забавена. Издържа пълното архивиране и точно след него забави. Такова топло посрещане след отпуска ме подтикна да взема физически дисковете с гостуващата машина и да ги прехвърля в друг хост.
И, макар че отдавна е известно, че в първия ден след отпуска не трябва да се прави нищо сериозно, въпреки че през цялото време по пътя към работата се настройвах да не работя, моето възмущение от новото забавяне ми извади от главата и настроението, и заръките...
Физическите дискове бяха преместени в друг хост. Свързването на горещо. В настройките на хранилищата на раздела Drives появяват се дискове. На таба 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 там. Освен това имам изключително сложна система за права на достъп до папките в отделите. Не е вариант. Единственият приемлив по време вариант е възстановяване на системното състояние и диска с данни и всички права.
Отново търсене в Google, форуми, KB-статии и отново плачът на Ярославна: VMware ESXi не предвижда механизъм за възстановяване на данни. Всички теми в дискусиите имат два завършека: някой се е възстановил с помощта на неевтина DiskInternals VMFS Recovery или на някого му е помогнал активен специалист по vmfs-tools и dd. Опцията с покупка на лиценз за DiskInternals VMFS Recovery за $700 — не е вариант. Допускането на чуждо лице от "територия на потенциален противник" до корпоративните данни — също не е вариант. Затова беше установено, че VMFS разделите може да чете и UFS Explorer.
DiskInternals VMFS Recovery
Беше изтеглена и инсталирана пробна версия. Програмата успешно разпозна празния VMFS раздел:
В режим Undelete (Бързо сканиране) също намери и изтрит 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,5 TB от UFS Explorer и 20 часа зареждане в Datastore хипервизора, повредените файлове на дисковете бяха свързани с новосъздадената виртуална машина. Дисковете бяха разпознати. Загуби на данни не бяха забелязани.
Източник: habr.com
