Informacja: Ten zapis ma charakter rozrywkowy. Gęstość użytecznych informacji jest w nim niska. Został napisany „dla siebie”.
Liryczne wprowadzenie
Kontener plików w naszej organizacji działa na wirtualnej maszynie VMware ESXi 6 pod Windows Server 2016. I to nie jest tylko kontener. To serwer wymiany plików między działami: tu odbywa się współpraca, dokumentacja projektowa i foldery ze skanera sieciowego. W skrócie, całe życie produkcyjne.
I właśnie to miejsce całego życia produkcyjnego zaczęło się zawieszać. Gość mógł zawiesić się sam, nie wpływając na innych. Mógł zawiesić cały host i, odpowiednio, wszystkie inne maszyny gościnne. Mógł zawiesić się sam i zablokować usługi klientów vSphere: to znaczy, że procesy innych gości działały, maszyny działały poprawnie i odpowiadały, ale kontener plików nie działał, a klient vSphere nie mógł połączyć się z hostem. Generalnie, nie udało się znaleźć żadnego systemu. Zawieszenia mogły zachodzić w ciągu dnia podczas słabej obciążenia. Mogły wystąpić w nocy podczas zerowego obciążenia. Mogły wystąpić w nocy podczas różnicowego backupu i średniego obciążenia. Mogły wystąpić w weekendy podczas pełnego backupu i wysokiego obciążenia. Obserwowano wyraźną degradację sytuacji. Na początku zdarzało się to raz w roku, potem raz w półroczu. Z końcem mojego cierpliwości – dwa razy w tygodniu.
Podejrzewałem pamięć RAM. Ale nie pozwolono mi zatrzymać kontenera nawet w weekend i uruchomić Memtest. Czekali na majowe święta. W majowe święta uruchomiłem Memtest i… nie znaleziono żadnych błędów.
Wpadłem w zdumienie i postanowiłem udać się na urlop. Gdy byłem na urlopie – kontener nie miał ani jednego zawieszenia. A kiedy w poniedziałek wróciłem do pracy – kontener zawiesił się. Zdołał przetrwać pełny backup i dokładnie po jego zakończeniu się zawiesił. Takie ciepłe powitanie po urlopie skłoniło mnie do decyzji o fizycznym przeniesieniu dysków z maszyny gościnnej do innego hosta.
I chociaż od dawna wiadomo, że w pierwszy dzień po urlopie nie należy robić nic poważnego, chociaż przez całą drogę do pracy nastawiałem się, aby nie pracować, moje oburzenie kolejnym zawieszeniem wybiło mi z głowy zarówno nastawienie, jak i postanowienia…
Fizyczne dyski zostały przeniesione do innego hosta. Hot swap. W ustawieniach przechowywania na zakładce Dyski pojawiają się dyski. Na zakładce Datastores magazyny na tych dyskach — brak. Odśwież — nie pojawiają się. Cóż, oczywiście, pierwsza myśl — Dodaj pamięć. Kreator dodawania informuje, że obsługuje. Oczywiście, że obsługuje VMFS. Nie miałem wątpliwości. Szybki przegląd komunikatów kreatora na każdym kroku: Dalej, Dalej, Dalej, Zakończ. Spojrzenie nawet nie zatrzymało się na małym żółtym kółku z wykrzyknikiem na dole okna jednego z kroków kreatora.
Po zakończeniu kreatora świeży Datastore pojawił się na liście… a wraz z nim również Datastores z pozostałych dysków fizycznych.
Przechodzę do nawigacji po właśnie dodanym Datastore, a tam… pusto. Oczywiście, znów wpadłem w osłupienie. 8 rano, pierwsze 15 minut pracy po urlopie, nawet cukier w kawie jeszcze nie wymieszany. I nagle to. Pierwsza myśl — nie ten dysk z 'rodzimego' hosta wyciągnąłem. Sprawdziłem, czy poszukiwany Datastore znajduje się w 'rodzimym' hoście: nie, nie ma. Druga myśl była: 'kurczę!'. Nie jestem pewien, ale wydaje mi się, że trzecia, czwarta i przynajmniej piąta myśl były podobne.
Aby rozwiać wątpliwości, szybko zainstalowałem nowego ESXi, wziąłem lewy dysk i, już wczytując się, przeszedłem przez kroki kreatora. Tak. Przy dodawaniu Datastore za pomocą kreatora następuje utrata wszystkich danych na dysku bez możliwości cofnięcia operacji i przywrócenia danych. Później przeczytałem na jednym z forów ocenę tego projektu kreatora: shitsome crap. I naprawdę się z tym zgadzam.
Od szóstej myśli — pomysły zaczęły płynąć w bardziej konstruktywnym kierunku. Dobrze. Inicjalizacja zajmuje zaledwie sekundy, nawet dla dysku 3TB. Oznacza to, że to wysokopoziomowe formatowanie. Oznacza to, że tylko tabela partycji została nadpisana. Oznacza to, że dane wciąż tam są. Oznacza to, że teraz poszukamy jakiegoś unformat i voila.
Uruchamiam maszynę z obrazu startowego Strelec… I odkrywam, że programy do odzyskiwania partycji znają wszystko, oprócz VMFS. Partcjonowanie Synology, na przykład, znają, a VMFS — nie.
Selekcja programów nie napawa optymizmem: w najlepszym przypadku GetDataBack i R.Saver znajdują partycje NTFS z żywą strukturą katalogów i żywymi nazwami plików. Ale mnie to nie zadowala. Potrzebuję dwóch plików vmdk: z dyskiem systemowym i dyskiem z plikami.
I realize now that it seems I'm going to install Windows and restore from the file backup. At the same time, I remember that I had a DFS root there. Also, there’s a completely wild volume and complexity of the access rights system for departmental folders. Not an option. The only time-acceptable option is to restore the system state and the disk with the data and all permissions.
More googling, forums, KB articles, and again the lamentations: VMware ESXi does not provide a data recovery mechanism. All discussion threads have two endings: someone recovered with the not-cheap DiskInternals VMFS Recovery, or someone was helped by a specialist actively promoting their services. vmfs-tools i dd. The option of purchasing a DiskInternals VMFS Recovery license for $700 is not an option. Allowing an outsider from the 'territory of a potential adversary' access to corporate data is also not an option. However, I found out that UFS Explorer can also read VMFS partitions.
DiskInternals VMFS Recovery
A trial version was downloaded and installed. The program successfully detected the empty VMFS partition:
W trybie Undelete (Fast Scan) also found the worn-out Datastore with folders maszyn wirtualnych with disks inside:
The preview showed that the files are alive:
Mounting the partition in the system was successful, but for some unclear reason, all three folders contained the same virtual machine. Of course, Murphy's law — it wasn’t the one I needed.
Three lines of shameThe attempt to shamelessly pirate the software ended in failure. However, UFS Explorer was successfully pirated.
I am extremely negative about software theft. Under no circumstances do I encourage the use of means to bypass protection against unlicensed use.
I was in a catastrophic situation and was not at all proud of the measures I resorted to.
UFS Explorer
Scanning the disk revealed 7 nodes. The number of nodes coincidentally matched the number of *-flat.vmdk files detected by VMFS Recovery:
Comparing the sizes of the files and the sizes of the nodes also showed a match to the byte. Along the way, the names of the *-flat.vmdk files were restored, and accordingly, their affiliation to virtual machines.
W zasadzie dyski vmdk w kontekście ESXi składają się z dwóch plików: pliku z danymi (-flat.vmdk) i pliku „fizycznego” podziału dysku (.vmdk). Jeśli z lokalnej maszyny przesłać plik *-flat.vmdk do Datastore, ESXi nie rozpozna go jako ważny plik dysku. W bazie wiedzy VMware znajduje się artykuł na temat ręcznego tworzenia pliku nagłówka dysku: , ale nie musiałem tego robić, po prostu skopiowałem zawartość odpowiednich plików z podglądu zawartości pliku w DiskInternals VMFS Recovery:
Po 4 godzinach wyprowadzania 2,5TB węzła z UFS Explorera i 20 godzinach ładowania do Datastore hipernadzorca podłączono usunięte pliki dysków do nowo utworzonej maszyny wirtualnej. Dyski zostały rozpoznane. Nie zaobserwowano utraty danych.
Źródło: habr.com
