Disclaimer: Poznámka je pro zábavní účely. Specifická hustota užitečných informací v něm je nízká. Bylo to napsáno „pro sebe“.
Lyrický úvod
Výpis souborů v naší organizaci běží na virtuálním počítači VMware ESXi 6 se systémem Windows Server 2016. A nejedná se jen o výpis odpadu. Jedná se o server pro výměnu souborů mezi strukturálními divizemi: existuje zde spolupráce, projektová dokumentace a složky ze síťových skenerů. Obecně je zde veškerý produkční život.
A tento kontejner veškerého produkčního života začal viset. Navíc se host mohl klidně oběsit, aniž by to ovlivnilo ostatní. Mohl by sundat celého hostitele a podle toho i všechny ostatní hostující stroje. Mohl bych se oběsit a zavěsit klientské služby vSphere: to znamená, že procesy ostatních hostů jsou živé, stroje fungují správně a reagují, ale neexistuje žádný promývač souborů a klient vSphere neulpívá na hostiteli. Obecně nelze identifikovat žádný systém. Během dne při nízké zátěži mohlo dojít k zamrznutí. Mohli to dělat v noci bez zátěže. Mohl v noci při rozdílovém zálohování a průměrné zátěži. Mohlo o víkendech při plném zálohování a vysoké zátěži. A došlo k jasné degradaci situace. Nejprve to bylo jednou za rok, pak jednou za půl roku. Na konci mé trpělivosti - dvakrát týdně.
Měl jsem problém s pamětí. Ale nedovolili mi zastavit hromadu odpadků ani o víkendech a spustit Memtest. Čekali jsme na květnové prázdniny. O květnových prázdninách jsem spustil Memtest a... nenašly se žádné chyby.
Byl jsem ohromen a rozhodl jsem se jet na dovolenou. Když jsem byl na dovolené, na skládce odpadků nebyl jediný problém. A když jsem se v pondělí vrátil první den do práce, byla tam hromada odpadků. Vydržel jsem plnou zálohu a zavěsil jsem hned po jejím dokončení. Takové vřelé přivítání z dovolené mě přimělo k rozhodnutí fyzicky přetáhnout disky s hostujícím počítačem na jiného hostitele.
A ačkoliv se už dávno ví, že první den po dovolené nemůžete udělat nic vážného, ačkoli jsem se celou cestu do práce připravoval, že nebudu pracovat, moje rozhořčení nad dalším mrazem mi srazilo náladu i mou náladu. sliby z mé hlavy...
Fyzické disky byly přesunuty na jiného hostitele. Horké spojení. V nastavení úložiště na záložce Pohony objeví se disky. Na kartě Datová úložiště Na těchto discích není žádné úložiště. Obnovit - neobjevují se. No, samozřejmě, první impuls - Přidat úložiště. Průvodce přidáním vysvětluje, co podporuje. Samozřejmě podporuje i VMFS. Nepochyboval jsem o tom. Rychlý pohled na zprávy průvodce v každém kroku: Další, Další, Další, Dokončit. Oko se ani nepřiblížilo k tomu, aby zachytilo malý žlutý kroužek s vykřičníkem ve spodní části okna jednoho z mistrových schodů.
Na konci průvodce se v seznamu objevilo čerstvé úložiště dat... a spolu s ním i úložiště dat ze zbývajících fyzických disků.
Pokračuji v procházení nově přidaným úložištěm dat a je... prázdné. Samozřejmě jsem znovu upadl v úžas. Je 8 hodin, prvních 15 minut v práci po dovolené, ještě jsem ani nerozmíchal cukr v kávě. A je to tady. První myšlenka byla, že jsem vytáhl špatný disk z „nativního“ hostitele. Podíval jsem se, zda je požadované úložiště dat přítomno v „nativním“ hostiteli: ne, nebylo přítomno. Druhá myšlenka byla: "do prdele!" Nejsem si jistý, ale zdá se mi, že třetí, čtvrtá a alespoň pátá myšlenka byla stejná.
Abych rozptýlil pochybnosti, rychle jsem nainstaloval čerstvé ESXi k testování, vzal levý disk a už ho přečetl a prošel kroky průvodce. Ano. Když přidáte úložiště dat pomocí průvodce, všechna data na disku budou ztracena, aniž by bylo možné vrátit operaci a obnovit data. Později jsem si na jednom z fór přečetl hodnocení tohoto designu od mistra: zasrané svinstvo. A opravdu jsem souhlasil.
Počínaje šestou, myšlenky plynuly konstruktivnějším směrem. OK. Inicializace trvá několik sekund i u 3TB disku. Jedná se tedy o formátování na vysoké úrovni. To znamená, že tabulka oddílů byla jednoduše přepsána. Takže data tam stále jsou. Takže teď budeme hledat nějaké neformátované a voila.
Nabootuji stroj ze spouštěcího obrazu Strelec... A zjišťuji, že programy pro obnovu oddílů umí všechno kromě VMFS. Například znají rozložení oddílů Synology, ale ne VMFS.
Prohledávání programů není uklidňující: v nejlepším případě GetDataBack a R.Saver najdou oddíly NTFS s aktivní adresářovou strukturou a živými názvy souborů. Ale tohle mi nesedí. Potřebuji dva soubory vmdk: se systémovým diskem a disk se soubory koše.
A pak chápu, že to vypadá, že teď nainstaluji Windows a vyjedu ze zálohy souboru. A zároveň si pamatuji, že jsem tam měl kořen DFS. A také systém přístupových práv ke složkám oddělení, který je svým rozsahem a důsledky naprosto divoký. Žádná možnost. Jedinou časově přijatelnou možností je obnovení stavu systému a disku s daty a všemi právy.
Opět Google, fóra, KB'shki a znovu pláč Yaroslavny: VMware ESXi neposkytuje mechanismus pro obnovu dat. Všechna diskusní vlákna mají dva konce: někdo byl obnoven pomocí drahého nástroje DiskInternals VMFS Recovery, nebo někomu pomohl softwarový specialista aktivně propagující jeho služby. vmfs-tools и dd. Možnost zakoupení licence DiskInternals VMFS Recovery za 700 USD není možná. Umožnit cizí osobě z „území potenciálního nepřítele“ přístup k firemním datům také nepřipadá v úvahu. Ale bylo vygooglováno, že VMFS oddíly lze číst i UFS Explorerem.
DiskInternals VMFS Recovery
Zkušební verze byla stažena a nainstalována. Program úspěšně viděl prázdný oddíl VMFS:
režim Obnovit (rychlé skenování) Také jsem našel ošuntělé úložiště dat se složkami virtuálních strojů s disky uvnitř:
Náhled ukázal, že soubory jsou živé:
Připojení oddílu do systému bylo úspěšné, ale z neznámého důvodu všechny tři složky obsahovaly stejný virtuální stroj. Samozřejmě, že podle zákona není podlost to, co se vyžaduje.
Tři řádky hanbyPokus o bezostyšné uzamčení softwaru skončil neúspěchem. Ale UFS Explorer se zablokoval.
Ke krádežím softwaru mám extrémně negativní vztah. V žádném případě nepodporuji používání prostředků k obcházení ochrany proti nelicencovanému použití.
Byl jsem v katastrofální situaci a nebyl jsem vůbec hrdý na opatření, ke kterým jsem se uchýlil.
Průzkumník UFS
Skenování disku ukázalo přítomnost 7 uzlů. Počet uzlů se „překvapivě“ shodoval s počtem souborů *-flat.vmdk detekovaných VMFS Recovery:
Porovnání velikostí souborů a velikostí uzlů také ukázalo shodu až na bajt. Zároveň byly obnoveny názvy souborů *-flat.vmdk a tím i jejich příslušnost k virtuálním strojům.
Obecně se disky vmdk z pohledu ESXi skládají ze dvou souborů: datového souboru (<jméno stroje>-flat.vmdk) a „fyzického“ souboru rozložení disku (<jméno stroje>.vmdk). Pokud nahrajete soubor *-flat.vmdk do úložiště dat z místního počítače, ESXi jej nerozpozná jako platný diskový soubor. Znalostní báze VMware obsahuje článek o tom, jak ručně vytvořit soubor deskriptoru disku: , ale nemusel jsem to udělat, jednoduše jsem zkopíroval obsah odpovídajících souborů z oblasti náhledu obsahu souboru v DiskInternals VMFS Recovery:
Po 4 hodinách stahování 2,5 TB uzlu z UFS Explorer a 20 hodinách načítání do úložiště dat hypervizoru byly soubory havarovaného disku připojeny k nově vytvořenému virtuálnímu počítači. Disky se zvedly. Nebyla pozorována žádná ztráta dat.
Zdroj: www.habr.com