Відмова від відповідальності: Нотатка має розважальний характер. Питома густина корисної інформації в ній мала. Була написана "для себе".
Ліричний вступ
Файловий смітник у нашій організації крутиться на віртуальній машині 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 з папками віртуальних машин з дисками всередині:
Попередній перегляд показав, що файли живі:
Монтування розділу в систему було успішним, але з незрозумілої причини у всіх трьох папках була та сама віртуалка. Звичайно, за законом підлості — не та, що потрібна.
Три рядки соромуВжита спроба безсовісно запирати софтину закінчилася провалом. Натомість замикався 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