Figyelem: Ez a megjegyzés szórakoztató jellegű. Az információ sűrűség alacsony. "Magamnak" íródott.
Lírai bevezető
A fájlmentés a mi szervezetünkben egy Windows Server 2016-on futó VMware ESXi 6 virtuális gépen működik. És ez nem csupán egy hulladéklerakó. Ez a fájlmegosztó szerver a struktúrák között: itt van a közös munka, a projekt dokumentációja és a hálózati szkennelők mappái. Szóval, itt van az egész termelési élet.
És ez a termelési élet összes tárolója elkezdett akadozni. Előfordulhatott, hogy a vendég csendben akadozott, anélkül, hogy befolyásolta volna a többieket. Akadozhatott a gazda mögött, ezzel leállítva az összes többi vendéggépet. Akadozhatott, majd befagyasztotta a vSphere kliens szolgáltatásokat is: azaz a többi vendég folyamatai élnek, a gépek rendben működnek és válaszolnak, de a fájlmentés nem, és vSphere Klien sem tud kapcsolódni a gazdagépre. Összességében nem tudtunk rendszert észlelni. Az akadozások napközben fordulhattak elő gyenge terhelés mellett. Éjjel nulla terhelés mellett. Éjjel a különbségi mentés és közepes terhelés során. Hétvégén a teljes biztonsági mentés és magas terhelés alatt. Nyilvánvaló romlás volt tapasztalható a helyzetben. Eleinte évente egyszer, majd fél évente egyszer. A türelmem végén - hetente kétszer.
A memóriára gyanakodtam. De nem tudtam leállítani a hulladéklerakót még hétvégén sem, és nem volt lehetőségem futtatni a Memtestet. A májusi ünnepekre vártak. A májusi ünnepek alatt futtattam a Memtestet és... nem talált hibát.
Megdöbbentem, és úgy döntöttem, szabadságra megyek. Amíg szabadságon voltam, a hulladéklerakónak nem volt akadozása. Aztán hétfőn, az első munkanapon, a hulladék zárolva volt. Túlélte a teljes biztonsági mentést, és éppen annak befejezésével akadozott. Ez a hősi fogadtatás a szabadságról arra ösztönzött, hogy fizikailag átköltöztetem a vendéggép lemezeit egy másik gazdához.
És bár régóta tudjuk, hogy a szabadság után az első napon semmit sem szabad csinálni, bár az úton a munkába állandóan készült arra, hogy nem dolgozom, a legújabb akadozás miatti felháborodás kiverte a fejemből és a hangulatomat is...
A fizikai lemezeket átköltöztették egy másik gazdához. Forró csatlakozás. A tárolási beállításokban a fülön Levezetések lemez jelenik meg. A fülön Adattárolók a tárolók ezekben a lemezekben — nincsenek. Frissítés — nem jelennek meg. Nos, természetesen az első impulzus — Tárhely hozzáadása. A varázsló elmondja, hogy mit támogat. Természetesen támogatja a VMFS-t. Ebben nem kételkedtem. Pillanatok alatt átfutottam a varázsló üzenetein minden lépésnél: Következő, Következő, Következő, Befejezés. A szemem még csak nem is akadt meg az ablak alján található kis sárga körön, rajta felkiáltójel.
A varázsló befejezése után az új Adattároló megjelent a listában… és vele együtt az Adattárolók a többi fizikai lemezről.
Átmegyek az éppen hozzáadott Adattároló navigálására, de az… üres. Természetesen újra megdöbbentem. 8 óra van, az első 15 perc a munkában a szabadság után, még a cukrot sem kevertem bele a kávémba. És itt ez. Az első gondolat az volt, hogy nem a „hazai” gazdagépről húztam. Ellenőriztem, hogy létezik-e a kívánt Adattároló a „hazai” gazdagépen: nem, nem létezik. A második gondolat az volt: „a francba!”. Nem vagyok benne biztos, de úgy vélem, hogy a harmadik, negyedik és legalább az ötödik gondolat is hasonló volt.
A kétségeim eloszlatása érdekében gyorsan telepítettem egy friss ESXi-t, fogtam egy idegen lemezt, és már olvasva végigjártam a varázsló lépéseit. Igen. Adattároló hozzáadása varázsló révén az adatvesztést okoz a lemezen, lehetőség nélkül az eljárás visszavonására és az adatok helyreállítására. Később olvastam egy fórumon egy ilyen varázsló dizájnjának értékelését: „szar”. És rendkívül egyetértettem.
A hatodik gondolattól kezdve a gondolatok konstruktívabb irányba terelődtek. Rendben. Az inicializálás néhány másodpercet vesz igénybe még a 3Tb-os lemez esetében is. Ez tehát egy magas szintű formázás. Tehát egyszerűen a partíciótábla lett felülírva. Tehát az adatok még mindig ott vannak. Tehát most keresni fogunk valami unformat programot és voila.
Betöltöm a gépet a Strelec boot képről... És kiderítem, hogy a partíció-helyreállító programok mindent tudnak, kivéve a VMFS-t. A Synology partíciói például ismertek, de a VMFS — nem.
A programok átfésülése nem vigasztaló: a legjobb esetben a GetDataBack és az R.Saver NTFS partíciókat találnak élő könyvtárstruktúrával és élő fájlnevekkel. De engem ez nem elégít ki. Két vmdk fájlra van szükségem: az operációs rendszert tartalmazó lemezről és a szemétdiszkről.
És itt rájövök, hogy valószínűleg most Windows-t kell telepítenem, és vissza kell állítanom az adatokat a fájlmentésből. És közben eszembe jut, hogy volt ott egy DFS gyökér. Ráadásul egy teljesen különös, méretében és összetettségében hatalmas mappa-hozzáférési jogok rendszere is. Nem opció. Az egyetlen időben elfogadható megoldás a rendszer és az adatokat tartalmazó lemez állapotának helyreállítása, minden joggal együtt.
Újra guglizás, fórumok, tudásbázisok, és újra a fájdalmas sirámok: a VMware ESXi nem biztosít adatok helyreállítási mechanizmust. Minden egyes beszélgetés két végkimenettel bír: valaki a nem olcsó DiskInternals VMFS Recovery-vel helyreállt, vagy egy aktívan szolgáltatásait népszerűsítő szakember segített valakinek. vmfs-tools és dd. A DiskInternals VMFS Recovery licenc megvásárlása 700 dollárért — nem opció. Külső személy hozzáférése a „potenciális ellenség területéről” a vállalati adatokhoz — szintén nem opció. Viszont kiderült, hogy a VMFS partíciókat az UFS Explorer is olvasni tudja.
DiskInternals VMFS Recovery
Letöltöttem és telepítettem a próbaverziót. A program sikeresen észlelte az üres VMFS partíciót:
A Undelete (Gyors keresés) azt is megtalálta, valamint a Használaton kívüli adatbázist mappákkal virtuális gépekhez a lemezekkel együtt:
Az előzetes nézet megmutatta, hogy a fájlok élnek:
A partíció rendszeren belüli csatolása sikeres volt, de érthetetlen okok miatt mindhárom mappában ugyanaz a virtuális gép volt. Persze, ahogy a balszerencse tartja — nem az, amire szükségem volt.
Három sor szégyenA szoftver jogtalan másolására tett kísérlet pocsék kudarcba fulladt. Viszont sikeresen másoltam az UFS Explorert.
Szigorúan ellenzem a szoftverlopást. Semmiképpen sem bátorítok védett szoftverek engedély nélküli használatára.
Katastrofális helyzetben voltam, és egyáltalán nem büszkélkedtem azzal, amit tettem.
UFS Explorer
A lemez szkennelése 7 csomópontot mutatott. A csomópontok száma „meglepő módon” egybeesett a VMFS Recovery által felfedezett *-flat.vmdk fájlok számával:
A fájlok méretének és a csomópontok méretének összehasonlítása is byte-ra pontos egyezést mutatott. Emellett helyreállították a *-flat.vmdk fájlok neveit, és ennek megfelelően a virtuális gépekhez való tartozását is.
Alapvetően az ESXi szempontjából a vmdk lemezek két fájlból állnak: egy adatfájl (-flat.vmdk) és egy "fizikai" lemezmeghatározó fájl (.vmdk). Ha a helyi gépről feltöltjük a Datastore-ba a *-flat.vmdk fájlt, az ESXi nem ismeri fel mint érvényes lemezfájlt. A VMware tudásbázisában van egy cikk arról, hogyan lehet kézzel létrehozni a lemez leíró fájlt: , de nekem erre nem volt szükségem, egyszerűen átmásoltam a megfelelő fájlok tartalmát a DiskInternals VMFS Recovery fájl tartalom előnézetéből:
Négy óra elteltével a 2,5TB-os csomópont kiemeléséből az UFS Explorerből, és 20 óra elteltével a Datastore-ba való betöltés után a meghibásodott lemezfájlok csatlakoztatva lettek egy frissen létrehozott virtuális géphez. A lemezek működtek. Adatvesztést nem tapasztaltunk.
Forrás: habr.com
