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

Nie chcesz pogorszyć sytuacji?

Najważniejsze na start

Magazyn danych VMware (datastore) zniknął, LUN nie montuje się po restarcie albo maszyny wirtualne nie uruchamiają się po awarii macierzy? Datastore to magazyn danych maszyn wirtualnych, a LUN to wydzielony zasób z macierzy. W środowiskach VMware, Hyper-V i SAN największe szkody robią szybkie operacje modyfikujące na produkcji: rescan, import, korekta 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ż izolowany incydent nośnika. 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 procedur modyfikujących 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 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

Nie wykonuj procedur modyfikujących 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 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ł działań modyfikujących środowisko produkcyjne 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.

Opisz awarię Omów środowisko

Jak uporządkować incydent, zanim zespół utraci kontrolę nad zmianami w środowisku produkcyjnym

W środowiskach wirtualnych największym problemem rzadko jest sama awaria. Dużo częściej szkody rosną przez presję czasu i równoległe działania kilku osób: administrator uruchamia ponowne skanowanie zasobów, integrator ponownie mapuje LUN, inny zespół uruchamia maszynę z kopii, a użytkownicy naciskają na przywrócenie 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 należy odtworzyć w pierwszej kolejności, a które działania mogą poczekać do czasu wykonania bezpiecznej diagnozy. Taki porządek ogranicza ryzyko, że działania pod presją czasu pogorszą szanse na pełne odtworzenie maszyn lub odzyskanie najważniejszych danych.

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 korekt 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 pamięci podręcznej kontrolera i zależności między warstwą macierzy a systemem plików VMFS lub CSV. To nie jest już dobry moment na niekontrolowane operacje 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 przed rozpoczęciem właściwej diagnostyki technicznej.

Przed zgłoszeniem środowiska VM/SAN

Powiązane poradniki o awariach środowisk firmowych

Zanim zgłosisz środowisko VMware, Hyper-V lub SAN, sprawdź materiały o kolejności działań i bezpiecznym zatrzymaniu pochopnych operacji modyfikujących.

Awaria serwera w firmie — pierwsze 24 godziny

Materiał o bezpiecznym zatrzymaniu chaosu po awarii środowiska serwerowego i decyzjach przed diagnozą.

Czytaj poradnik

RAID to nie backup

Krótki materiał o tym, dlaczego sama redundancja nie zabezpiecza środowiska przed utratą danych.

Czytaj poradnik

Datastore, LUN albo maszyny nie wróciły po restarcie?

Opisz host, macierz, datastore albo LUN — wrócimy z wstępną oceną i bezpiecznym planem odzysku.

Omów środowisko VMware/SAN

FAQ — odzyskiwanie danych z VMware, Hyper-V i SAN

Czy potrzebujecie całej macierzy lub zasobu dyskowego, czy wystarczą eksporty i pliki maszyn?

To zależy od źródła awarii. Czasem wystarczą wybrane pliki i logi, ale przy uszkodzeniu datastore albo warstwy macierzowej potrzebny bywa szerszy materiał do analizy.

Czy da się odzyskać VM po awarii hosta lub datastore?

W wielu przypadkach tak, ale kluczowe jest, aby nie wykonywać pochopnych operacji odbudowy, inicjalizacji czy migracji bez kopii.

Czy pracujecie z VMDK, VHDX, snapshotami i środowiskami wielomaszynowymi?

Tak, analiza takich przypadków zwykle obejmuje nie tylko same pliki maszyn, ale też zależności między snapshotami, konfiguracją hosta i stanem warstwy dyskowej. Szczegółowy zakres pracy na poziomie plików opisujemy w usłudze odzyskiwania danych z VMDK, VHD i VHDX.

Jak ograniczyć ryzyko po awarii środowiska wirtualnego?

Najlepiej zatrzymać niekontrolowane działania modyfikujące środowisko, zabezpieczyć logi i opisać kolejność zdarzeń. W środowiskach VM błędna sekwencja działań potrafi powiększyć zakres uszkodzeń logicznych.