Najważniejsze na start
Datastore zniknął, LUN nie montuje się po restarcie albo maszyny wirtualne nie uruchamiają się po awarii macierzy? W środowiskach VMware, Hyper-V i SAN największe szkody robią szybkie naprawy na produkcji: rescan, import, naprawa datastore albo ponowne mapowanie LUN-ów bez kopii metadanych.
Awaria w środowisku VMware, Hyper-V albo SAN prawie nigdy nie dotyczy jednej warstwy. Z pozoru problem wygląda jak "brak datastore", "niewidoczny LUN" albo niedostępna maszyna wirtualna. W rzeczywistości przyczyna może siedzieć niżej: w macierzy, cache kontrolera, metadanych wolumenu, VMFS/CSV albo w skutkach wcześniejszego restartu czy migracji.
Dlatego odzyskiwanie danych z wirtualizacji wymaga innego podejścia niż zwykły incydent dyskowy. W takim przypadku trzeba rozumieć zależności między hostem, macierzą, datastore, systemem plików i samą maszyną wirtualną. Błąd na jednej warstwie łatwo przenosi się wyżej.
Pierwszy krok
Zabezpiecz środowisko przed dalszym zapisem i zbierz dane techniczne zanim ktoś uruchomi kolejne zmiany na produkcji.
- zapisz modele hostów, macierzy i układ LUN-ów,
- zachowaj komunikaty błędów, logi i czas wystąpienia awarii,
- Nie uruchamiaj kolejnych rescanów, importów ani napraw VMFS/CSV bez wykonania kopii metadanych.
Najczęstsze scenariusze awarii
- ESXi lub Hyper-V przestaje widzieć datastore / CSV po restarcie.
- LUN jest widoczny, ale ma niespójne metadane lub nie daje się poprawnie zamontować.
- Macierz wróciła po awarii, ale maszyny wirtualne nie startują lub mają uszkodzone pliki.
- Rescan, resync lub migracja zostały uruchomione na niewłaściwym etapie incydentu.
- Awaria sprzętowa połączyła się z problemem logicznym — np. błędem RAID i uszkodzeniem struktury datastore.
Czego nie robić w środowisku produkcyjnym
- Nie wykonuj napraw VMFS, CSV ani datastore bez pełnej kopii metadanych.
- Nie mapuj ponownie LUN-ów tylko po to, żeby "sprawdzić", czy wrócą.
- Nie uruchamiaj wielu zmian naraz: restartów hostów, rescanów, importów, aktualizacji kontrolera.
- Nie zapisuj nowych danych na zasobie, który może być logicznie niespójny.
- Nie zakładaj, że problem jest wyłącznie po stronie hypervisora, jeśli wcześniej były błędy macierzy lub zasilania.
Jak wygląda bezpieczna ścieżka odzysku
Najpierw trzeba ustabilizować środowisko i ograniczyć zapisy. Potem zebrać wszystkie informacje: modele serwerów i macierzy, układ LUN-ów, mapowanie hostów, snapshoty, komunikaty, datę ostatnich zmian i objawy po restarcie. Dopiero wtedy można zdecydować, czy bezpieczniej pracować na poziomie macierzy, na kopii LUN-u, na obrazie datastore czy już na plikach maszyn wirtualnych.
W praktyce kluczowe są kopie i rekonstrukcja poza produkcją. To minimalizuje ryzyko, że odzysk jednej warstwy nadpisze inną. W bardziej złożonych przypadkach dopiero analiza na kopii pokazuje, czy problem dotyczy samej wirtualizacji, czy jest skutkiem wcześniejszej awarii RAID lub NAS.
Kiedy zgłosić sprawę od razu
- na datastore stoją krytyczne VM-y, bazy danych lub systemy firmowe,
- problem pojawił się po zaniku zasilania, restarcie macierzy lub migracji,
- widzisz błędy I/O, znikające LUN-y albo niestabilność odczytu,
- ktoś już próbował naprawy na produkcji i objawy się zmieniają,
- przestój rośnie, a środowisko nie ma aktualnej, niezależnej kopii.
Masz awarię VMware, Hyper-V albo SAN i nie chcesz ryzykować na produkcji?
Wyślij model serwera, macierzy, komunikaty błędów i opis objawów przez formularz albo zadzwoń: 573 532 490.
Jak uporządkować incydent zanim zacznie się chaos na produkcji
W środowiskach wirtualnych największym problemem rzadko jest sama awaria. Dużo częściej szkody rosną przez presję czasu i równoczesne działania kilku osób: administrator uruchamia rescan, integrator próbuje remapowania LUN-u, ktoś inny włącza maszynę z kopii, a użytkownicy naciskają na szybki powrót usług. Dlatego już na początku warto wyznaczyć jedną osobę odpowiedzialną za decyzje, zatrzymać niekontrolowane zmiany i spisać sekwencję zdarzeń.
Dobrą praktyką jest też rozdzielenie priorytetów: które maszyny są krytyczne, które dane muszą wrócić najpierw, a które działania mogą poczekać do czasu wykonania bezpiecznej diagnozy. Taki porządek pozwala uniknąć sytuacji, w której pogoń za "szybkim wstaniem" środowiska pogarsza szanse na pełne odzyskiwanie danych z RAID albo odtworzenie maszyn z najbardziej wartościowymi danymi.
Kiedy szukać pomocy zewnętrznej
Jeżeli macierz po restarcie wróciła tylko częściowo, datastore jest widoczny, ale niespójny, a kolejne próby importu lub napraw nie dają stabilnego efektu, to zwykle znak, że problem nie kończy się na poziomie hosta. Wtedy potrzebna jest analiza metadanych, kolejności LUN-ów, stanu cache kontrolera i zależności między warstwą macierzy a systemem plików VMFS lub CSV. To nie jest już dobry moment na eksperymenty wykonywane na produkcji.
Jeżeli temat dotyczy także awarii NAS lub macierzy w firmie, zobacz również instrukcję pierwszych 24 godzin po awarii serwera/NAS oraz wpis awaria RAID w firmie – co robić. Te materiały pomagają uporządkować działania zanim ruszy właściwa diagnoza techniczna.
Jeżeli oprócz warstwy wirtualnej problem dotyczy też samej macierzy albo udziałów firmowych, porównaj objawy z materiałem odzyskiwanie danych z RAID, zobacz korporacyjny case VMware ESXi nie widzi datastore po restarcie i sprawdź, co zrobić w pierwszej dobie po awarii na stronie awaria serwera/NAS – pierwsze 24 godziny.
