Jogi nyilatkozat: A jegyzet szórakoztató jellegű. A benne található hasznos információk fajlagos sűrűsége alacsony. „Magamnak” írták.
Lírai bevezető
Szervezetünkben a fájlkiírató Windows Server 6 rendszert futtató VMware ESXi 2016 virtuális gépen fut. És ez nem csak egy szeméttelep. Ez egy fájlcsere szerver a szerkezeti részlegek között: van együttműködés, projektdokumentáció és mappák a hálózati szkennerekből. Általánosságban elmondható, hogy a teljes gyártási élet itt van.
És ez a teljes termelési élettartamú konténer lógni kezdett. Sőt, a vendég nyugodtan felakasztotta magát anélkül, hogy a többieket befolyásolná. Le tudta szedni az egész házigazdát és ennek megfelelően az összes többi vendéggépet is. Felakaszthatnám magam és akaszthatnám a vSphere kliens szolgáltatásokat: vagyis a többi vendég folyamatai élnek, a gépek megfelelően működnek és válaszolnak, de nincs fájlmosó, és a vSphere Client sem tapad a gazdagéphez. Általában nem lehetett rendszert azonosítani. Alacsony terhelés mellett napközben is fagyhat. Tehették ezt éjszaka, terhelés nélkül. Éjszaka lehetséges a differenciálmentés és az átlagos terhelés alatt. Hétvégén teljes biztonsági mentés és nagy terhelés alatt. És a helyzet egyértelműen romlott. Eleinte évente egyszer volt, majd félévente egyszer. A türelmem végén - hetente kétszer.
Memória problémám volt. De nem engedték, hogy még hétvégén is leállítsam a szemeteskupacot és futtassam a Memtestet. Vártuk a májusi ünnepeket. A májusi ünnepek alatt lefuttattam a Memtestet és... nem találtam hibát.
Meglepődtem, és úgy döntöttem, elmegyek nyaralni. Amíg nyaraltam, egy szeméttelepen sem volt fennakadás. És amikor hétfőn az első nap visszamentem dolgozni, egy szemétdomb volt. Kibírtam a teljes mentést, és azonnal le is akasztottam, miután elkészült. A vakáció ilyen meleg fogadtatása késztetett arra a döntésre, hogy fizikailag áthúzzam a lemezeket a vendéggéppel egy másik házigazdához.
És bár régóta köztudott, hogy a vakáció utáni első napon nem lehet semmi komolyat csinálni, hiába készültem arra, hogy ne dolgozzunk egészen a munkahelyemig, az újabb fagyás miatti felháborodásom mind a hangulatomon, mind pedig a esküszöm a fejemből...
A fizikai lemezek egy másik gazdagépre kerültek. Forró kapcsolat. A lap tárolási beállításaiban Meghajtók lemezek jelennek meg. A lapon Adattárak Ezeken a lemezeken nincs tárhely. felfrissít - ne jelenjenek meg. Hát persze, az első impulzus... Tárhely hozzáadása. A Hozzáadás varázsló elmagyarázza, mit támogat. Természetesen támogatja a VMFS-t is. nem kételkedtem benne. Gyors pillantás a varázsló üzeneteire az egyes lépéseknél: Következő, Következő, Következő, Befejezés. A szem meg sem közelítette a kis sárga, felkiáltójellel ellátott kört az egyik mester lépcsőjének ablakának alján.
A varázsló végén megjelent a listában a friss Datastore... és vele együtt a Datastore a megmaradt fizikai lemezekről.
Továbblépek az újonnan hozzáadott Datastore navigációjához, és az... üres. Természetesen visszaestem a csodálkozásba. Reggel 8 óra van, szabadság után az első 15 perc a munkahelyemen, még a cukrot sem kavartam a kávémba. És itt van. Az első gondolat az volt, hogy rossz lemezt húztam ki a „natív” gazdagépről. Megnéztem, hogy a szükséges Datastore jelen van-e a „natív” gazdagépen: nem, nem volt jelen. A második gondolat az volt: „A bassza meg!” Nem vagyok benne biztos, de nekem úgy tűnik, hogy a harmadik, negyedik és legalább ötödik gondolat ugyanaz volt.
A kétségek eloszlatására gyorsan telepítettem egy friss ESXi-t tesztelésre, fogtam a bal oldali lemezt, és már olvasva végigmentem a varázsló lépésein. Igen. Amikor a varázsló segítségével adattárat ad hozzá, elveszíti a lemezen lévő összes adatot anélkül, hogy vissza tudná állítani a műveletet és visszaállítani az adatokat. Később az egyik fórumon olvastam egy mester értékelését erről a tervről: baromi baromság. És tényleg egyetértettem.
A hatodiktól kezdve konstruktívabb irányba áramlottak a gondolatok. RENDBEN. Az inicializálás még egy 3 TB-os lemez esetében is másodpercek kérdése. Tehát ez egy magas szintű formázás. Ez azt jelenti, hogy a partíciós tábla egyszerűen át lett írva. Tehát az adatok továbbra is megvannak. Tehát most keresünk valami unformat-ot, és íme.
A Strelec boot image-ről indítom a gépet... És rájövök, hogy a partíció-helyreállító programok a VMFS kivételével mindent tudnak. Például ismerik a Synology partícióelrendezését, de a VMFS-t nem.
A programok közötti keresés nem megnyugtató: a GetDataBack és az R.Saver legjobb esetben is élő könyvtárszerkezettel és élő fájlnevekkel rendelkező NTFS-partíciókat talál. De ez nekem nem jön be. Két vmdk fájlra van szükségem: a rendszerlemezzel és a kuka fájllemezzel.
És akkor megértem, hogy úgy tűnik, most telepítem a Windows-t, és egy biztonsági másolatból fogom telepíteni. És ugyanakkor emlékszem, hogy ott volt egy DFS gyökér. És a részlegmappákhoz való hozzáférési jogok rendszere is, amely teljesen vad terjedelmét és következményeit tekintve. Nem opció. Az egyetlen időre elfogadható lehetőség a rendszer és a lemez állapotának visszaállítása adatokkal és minden joggal.
Ismét a Google, a fórumok, a KB'shki és ismét Jaroszlavna sírása: a VMware ESXi nem biztosít adat-helyreállítási mechanizmust. Minden vitaszálnak két vége van: valakit a drága DiskInternals VMFS Recovery segítségével sikerült helyreállítani, vagy valakit egy szoftverszakértő segített, aki aktívan reklámozta a szolgáltatásait. vmfs-tools и dd. A DiskInternals VMFS Recovery licenc megvásárlása 700 dollárért nem lehetséges. Az sem lehetséges, hogy a „potenciális ellenség területéről” kívülálló hozzáférjen a vállalati adatokhoz. De azt a google-ban keresték, hogy a VMFS partíciókat az UFS Explorer is tudja olvasni.
DiskInternals VMFS helyreállítás
A próbaverzió letöltése és telepítése megtörtént. A program sikeresen látta az üres VMFS partíciót:
az üzemmód Törlés visszavonása (gyors szkennelés) Találtam egy kopott Datastore-t is, amelyben virtuális gépek mappái vannak lemezekkel:
Az előnézet megmutatta, hogy a fájlok élnek:
A partíció beillesztése a rendszerbe sikeres volt, de ismeretlen okból mindhárom mappa ugyanazt a virtuális gépet tartalmazta. Természetesen a törvény szerint nem az aljasság kell.
Három sor szégyenA szoftver szégyentelen zárolására tett kísérlet kudarccal végződött. De az UFS Explorer bezárt.
Rendkívül negatívan viszonyulok a szoftverlopáshoz. Semmilyen módon nem javaslom az engedély nélküli használat elleni védelem megkerülésére szolgáló eszközök alkalmazását.
Katasztrofális helyzetben voltam, és egyáltalán nem voltam büszke azokra az intézkedésekre, amelyekhez folyamodtam.
UFS Explorer
A lemezellenőrzés 7 csomópont jelenlétét mutatta ki. A csomópontok száma „meglepő módon” egybeesett a VMFS Recovery által észlelt *-flat.vmdk fájlok számával:
A fájlméretek és a csomópontok méretének összehasonlítása a bájtig terjedő egyezést is mutatott. Ezzel egy időben a *-flat.vmdk fájlok nevei és ennek megfelelően a virtuális gépekhez való tartozásuk visszaállításra került.
Az ESXi szempontjából a vmdk lemezek általában két fájlból állnak: egy adatfájlból (<gépnév>-flat.vmdk) és egy „fizikai” lemezelrendezési fájlból (<gépnév>.vmdk). Ha egy *-flat.vmdk fájlt tölt fel az adattárba egy helyi gépről, az ESXi nem ismeri fel érvényes lemezfájlként. A VMware Knowledge Base egy cikket tartalmaz a lemezleíró fájl manuális létrehozásáról: , de ezt nem kellett megtennem, egyszerűen átmásoltam a megfelelő fájlok tartalmát a DiskInternals VMFS Recovery fájltartalom előnézeti területéről:
Az UFS Explorerből egy 4 TB-os csomópont eltávolítása 2,5 óra, majd a hipervizor adattárába 20 óra betöltése után az összeomlott lemezfájlokat csatlakoztattuk az újonnan létrehozott virtuális géphez. A lemezek felszedték. Adatvesztés nem volt megfigyelhető.
Forrás: will.com