Lahtiütlus: Märkus on meelelahutuslikel eesmärkidel. Selles sisalduva kasuliku teabe eritihedus on madal. See oli kirjutatud "enda jaoks".
Lüüriline sissejuhatus
Meie organisatsiooni failitõmmis töötab VMware ESXi 6 virtuaalmasinas, kus töötab Windows Server 2016. Ja see pole lihtsalt prügimägi. See on struktuuriüksuste vaheline failivahetusserver: seal on koostöö, projekti dokumentatsioon ja võrguskannerite kaustad. Üldiselt on kogu tootmiselu siin.
Ja see kogu tootmisea konteiner hakkas rippuma. Pealegi võis külaline end vaikselt üles puua, teisi mõjutamata. Ta võis maha võtta kogu peremehe ja vastavalt ka kõik teised külalismasinad. Võiksin end üles riputada ja vSphere klienditeenindusi üles riputada: see tähendab, et teiste külaliste protsessid on elus, masinad töötavad korralikult ja reageerivad, aga failipesija puudub ja vSphere Client ei klammerdu hosti külge. Üldiselt ei õnnestunud ühtegi süsteemi tuvastada. Madala koormuse korral võib päeva jooksul külmuda. Nad said seda teha öösel ilma koormuseta. Võib öösel diferentsiaali varundamise ja keskmise koormuse ajal. Võiks nädalavahetustel täieliku varundamise ja suure koormuse ajal. Ja olukord halvenes selgelt. Algul kord aastas, siis kord poole aasta jooksul. Minu kannatuse lõpus - kaks korda nädalas.
Mul oli mäluprobleem. Kuid nad ei lubanud mul isegi nädalavahetustel prügihunnikut peatada ja Memtesti käivitada. Ootasime maipühi. Maipühade ajal tegin Memtesti ja... ühtegi viga ei leitud.
Olin üllatunud ja otsustasin puhkusele minna. Sel ajal, kui olin puhkusel, ei toimunud prügimäe juures ainsatki hanget. Ja kui ma esmaspäeval esimest päeva tööle tagasi läksin, oli seal prügihunnik. Ma talusin täielikku varundust ja riputasin kohe pärast selle valmimist. Selline soe vastuvõtt puhkuselt tõukas mind otsusele lohistada kettad koos külalismasinaga füüsiliselt teise hosti juurde.
Ja kuigi on juba ammu teada, et esimesel päeval pärast puhkust ei saa midagi tõsist ette võtta, kuigi valmistusin terve tee tööle mitte töötama, lõi mu nördimus järjekordse külmetuse peale nii mu tuju kui ka mu tuju. lubadused peast välja...
Füüsilised kettad on teisaldatud teise hosti. Kuum ühendus. Vahekaardi salvestusseadetes Veovõlli ilmuvad kettad. Vahekaardil Andmesalved Nendel ketastel pole salvestusruumi. värskendama - ei ilmu. Noh, muidugi, esimene impulss - Lisage salvestusruum. Lisamisviisard selgitab, mida see toetab. Loomulikult toetab see ka VMFS-i. Ma ei kahelnud selles. Kiire pilk viisardi sõnumitele igal sammul: Järgmine, Järgmine, Järgmine, Lõpeta. Silm ei jõudnud ligilähedalegi, et tabada väikest kollast hüüumärgiga ringi ühe meistri astme akna allosas.
Nõustaja lõpus ilmus loendisse värske Datastore... ja koos sellega ka andmesalved ülejäänud füüsilistelt ketastelt.
Liigun äsja lisatud andmesalve navigeerimisele ja see on... tühi. Muidugi langesin uuesti hämmastusse. Kell on 8 hommikul, esimesed 15 minutit pärast puhkust tööl, ma pole veel isegi kohvi sisse seganud. Ja siin see on. Esimene mõte oli, et tõmbasin "natiivsest" hostist vale ketta. Vaatasin, kas vajalik andmesalve on „native” hostis olemas: ei, seda ei olnud. Teine mõte oli: "persse!" Ma pole kindel, aga mulle tundub, et kolmas, neljas ja vähemalt viies mõte olid samad.
Kahtluste hajutamiseks installisin testimiseks kiiresti värske ESXi, võtsin vasaku ketta ja juba seda lugedes kõndisin viisardi sammud läbi. Jah. Kui lisate viisardi abil andmesalve, lähevad kõik kettal olevad andmed kaotsi, ilma et oleks võimalik toimingut tagasi pöörata ja andmeid taastada. Hiljem lugesin ühest foorumist meistri hinnangut sellele disainile: jama. Ja ma olin tõesti nõus.
Alates kuuendast liikusid mõtted konstruktiivsemas suunas. OKEI. Initsialiseerimine võtab isegi 3 Tb ketta puhul aega mõne sekundi. Nii et see on kõrgetasemeline vormindamine. See tähendab, et partitsioonitabel kirjutati lihtsalt ümber. Nii et andmed on alles. Niisiis, nüüd otsime vormingut ja voila.
Käivitan masina Streleci alglaadimispildilt... Ja saan teada, et partitsiooni taastamise programmid teavad kõike peale VMFS-i. Näiteks teavad nad Synology partitsiooni paigutust, kuid mitte VMFS-i.
Programmide kaudu otsimine ei ole rahustav: parimal juhul leiavad GetDataBack ja R.Saver NTFS-i partitsioonid, millel on reaalajas kataloogi struktuur ja reaalajas failinimed. Aga see mulle ei sobi. Mul on vaja kahte vmdk-faili: süsteemiketta ja prügikastifaili kettaga.
Ja siis saan aru, et näib, et installin nüüd Windowsi ja käivitan failivarukoopiast. Ja samas ma mäletan, et mul oli seal DFS-juur. Ja ka osakonna kaustadele juurdepääsuõiguste süsteem, mis on oma ulatuse ja tagajärgede poolest täiesti metsik. Pole valik. Ainus ajaliselt vastuvõetav võimalus on taastada süsteemi ja ketta olek andmete ja kõigi õigustega.
Jälle Google, foorumid, KB'shki ja jälle Jaroslavna nutt: VMware ESXi ei paku andmete taastamise mehhanismi. Kõigil arutelulõimedel on kaks lõppu: keegi taastati kalli DiskInternals VMFS Recovery abil või kedagi aitas tarkvaraspetsialist, kes tema teenuseid aktiivselt reklaamis. vmfs-tööriistad и dd. DiskInternalsi VMFS-i taastamise litsentsi ostmine 700 dollari eest ei ole valik. Samuti ei ole võimalik lubada kõrvalseisjal "potentsiaalse vaenlase territooriumilt" juurdepääsu ettevõtte andmetele. Aga googeldati, et VMFS-i partitsioone saab lugeda ka UFS Exploreriga.
DiskInternalsi VMFS-i taastamine
Prooviversioon laaditi alla ja installiti. Programm nägi tühja VMFS-i partitsiooni edukalt:
režiimi Taasta kustutamine (kiire skannimine) Leidsin ka räbala Datastore'i, kus on virtuaalmasinate kaustad, mille sees on kettad:
Eelvaade näitas, et failid on elus:
Sektsiooni paigaldamine süsteemi õnnestus, kuid teadmata põhjusel sisaldasid kõik kolm kausta sama virtuaalmasinat. Loomulikult ei ole seaduse järgi alatus see, mida nõutakse.
Kolm rida häbiTarkvara häbitult lukustamise katse lõppes ebaõnnestumisega. Kuid UFS Explorer on lukustatud.
Suhtun tarkvaravargustesse äärmiselt negatiivselt. Ma ei julgusta mingil juhul kasutama vahendeid, et vältida kaitset litsentseerimata kasutamise eest.
Olin katastroofilises olukorras ega tundnud meetmete üle, mida olin võtnud, üldse uhke.
UFS-i uurija
Ketta skaneerimine näitas 7 sõlme olemasolu. Sõlmede arv langes "üllatuslikult" kokku VMFS Recovery tuvastatud *-flat.vmdk failide arvuga:
Faili suuruste ja sõlmede suuruste võrdlus näitas ka vastavust baitidele. Samal ajal taastati *-flat.vmdk failide nimed ja vastavalt nende kuuluvus virtuaalsetele masinatele.
Üldiselt koosnevad vmdk-kettad ESXi vaatenurgast kahest failist: andmefailist (<masina nimi>-flat.vmdk) ja “füüsilisest” kettapaigutuse failist (<masina nimi>.vmdk). Kui laadite kohalikust masinast andmesalve üles faili *-flat.vmdk, ei tuvasta ESXi seda kehtiva kettafailina. VMware teadmistebaasis on artikkel ketta deskriptorifaili käsitsi loomise kohta: , kuid ma ei pidanud seda tegema, vaid kopeerisin vastavate failide sisu lihtsalt DiskInternals VMFS Recovery failisisu eelvaate alalt:
Pärast 4-tunnist 2,5 TB sõlme mahalaadimist UFS Explorerist ja 20-tunnist laadimist hüperviisori andmesalve ühendati kokkujooksnud kettafailid vastloodud virtuaalmasinaga. Kettad tõusid üles. Andmete kadumist ei täheldatud.
Allikas: www.habr.com