Відновлення даних з VMware, Hyper-V та SAN — режим B2B

Відмова в середовищі VMware, Hyper-V або SAN майже ніколи не стосується одного шару. З вигляду проблема виглядає як «немає datastore», «невидимий LUN» або недоступна віртуальна машина. Насправді причина може ховатися нижче: у масиві, кеші контролера, метаданих тому, VMFS/CSV або наслідках попереднього рестарту чи міграції.

Тому відновлення даних з віртуалізації вимагає іншого підходу, ніж звичайний інцидент з диском. У такому випадку потрібно розуміти залежності між хостом, масивом, datastore, файловою системою та самою віртуальною машиною. Помилка на одному шарі легко переноситься вгору.

Найпоширеніші сценарії відмов

• ESXi або Hyper-V перестає бачити datastore / CSV після перезавантаження.
• LUN видимий, але має неконсистентні метадані або не можна правильно змонтувати.
• Масив повернувся після відмови, але віртуальні машини не стартують або мають пошкоджені файли.
• Rescan, resync або міграцію запущено на неправильному етапі інциденту.
• Аварія обладнання поєдналася з логічною проблемою — наприклад, помилкою RAID і пошкодженням структури datastore.

Чого не робити в продукційному середовищі

1. Не виконуйте ремонт VMFS, CSV або datastore без повної копії метаданих.
2. Не переназначайте LUN-и лише для того, щоб «перевірити», чи повернуться вони.
3. Не запускайте багато змін одночасно: перезавантаження хостів, rescans, імпорти, оновлення контролера.
4. Не записуйте нові дані на ресурс, який може бути логічно непослідовним.
5. Не припускайте, що проблема лише на боці гіпервізора, якщо раніше були помилки масиву або живлення.

Як виглядає безпечний шлях відновлення

Спочатку потрібно стабілізувати середовище та обмежити записи. Потім зібрати всю інформацію: моделі серверів і масивів, схему LUN-ів, відображення хостів, знімки, повідомлення, дату останніх змін та симптоми після перезавантаження. Тільки тоді можна вирішити, чи безпечніше працювати на рівні масиву, на копії LUN, на зображенні datastore чи вже на файлах віртуальних машин.

На практиці ключовими є копії та відновлення поза виробництвом. Це мінімізує ризик того, що відновлення одного шару перезапише інший. У складніших випадках лише аналіз на копії показує, чи стосується проблема самої віртуалізації, чи є наслідком попередньої відмови RAID або NAS.

Коли слід негайно повідомляти про проблему

• на datastore знаходяться критичні VM, бази даних або корпоративні системи,
• проблема з'явилася після відключення живлення, перезапуску масиву або міграції,
• ви бачите помилки I/O, зникаючі LUN або нестабільність читання,
• хтось уже намагався ремонтувати на продукції, і симптоми змінюються,
• простоїв стає все більше, а середовище не має актуальної незалежної копії.

У вас відмова VMware, Hyper-V або SAN, і ви не хочете ризикувати на продукції?
Надішліть модель сервера, масиву, повідомлення про помилки та опис симптомів через форма або зателефонуйте: 573 532 490.

Як впорядкувати інцидент, перш ніж почнеться хаос на виробництві

У віртуальних середовищах найбільшою проблемою рідко є сама несправність. Значно частіше шкода зростає через тиск часу та одночасні дії кількох осіб: адміністратор запускає повторне сканування, інтегратор намагається зробити переназначення LUN, хтось інший вмикає машину з копії, а користувачі тиснуть на швидке відновлення сервісів. Тому вже на початку варто призначити одну особу, відповідальну за рішення, зупинити неконтрольовані зміни та зафіксувати послідовність подій.

Доброю практикою також є розподіл пріоритетів: які машини критичні, які дані повинні бути відновлені першими, а які дії можуть почекати до завершення безпечної діагностики. Такий порядок дозволяє уникнути ситуацій, коли гонка за "швидким запуском" середовища погіршує шанси на повне відновлення даних з RAID або відновлення машин з найбільш цінними даними.

Коли шукати зовнішню допомогу

Якщо масив після перезавантаження відновився лише частково, datastore видимий, але неконсистентний, а подальші спроби імпорту або виправлення не дають стабільного результату, це зазвичай ознака того, що проблема не обмежується рівнем хоста. Тоді потрібен аналіз метаданих, порядку LUN-ів, стану кешу контролера та залежностей між шаром масиву і файловою системою VMFS або CSV. Це вже не найкращий момент для експериментів в продуктивному середовищі.

Якщо тема також стосується аварії NAS або масиву у компанії, дивіться також інструкцію перших 24 годин після аварії сервера/NAS та запис Поломка RAID у компанії – що робити. Ці матеріали допомагають впорядкувати дії до початку власне технічної діагностики.

Якщо проблема стосується не лише віртуального шару, а й масиву або корпоративних ресурсів, порівняйте симптоми з матеріалом відновлення даних з RAID. Дивіться також кейс-стаді VMware ESXi не бачить datastore після перезавантаження та інструкція на перші добу після збою: збій сервера/NAS – перші 24 години.