Адмова ад адказнасці: Нататка носіць забаўляльны характар. Удзельная шчыльнасць карыснай інфармацыі ў ёй малая. Была напісана "для сябе".
Лірычны ўступ
Файлавая памыйніца ў нашай арганізацыі круціцца на віртуальнай машыне VMware ESXi 6 пад Windows Server 2016. І гэта не проста памыйніца. Гэта сервер файлавага абмену паміж структурнымі падраздзяленнямі: тут і сумесная праца, і праектная дакументацыя, і тэчкі з сеткавых сканараў. Увогуле, тут усё вытворчае жыццё.
І вось гэтае ёмішча ўсяго вытворчага жыцця стала віснуць. Прычым госць мог ціха павіснуць сам, не закранаючы астатніх. Мог павесіць услед за сабой увесь хост і, адпаведна, усе астатнія гасцявыя машыны. Мог павіснуць сам і павесіць кліенцкія службы vSphere: гэта значыць працэсы астатніх госцяў жывыя, машыны спраўна працуюць і адказваюць, а вось файлапамыйніца няма і vSphere Client да хаста не чапляецца. Увогуле, ніякай сістэмы выявіць не ўдавалася. Завісанні маглі адбыцца днём падчас слабой загрузкі. Маглі ноччу падчас нулявой нагрузкі. Маглі ўначы падчас дыферэнцыяльнага рэзервовага капіявання і сярэдняй загрузкі. Маглі ў выходныя падчас поўнага рэзервовага капіявання і высокай нагрузкі. І назіралася яўная дэградацыя сітуацыі. Спачатку гэта было раз на год, потым раз на паўгода. Пад канец майго цярпення - двойчы на тыдзень.
Я грашыў на аператыўную памяць. Але спыніць памыйніцу нават у выходныя і прагнаць Memtest мне не давалі. Чакалі травеньскіх свят. У травеньскія святы я прагнаў Memtest і… памылак знойдзена не было.
Я захапіўся і вырашыў схадзіць у адпачынак. Пакуль я быў у адпачынку - у памыйніцы не было ніводнага завісання. А калі ў панядзелак выйшаў першы дзень на працу - памыйніца вісела. Вытрывала поўнае рэзервовае капіраванне і акурат пасля яго заканчэння павісла. Такая цёплая сустрэча з водпуску падштурхнула мяне да рашэння фізічна перацягнуць дыскі з гасцявой машынай у іншы хост.
І, хоць даўно вядома, што ў першы дзень пасля водпуску нельга рабіць нічога сур'ёзнага, хоць я ўсю дарогу на працу настройваў сябе не працаваць, маё абурэнне чарговым завісаннем выбіла з галавы і настрой, і зарокі…
Фізічныя дыскі былі перастаўлены ў іншы хост. Падключэнне на гарачую. У наладах сховішчаў на ўкладцы Дыскі з'яўляюцца дыскі. На ўкладцы Сховішчы дадзеных сховішчы на гэтых дысках - не. абнаўленне - не з'яўляюцца. Ну і, зразумела, першы парыў - Дадаць сховішча. Майстар дадання расказвае, што ён падтрымлівае. Вядома падтрымлівае і 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
Сканіраванне дыска паказала наяўнасць 7 нод. Колькасць нод "дзіўнай выявай" супала з колькасцю *-flat.vmdk файлаў, выяўленых VMFS Recovery:
Параўнанне памераў файлаў і памераў нод паказала гэтак жа супадзенне да байта. Заадно былі адноўлены імёны *-flat.vmdk файлаў і, адпаведна, прыналежнасць іх да віртуальных машын.
Наогул, vmdk-дыскі з пункта гледжання ESXi складаюцца з двух файлаў: гэта файл з дадзенымі (<імя машыны>-flat.vmdk) і файл "фізічнай" разметкі дыска (<імя машыны>.vmdk). Калі з лакальнай машыны ў Datastore заліць *-flat.vmdk файл, то ESXi яго не распазнае як валідны файл дыска. У базе ведаў VMware ёсць артыкул аб тым, як уручную стварыць файл дэскрыптара дыска: , але мне рабіць гэтага не прыйшлося, я проста скапісціў змесціва адпаведных файлаў з вобласці прадпрагляду змесціва файла ў DiskInternals VMFS Recovery:
Праз 4 гадзіны выгрузкі 2,5 Тб нода з UFS Explorer'a і 20 гадзін загрузкі ў Datastore гіпервізара грымнутыя файлы дыскаў былі падлучаныя да свежа-створанай віртуальнай машыны. Дыскі падхапіліся. Страты звестак заўважана не было.
Крыніца: habr.com