Zrzeczenie się: Notatka ma charakter rozrywkowy. Specyficzna gęstość przydatnych informacji w nim jest niska. Został napisany „dla siebie”.
Wprowadzenie liryczne
Zrzut plików w naszej organizacji działa na maszynie wirtualnej VMware ESXi 6 z systemem Windows Server 2016. I nie jest to zwykły zrzut śmieci. Jest to serwer wymiany plików pomiędzy działami strukturalnymi: istnieje współpraca, dokumentacja projektowa i foldery ze skanerów sieciowych. Ogólnie rzecz biorąc, całe życie produkcyjne jest tutaj.
I ten pojemnik całego życia produkcyjnego zaczął wisieć. Co więcej, gość mógł spokojnie się powiesić, nie wpływając na innych. Mógłby zniszczyć całego hosta i, odpowiednio, wszystkie inne maszyny gościnne. Mógłbym się powiesić i zawiesić usługi klienta vSphere: to znaczy, że procesy innych gości żyją, maszyny działają poprawnie i odpowiadają, ale nie ma zmywarki plików, a klient vSphere nie przylega do hosta. Ogólnie rzecz biorąc, nie udało się zidentyfikować żadnego systemu. Zamrożenie może wystąpić w ciągu dnia przy niskim obciążeniu. Mogliby to zrobić w nocy, gdy nie było obciążenia. Może w nocy podczas różnicowego tworzenia kopii zapasowych i średniego obciążenia. Może w weekendy podczas pełnych kopii zapasowych i dużego obciążenia. I nastąpiło wyraźne pogorszenie sytuacji. Na początku było to raz na rok, później raz na pół roku. Kończy mi się cierpliwość - dwa razy w tygodniu.
Miałem problem z pamięcią. Ale nie pozwolili mi zatrzymać śmietnika nawet w weekendy i uruchomić Memtest. Czekaliśmy na majowe wakacje. W czasie majowych wakacji uruchomiłem Memtest i... żadnych błędów nie wykrył.
Byłem zaskoczony i postanowiłem pojechać na wakacje. Będąc na wakacjach nie było ani jednej rozmowy na wysypisku śmieci. A kiedy w poniedziałek pierwszego dnia wróciłem do pracy, zastałam stertę śmieci. Wytrzymałem pełną kopię zapasową i zawiesiłem się zaraz po jej ukończeniu. Tak ciepłe powitanie na wakacjach skłoniło mnie do podjęcia decyzji o fizycznym przeciągnięciu dysków z maszyną gościa do innego hosta.
I choć od dawna wiadomo było, że pierwszego dnia po urlopie nie da się nic poważnego zrobić, choć całą drogę do pracy przygotowywałam się do tego, żeby nie pracować, to moje oburzenie na kolejne zamrożenie popsuło mi nastrój i samopoczucie przysięga z mojej głowy...
Dyski fizyczne zostały przeniesione na inny host. Gorące połączenie. W ustawieniach przechowywania na karcie Napędów pojawiają się dyski. Na karcie Magazyny danych Na tych dyskach nie ma miejsca na dane. Odśwież kod - nie pojawiają się. Cóż, oczywiście, pierwszy impuls - Dodaj miejsce. Kreator dodawania wyjaśnia, co obsługuje. Oczywiście obsługuje również VMFS. Nie wątpiłem w to. Szybki przegląd komunikatów kreatora na każdym kroku: Dalej, Dalej, Dalej, Zakończ. Oko nawet nie zbliżyło się do uchwycenia małego żółtego kółka z wykrzyknikiem na dole okna jednego ze stopni mistrza.
Na końcu kreatora na liście pojawił się świeży Datastore... a wraz z nim Datastore z pozostałych dysków fizycznych.
Przechodzę do nawigacji po nowo dodanym Datastore, który jest… pusty. Oczywiście ponownie wpadłem w zdumienie. Jest 8 rano, pierwsze 15 minut w pracy po wakacjach, a ja jeszcze nawet nie dodałam cukru do kawy. I oto jest. Pierwsza myśl była taka, że wyciągnąłem zły dysk z „natywnego” hosta. Sprawdziłem, czy wymagany Datastore jest obecny na „rodzimym” hoście: nie, nie był obecny. Druga myśl brzmiała: „kurwa!” Nie jestem pewien, ale wydaje mi się, że trzecia, czwarta i co najmniej piąta myśl była taka sama.
Aby rozwiać wątpliwości, szybko zainstalowałem do testów świeżego ESXi, wziąłem lewy dysk i już go czytając przeszedłem kolejne kroki kreatora. Tak. Po dodaniu magazynu danych za pomocą kreatora wszystkie dane na dysku zostaną utracone bez możliwości wycofania operacji i przywrócenia danych. Później przeczytałem na jednym z forów ocenę tego projektu przez mistrza: chujowa bzdura. I naprawdę się zgodziłem.
Począwszy od szóstego, myśli płynęły w bardziej konstruktywnym kierunku. OK. Inicjalizacja zajmuje kilka sekund, nawet w przypadku dysku o pojemności 3 TB. Jest to więc formatowanie wysokiego poziomu. Oznacza to, że tablica partycji została po prostu przepisana. Zatem dane nadal tam są. Więc teraz poszukamy jakiegoś niesformatowanego pliku i voila.
Uruchamiam maszynę z obrazu startowego Strelec... I dowiaduję się, że programy do odzyskiwania partycji wiedzą wszystko oprócz VMFS. Na przykład znają układ partycji Synology, ale nie VMFS.
Przeszukiwanie programów nie daje pewności: w najlepszym przypadku GetDataBack i R.Saver znajdują partycje NTFS ze strukturą katalogów na żywo i nazwami plików na żywo. Ale to mi nie odpowiada. Potrzebuję dwóch plików vmdk: z dyskiem systemowym i dyskiem z plikami śmieci.
A potem rozumiem, że wygląda na to, że teraz zainstaluję system Windows i wdrożę go z kopii zapasowej pliku. A jednocześnie pamiętam, że miałem tam root DFS. A także system praw dostępu do teczek działów, który ma absolutnie szalony zakres i konsekwencje. Nie jest to opcja. Jedyną akceptowalną czasowo opcją jest przywrócenie stanu systemu i dysku z danymi i wszystkimi uprawnieniami.
Znowu Google, fora, KB'shki i znowu płacz Jarosławnej: VMware ESXi nie zapewnia mechanizmu odzyskiwania danych. Wszystkie wątki dyskusji mają dwa zakończenia: ktoś został odzyskany przy użyciu drogiego DiskInternals VMFS Recovery, albo komuś pomógł specjalista ds. oprogramowania aktywnie promujący swoje usługi narzędzia vmfs и dd. Opcja zakupu licencji DiskInternals VMFS Recovery za 700 USD nie wchodzi w grę. Umożliwienie osobie z zewnątrz „terytorium potencjalnego wroga” dostępu do danych korporacyjnych również nie wchodzi w grę. Ale w Google wpisano, że partycje VMFS można również odczytać za pomocą Eksploratora UFS.
Odzyskiwanie danych wewnętrznych dysku VMFS
Wersja próbna została pobrana i zainstalowana. Program pomyślnie zobaczył pustą partycję VMFS:
tryb Przywróć usunięcie (szybkie skanowanie) Znalazłem też obskurny Datastore z folderami maszyn wirtualnych z dyskami w środku:
Podgląd pokazał, że pliki żyją:
Zamontowanie partycji w systemie powiodło się, ale z nieznanego powodu wszystkie trzy foldery zawierały tę samą maszynę wirtualną. Oczywiście, zgodnie z prawem, podłość nie jest wymagana.
Trzy linie wstyduPróba bezwstydnego zablokowania oprogramowania zakończyła się niepowodzeniem. Ale UFS Explorer jest zamknięty.
Mam wyjątkowo negatywny stosunek do kradzieży oprogramowania. W żadnym wypadku nie zachęcam do stosowania środków pozwalających ominąć ochronę przed nielicencjonowanym użyciem.
Znalazłem się w katastrofalnej sytuacji i wcale nie byłem dumny ze środków, jakie zastosowałem.
Eksplorator UFS
Skan dysku wykazał obecność 7 węzłów. Liczba węzłów „zaskakująco” zbiegła się z liczbą plików *-flat.vmdk wykrytych przez VMFS Recovery:
Porównanie rozmiarów plików i rozmiarów węzłów również wykazało dopasowanie co do bajtu. Jednocześnie przywrócono nazwy plików *-flat.vmdk i odpowiednio ich przynależność do maszyn wirtualnych.
Ogólnie rzecz biorąc, dyski vmdk z punktu widzenia ESXi składają się z dwóch plików: pliku danych (-flat.vmdk) i pliku „fizycznego” układu dysku (.vmdk). Jeśli prześlesz plik *-flat.vmdk do Datastore z komputera lokalnego, ESXi nie rozpozna go jako prawidłowego pliku dyskowego. W bazie wiedzy VMware znajduje się artykuł na temat ręcznego tworzenia pliku deskryptora dysku: , ale nie musiałem tego robić, po prostu skopiowałem zawartość odpowiednich plików z obszaru podglądu zawartości pliku w DiskInternals VMFS Recovery:
Po 4 godzinach wyładowywania węzła o pojemności 2,5 TB z Eksploratora UFS i 20 godzinach ładowania do Datastore hypervisora, uszkodzone pliki dyskowe zostały podłączone do nowo utworzonej maszyny wirtualnej. Dyski odeszły. Nie zaobserwowano utraty danych.
Źródło: www.habr.com