Disclaimer: Opomba je za zabavne namene. Specifična gostota uporabnih informacij v njem je nizka. Napisano je bilo "zase".
Lirični uvod
Odlagališče datotek v naši organizaciji se izvaja na virtualnem stroju VMware ESXi 6 z operacijskim sistemom Windows Server 2016. In to ni samo odlagališče smeti. To je strežnik za izmenjavo datotek med strukturnimi deli: obstaja sodelovanje, projektna dokumentacija in mape iz omrežnih skenerjev. Na splošno je vse proizvodno življenje tukaj.
In ta posoda vsega proizvodnega življenja je začela viseti. Poleg tega se je gost lahko tiho obesil, ne da bi vplival na druge. Lahko bi odstranil celotnega gostitelja in s tem tudi vse druge gostujoče stroje. Lahko bi se obesil in obesil odjemalske storitve vSphere: to pomeni, da so procesi drugih gostov živi, stroji delujejo pravilno in se odzivajo, vendar ni pralnika datotek in odjemalec vSphere se ne drži gostitelja. Na splošno ni bilo mogoče identificirati nobenega sistema. Med nizko obremenitvijo lahko čez dan pride do zamrzovanja. To so lahko storili ponoči, ko ni obremenitve. Lahko ponoči med diferencialnim varnostnim kopiranjem in povprečno obremenitvijo. Lahko ob vikendih med popolnimi varnostnimi kopijami in veliko obremenitvijo. In prišlo je do očitne degradacije razmer. Sprva enkrat na leto, nato enkrat na pol leta. Na koncu mojega potrpljenja - dvakrat na teden.
Imel sem težave s spominom. Niso pa mi dovolili, da bi ustavila smeti tudi ob vikendih in zagnala Memtest. Čakali smo na majske praznike. Med majskimi počitnicami sem zagnal Memtest in ... ni bilo nobene napake.
Bil sem presenečen in odločil sem se, da grem na dopust. Medtem ko sem bil na dopustu, ni bilo niti enega zastoja na smetišču. In ko sem se v ponedeljek prvi dan vrnil v službo, je bil tam kup smeti. Prestal sem popolno varnostno kopiranje in oblesel takoj, ko je bilo dokončano. Tako topel sprejem z dopusta me je spodbudil k odločitvi, da diske z gostujočim strojem fizično odvlečem na drugega gostitelja.
In čeprav je že dolgo znano, da prvi dan po dopustu ne smeš početi nič resnega, čeprav sem se pripravljala, da ne bom delala vso pot do službe, mi je ogorčenje zaradi ponovne zmrzali pokvarilo tako moje razpoloženje kot zaobljube iz moje glave...
Fizični diski so bili premaknjeni na drugega gostitelja. Vroča povezava. V nastavitvah shranjevanja na zavihku Diski se pojavijo diski. Na zavihku Podatkovne shrambe Na teh diskih ni prostora za shranjevanje. Osveži - se ne pojavijo. No, seveda, prvi impulz - Dodaj shrambo. Čarovnik za dodajanje pojasnjuje, kaj podpira. Seveda podpira tudi VMFS. Nisem dvomil. Hiter pogled na sporočila čarovnika pri vsakem koraku: Naprej, Naprej, Naprej, Konec. Oko ni niti približno ujelo majhnega rumenega kroga s klicajem na dnu okna ene od gospodarjevih stopnic.
Na koncu čarovnika se je na seznamu pojavila nova shramba podatkov ... in skupaj z njo shramba podatkov s preostalih fizičnih diskov.
Nadaljujem z navigacijo po novo dodani shrambi podatkov in je ... prazna. Seveda sem spet padel v začudenje. Ura je 8 zjutraj, prvih 15 minut v službi po dopustu, sladkorja še nisem vmešala v kavo. In tukaj je. Prva misel je bila, da sem iz "domačega" gostitelja potegnil napačen disk. Pogledal sem, ali je zahtevana shramba podatkov prisotna v »domačem« gostitelju: ne, ni bila prisotna. Druga misel je bila: "jebiga!" Nisem prepričan, ampak zdi se mi, da je bila tretja, četrta in vsaj peta misel enaka.
Da bi razblinil dvome, sem hitro namestil svež ESXi za testiranje, vzel levi disk in, ko sem ga že prebral, šel skozi korake čarovnika. ja Ko s čarovnikom dodate shrambo podatkov, se vsi podatki na disku izgubijo, ne da bi bilo mogoče povrniti operacijo in obnoviti podatke. Kasneje sem na enem od forumov prebral oceno tega dizajna s strani mojstra: sranje. In res sem se strinjal.
Od šestega naprej so misli tekle v bolj konstruktivno smer. V REDU. Inicializacija traja nekaj sekund tudi pri 3Tb disku. To je torej oblikovanje na visoki ravni. To pomeni, da je bila particijska tabela preprosto prepisana. Torej so podatki še vedno tam. Torej, zdaj bomo poiskali nekaj neformata in voila.
Zaženem stroj iz zagonske slike Strelca... In ugotovim, da programi za obnovitev particij poznajo vse razen VMFS. Na primer, poznajo postavitev particij Synology, ne pa tudi VMFS.
Iskanje po programih ni pomirjujoče: v najboljšem primeru GetDataBack in R.Saver najdeta particije NTFS z živo strukturo imenikov in živimi imeni datotek. Ampak to mi ne ustreza. Potrebujem dve datoteki vmdk: s sistemsko disketo in disketo za smeti.
In potem razumem, da je videti, kot da bom zdaj namestil Windows in ga uvedel iz varnostne kopije datoteke. In hkrati se spomnim, da sem imel tam DFS root. In tudi sistem pravic dostopa do map oddelkov, ki je popolnoma divji po obsegu in razvejanosti. Ni možnost. Edina časovno sprejemljiva možnost je obnovitev stanja sistema in diska s podatki in vsemi pravicami.
Spet Google, forumi, KB'shki in spet Yaroslavna jok: VMware ESXi ne zagotavlja mehanizma za obnovitev podatkov. Vse teme razprav imajo dva konca: nekdo je bil obnovljen z dragim orodjem DiskInternals VMFS Recovery ali pa je nekomu pomagal strokovnjak za programsko opremo, ki aktivno promovira svoje storitve. vmfs-orodja и dd. Možnost nakupa licence DiskInternals VMFS Recovery za 700 USD ni možnost. Omogočanje dostopa do podatkov podjetja zunanji osebi z »ozemlja potencialnega sovražnika« prav tako ni možnost. Je pa bilo poguglano, da lahko particije VMFS bere tudi UFS Explorer.
DiskInternals VMFS Recovery
Preizkusna različica je bila prenesena in nameščena. Program je uspešno videl prazno particijo VMFS:
način Razveljavi (hitro iskanje) Našel sem tudi zanikrno Datastore z mapami virtualnih strojev z diski v notranjosti:
Predogled je pokazal, da so datoteke žive:
Namestitev particije v sistem je bila uspešna, vendar so iz neznanega razloga vse tri mape vsebovale isti virtualni stroj. Podlost seveda po zakonu ni zahtevana.
Tri vrstice sramuPoskus brezsramnega zaklepanja programske opreme se je končal neuspešno. Toda UFS Explorer je zaklenjen.
Do kraje programske opreme imam izjemno negativen odnos. Nikakor ne spodbujam uporabe sredstev za izogibanje zaščiti pred nelicencirano uporabo.
Bil sem v katastrofalni situaciji in nisem bil prav nič ponosen na ukrepe, h katerim sem se zatekel.
UFS Explorer
Pregled diska je pokazal prisotnost 7 vozlišč. Število vozlišč je "presenetljivo" sovpadalo s številom datotek *-flat.vmdk, ki jih je zaznal VMFS Recovery:
Primerjava velikosti datotek in velikosti vozlišč je prav tako pokazala ujemanje do bajta. Istočasno so bila obnovljena imena datotek *-flat.vmdk in s tem njihova pripadnost virtualnim strojem.
Na splošno so diski vmdk z vidika ESXi sestavljeni iz dveh datotek: podatkovne datoteke (<ime stroja>-flat.vmdk) in datoteke »fizične« postavitve diska (<ime stroja>.vmdk). Če naložite datoteko *-flat.vmdk v Datastore z lokalnega računalnika, je ESXi ne bo prepoznal kot veljavne diskovne datoteke. V zbirki znanja VMware je članek o ročnem ustvarjanju datoteke deskriptorja diska: , vendar mi tega ni bilo treba storiti, preprosto sem kopiral vsebino ustreznih datotek iz območja za predogled vsebine datoteke v DiskInternals VMFS Recovery:
Po 4 urah razkladanja 2,5 TB vozlišča iz UFS Explorerja in 20 urah nalaganja v hipervizorjevo shrambo podatkov so bile zrušene diskovne datoteke povezane z novo ustvarjenim virtualnim strojem. Diski so se pobrali. Izgub podatkov ni bilo opaziti.
Vir: www.habr.com