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.
