Odzyskiwanie danych z VMware, Hyper-V i SAN — tryb B2B

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.

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 migrację uruchomiono 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

1. Nie wykonuj napraw VMFS, CSV ani datastore bez pełnej kopii metadanych.
2. Nie mapuj ponownie LUN-ów tylko po to, żeby "sprawdzić", czy wrócą.
3. Nie uruchamiaj wielu zmian naraz: restartów hostów, rescanów, importów, aktualizacji kontrolera.
4. Nie zapisuj nowych danych na zasobie, który może być logicznie niespójny.
5. 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 procedura 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?
Przekaż model serwera, macierzy, komunikaty błędów i opis objawów. Na tej podstawie dobierzemy bezpieczny pierwszy krok.

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 Dyski SAS i nośniki serwerowe 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.