Käesolev: Märkused on meelelahutuslikud. Selles on vähe kasulikku teavet. Kirjutatud "enda jaoks".
Lüüriline sissejuhatus
Failide prügisort meie organisatsioonis töötab virtuaalmasinas VMware ESXi 6 Windows Server 2016'i all. Ja see ei ole lihtsalt prügisort. See on failivahetussevõime struktuuriüksuste vahel: siin on nii koostöö, projektidokumendid kui ka kaustad võrgu skanneritelt. Ühesõnaga, siin on kogu tootmiselu.
Ja see kogu tootmiselu hoidmine hakkas külmuma. Külastaja võis rahulikult ise kinni jääda, puudutamata teisi. Ta võis külmutada terve hosti ja seega kõik teised külalismasinad. Ta võis ise kinni jääda ja külmutada vSphere kliendi teenuseid: st teiste külaliste protsessid töötavad, masinad vastavad ja töötavad, kuid failide prügisort ei toimi ja vSphere Client ei saa hostiga ühendust. Ühesõnaga, mingit süsteemi tuvastada ei õnnestunud. Kinnijäämised võisid juhtuda päeval nõrga koormuse ajal. Need võisid juhtuda öösel nullkoormuse ajal. Need võisid juhtuda öösel diferentsiaalse varundamise ja keskmise koormuse ajal. Need võisid juhtuda nädalavahetustel täieliku varundamise ja kõrge koormuse ajal. Ja olukord halvenes selgelt. Alguses juhtus see kord aastas, siis kord kuue kuu jooksul. Minu kannatuse lõpuks - kaks korda nädalas.
Ma tunnistasin mälu süüdlaseks. Kuid plaan oli isegi nädalavahetusel prügisordist sulgeda ja läbi viia Memtest. Ootasin mai pühasid. Mai püha ajal jooksin Memtest'i ja… vigu ei leitud.
Olin üllatunud ja otsustasin minna puhkusele. Kui olin puhkusel, ei olnud prügisordil ühtegi kinnijäämist. Ja kui esmaspäeval tööle naasin, oli prügisort kinni. Ta talus täielikku varundamist ja just selle lõpul kinnijäämine juhtus. Selline soe kohtumine puhkuselt ajendas mind otsustama füüsiliselt viia külalismasinate kettad teise hosti.
Ja kuigi juba ammu on teada, et esimesel päeval pärast puhkust ei tohiks midagi tõsist teha, kuigi ma kogu tee tööle seadsin end üles mitte töötama, ajas minu rahulolematus järgmise kinnijäämise häirima mu mõtted ja seadistused.
Füüsilised kettad viidi teise hosti. Ühendamine kuumalt. Salvestusseadiste seadetes vahekaart Kettad ilmuvad kettad. Vahekaardil Andmete salvestusruumid need kettad ei kuvata. Uuenda — ei ilmu. Noh, esmane reaktsioon — Lisa salvestusruumi. Lisamise viisard ütleb, et see toetab. Muidugi toetab ka VMFS. Ma ei kahtlenudki. Kiire ülevaade viisaardi sõnumitest igal sammul: Järgmine, Järgmine, Järgmine, Lõpp. Vaade isegi ei seostunud väikese kollase ringiga, mille sees on hüüumärk ühel viisaardi sammul.
Viisardi lõpetamisel ilmus värske andmete salvestusruum nimekirja... ning koos sellega ka Andmete salvestusruumid teistelt füüsilistelt kettadelt.
Liigun äsja lisatud andmete salvestusruumi navigeerimise juurde, kuid see on... tühi. Loomulikult tabas mind järjekordne üllatus. Kell on 8 hommikul, tööpäeva esimesed 15 minutit pärast puhkust, isegi suhkur kohvis pole veel segatud. Ja siis selline asi. Esimene mõte oli — vale ketas tõmmatud «ema» hostist. Kontrollisin, kas otsitav andmete salvestusruum on «ema» hostis: ei, pole olemas. Teine mõte oli: «m**t!». Ei ole kindel, aga mulle tundub, et kolmas, neljas ja vähemalt viies mõte olid samad.
Kahtluste hajutamiseks paigaldasin kiiresti proovimiseks uue ESXi, võtsin sihitava ketta ja, juba süvenedes, läksin viisaardi samme läbi. Jah. Andmete salvestusruumi lisamisel viisaardi abil kaovad kõik andmed kettalt, ilma võimaluseta operatsiooni tagasi pöörata või andmeid taastada. Hiljem lugesin ühel foorumil hinnangut sellise viisaardi kujunduse kohta: shitsome crap. Ja nõustusin selle arvamusega väga.
Alates kuuendast — mõtted voolasid konstruktiivsematesse suundadesse. Okei. Algatus võtab vaid mõned sekundid isegi 3Tb kettale. Tähendab, see on kõrgema taseme vormindamine. Seega oli lihtsalt jaotustabel kirjutatud üle. Seega on andmed endiselt seal. Seega, nüüd otsime mingisugust unformat ja voila.
Laadin masina Strelec'i käivituspildist... Ja selgitan, et taastamisprogrammid tunnevad kõike, välja arvatud VMFS. Näiteks tunnevad nad Synology jaotust, aga VMFS'i mitte.
Programmide valimine ei ole lohutav: parimal juhul leiavad GetDataBack ja R.Saver NTFS jaotuseid elava katalooge struktuuri ja elavate failide nimedega. Kuid mind see ei rahulda. Mul on vaja kahte vmdk-faili: ühe süsteemi ketta ja ühe prügifailide kettaga.
Ja saan aru, et paistab, et pean nüüd installima Windowsi ja taastama failibackup'ist. Samal ajal meenub, et mul oli seal DFS juur. Ja täiesti ulatuslik ja keeruline kaustade õiguste süsteem. See ei sobi. Ainus ajaliselt vastuvõetav variant on süsteemi ja andmete oleku ning kõigi õiguste taastamine.
Taaskord googeldamine, foorumid, KB-d ja jälle Jarooslavna nutmine: VMware ESXi ei toeta andmete taastamise mehhanismi. Kõigil aruteludel on kaks lõppu: keegi taastus kallis DiskInternals VMFS Recovery abil või aitas keegi oma teenuseid aktiivselt tutvustav spetsialist. vmfs-tools ja dd. DiskInternals VMFS Recovery litsentsi ostmise variant 700 dollari eest ei sobi. Kolmanda isiku juurdepääs „potentsiaalsest vaenlasest territooriumilt“ ettevõtte andmetele — samuti ei sobi. Kuid leiti, et VMFS jaotisi oskab lugeda ka UFS Explorer.
DiskInternals VMFS Recovery
Laaditi alla ja installiti prooviversioon. Programm nägi edukalt tühja VMFS jaotist:
Režiimis Undelete (Fast Scan) leidis samuti ära ka kahjustatud Datastore koos kaustadega virtuaalmasinate ja ketastega seest:
Eelvaade näitas, et failid on elus:
Jaotise montaaž süsteemi oli edukas, kuid arusaamatutel põhjustel oli kõigis kolmes kaustas üks ja sama virtuaalmasin. Loomulikult, halva õnne seaduse kohaselt — ei olnud see see, mis oli vajalik.
Kolm rida häbiKatsed tarkvara rängalt ebaseaduslikult kopeerida lõppesid läbikukkumisega. Kuid UFS Explorer anti üle.
Mul on äärmiselt negatiivne suhtumine tarkvara varastamisse. Ma ei kutsu mingil juhul üles kasutama vahendeid litsentseerimata kasutamise vältimiseks.
Ma olin katastroofilises olukorras ega olnud uhke nende meetmete üle, millele pöördusin.
UFS Explorer
Ketta skaneerimine näitas 7 nodi olemasolu. Nodide arv „hämmastaval kombel“ langes kokku *-flat.vmdk failide arvuga, mille VMFS Recovery leidis:
Failide suuruste ja nodide suuruste võrdlemine näitas samuti täpset ühtlust. Samuti taastati *-flat.vmdk failide nimed ja seega nende kuuluvus virtuaalmasinatesse.
Üldiselt koosnevad vmdk-diskid ESXi vaatenurgast kahest failist: andmefailist (<masina nimi>-flat.vmdk) ja disk struktuuri failist (<masina nimi>.vmdk). Kui laadida *-flat.vmdk fail lokaalsest masinast Datastore'i, ei tunnista ESXi seda kui kehtivat diskifaili. VMware'i teadmusbaasis on artikkel, kuidas käsitsi luua diskide kirjeldusfail: , kuid ma ei pidanud seda tegema, kopeerisin lihtsalt vastavate failide sisu DiskInternals VMFS Recovery failide sisu vaatealasest:
Pärast 4 tunni jooksul 2,5TB sõlme eksportimist UFS Explorer'ist ja 20 tunni jooksul hüpervise Datastore'i laadimist, olid katkised diskifailid ühendatud värskelt loodud virtuaalse masinaga. Diskid töötasid. Andmete kadumise juhtumeid ei tuvastatud.
Allikas: habr.com
