Käesoleva artikli sisu: Märkus on meelelahutuslik. Sisuline info on selles vähe. See oli kirjutatud "enda jaoks".
Lüüriline sissejuhatus
Meie organisatsiooni failide prügilat haldab virtuaalmasin VMware ESXi 6 Windows Server 2016 all. Ja see ei ole lihtsalt prügil. See on failivahetusserver struktuuriliste üksuste vahel: siit leiate nii koostöö kui ka projektidokumendid ning kaustad võrguskanneritest. Ühesõnaga, siin on kogu tootmiselu.
Ja see kogu tootmiselu keskus hakkas hanguma. Ja külaline võis vaikides ise kinni jääda, mõjutamata teisi. Ta võis endaga kaasa võtta kogu hosti ja sellega kõik ülejäänud külalismasinad. Ta võis kinni jääda ning peatada klientide teenused vSphere: st, et teiste külaliste protsessid on elus, masinad töötavad ja vastavad, kuid failisüsteem ei tööta ja vSphere Client ei saa hostiga ühendust. Ühesõnaga, mingit süsteemi tuvastada ei õnnestunud. Hangumised võisid toimuda päeval nõrga koormuse ajal. Võisid öösel nullkoormuse ajal. Võisid öösel diferentseeritud varundamise ja keskmise koormuse ajal. Võisid nädalavahetustel täieliku varundamise ja kõrge koormuse ajal. Ja olukorra selge halvenemise tunnuseid täheldati. Alguses oli see kord aastas, siis kord pool aastat. Minu kannatuse lõpus — kaks korda nädalas.
Ma kahtlustasin, et probleem on RAM-is. Kuid isegi nädalavahetustel ei lubatud mul prügikasti peatada ja Memtesti käivitada. Ootel oli mai pühasid. Mai pühasid käivitasin Memtesti ja... vigu ei leitud.
Ma olin hämmingus ja otsustasin puhkusеle minna. Kui olin puhkusеl, ei juhtunud prügis kastil ühtegi külmumist. Aga kui esmaspäeval naasin tööle, oli prügis kast külmunud. Ta kannatas täieliku varundamise üle ja just sel ajal külmus. Selline soe puhkusevastuvõtt ajendas mind otsustama füüsiliselt viia kettad külalismasinast teise hosti.
Ja kuigi on ammu teada, et esimesel päeval pärast puhkust ei tohiks teha midagi tõsist, kuigi ma sättisin end teel tööle mitte töötama, viskas minu ehmatus järgmise külmumise pärast mõtted ja lubadused peast...
Füüsilised kettad viidi teise hosti. Ühendamine kuumalt. Hoiustamise seadetes vahekaardil Drives ilmuvad kettad. Vahekaardil Datastores nendel kettadel - ei ole. Käivita - ei ilmu. Ja muidugi, esimene impulss - Add Storage. Meistriliidja ütleb, et ta toetab. Loomulikult toetab ta ka VMFS-i. Ma ei kahtlenud selles. Jooksik üle meisteri teadete igal sammul: Next, Next, Next, Finish. Vaade ei jää isegi kinni allosas ühe sammu aknas oleva väikese kollase ringi juures, millel on üksteist märku tähistav märk.
Meistri ärakirja lõpetamisel ilmus uus andmehoidla nimekirja… koos sellega ka andmehoidlad muudelt füüsilistelt kettadelt.
Lähen uudistama just lisatud andmehoidlat, aga see on… tühi. Loomulikult langesin ma taas hämmastusse. Kell on 8 hommikul, esimesed 15 minutit tööl pärast puhkust, isegi suhkur kohvis ei ole veel segatud. Ja siis selline asi. Esimene mõte oli - vale kett, mida „koduhostist” välja tõin. Vaatasin, kas otsitud andmehoidla on „koduhosti” juures: ei, ei ole. Teine mõte oli: „kuradit!”. Ei ole kindel, aga mulle tundub, et kolmas, neljas ja vähemalt viies mõte olid samasugused.
Kahtluste hajutamiseks paigaldasin kiiresti uue ESXi versiooni, võtsin vale kõvaketta ning tutvusin järk-järgult seadistamisviisardiga. Jah. Andmekogu lisamisel viisardiga kaob kõvakettal kõik andmed ilma võimaluseta operatsiooni tagasi pöörata ja andmeid taastada. Hiljem lugesin foorumist selle viisaka disaini kohta: shitsome crap. Ja nõustusin täiesti sellega.
Alates kuuendast — mõtted voolasid konstruktiivsemaks. Olgu. Algus võtab isegi 3Tb kettale vaid paar sekundit. See tähendab, et tegemist on kõrgtaseme vormindamisega. Tähendab, et jaotustabel lihtsalt kirjutati üle. Tähendab, et andmed on alles. Tähendab, et nüüd otsime mingit unformat'i ja voila.
Laen masinat Strelec'i käivituspildilt... Ja leian, et jaotusprogrammide taastamise rakendused ei tunne VMFS-i. Näiteks tunnevad nad Synology jaotust, aga VMFS-i ei tunne.
Programmide valik ei ole lohutav: parimal juhul leiavad GetDataBack ja R.Saver elusa kaustastruktuuriga ja elusate failinimede NTFS-jaotusi. Kuid mind see ei rahulda. Mul on vaja kahte vmdk-faili: süsteemikettaga ja prükkettaga.
Ja mõistan, et pean nüüd Windowsi installima ja failide varukoopiast taastuma. Samuti meenub, et mul oli seal DFS juur. Ja seal oli täiesti uskumatu õiguste süsteem, mis katab osakondade kaustad. See pole variant. Ainus ajaliselt sobiv variant on süsteemi ja andmete ketta taastamine koos kõigi õigustega.
Jälle googeldamine, foorumid, KB artiklid ja jälle Jerobeam'i nutmine: VMware ESXi ei toeta andmete taastamise mehhanismi. Kõik arutelud lõppevad kahe variandiga: keegi taastub kalliga DiskInternals VMFS Recovery abil või keegi, kes aktiivselt oma teenuseid reklaamib, aitab. vmfs-tools ja dd. Variandi ostmine DiskInternals VMFS Recovery litsentsi eest 700 dollari eest ei ole variant. Kolmandate osapoolte juurdepääs ettevõtte andmetele “potentsiaalsest vastase territooriumilt” ei ole samuti variant. Küll aga leidsin googeldades, et VMFS jaotisi oskab lugeda ka UFS Explorer.
DiskInternals VMFS Recovery
Laadisin alla ja installisin prooviversiooni. Programmi suutis edukalt tuvastada tühja VMFS jaotise:
Režiimis Undelete (Fast Scan) samuti leidis ja kulunud Datastore kaustad virtuaalmasinad ketastega sees:
Eelvaade näitas, et failid on elus:
Osaku monteerimine süsteemi õnnestus, kuid arusaamatutel põhjustel oli kõigis kolmes kaustas üks ja sama virtuaalmasin. Loomulikult — mitte see, mis vajalik.
Kolm häbi ridaPüüdlus programmat varastada lõppes ebaõnnestumisega. Küll aga varastas UFS Explorer.
Ma olen äärmiselt vastu tarkvara varastamisele. Ma ei kutsu mingil juhul üles kasutama litsentsi kaitseülesannete ümbersõitmise vahendeid.
Ma olin katastroofilises olukorras ja ei olnud uhke nende meetmete üle, millele ma pöördusin.
UFS Explorer
Ketaste skaneerimine näitas 7 sõlme olemasolu. Sõlmede arv „üllataval kombel” vastas *-flat.vmdk failide arvule, mis leiti VMFS Recovery:
Failide suuruste ja sõlmede suuruste võrdlemine näitas samuti vastavust kuni baitide kaupa. Samuti taastati *-flat.vmdk failide nimed ja seega nende kuuluvus virtuaalmasinatele.
Üldiselt koosnevad vmdk-kettad ESXi vaates kahest failist: andmefailist (<nime masin>-flat.vmdk) ja disk'i „füüsilisest” jaotusfailist (<nime masin>.vmdk). Kui laadida lokaalsest masinast Datastore'i *-flat.vmdk fail, siis ei tunnusta ESXi seda kui kehtivat ketta faili. VMware'i teadmistebaasis on artikkel selle kohta, kuidas käsitsi luua kettakirjeldaja faili: , aga mul ei olnud seda vaja teha, lihtsalt kopeerisin ja kleepisin vastavate failide sisu DiskInternals VMFS Recovery failisisu eelvaate alal:
Pärast 4 tunni jooksul 2,5Tb sõlme eksportimist UFS Explorer'ist ja 20 tunni jooksul Datastore'i laadimist kaksiku faile ühendati värskelt loodud virtuaalmasinaga. Kettad hakkasid tööle. Andmete kadumist ei märgatud.
Allikas: habr.com
