Við hjá Veeam elskum logs. Og þar sem flestar lausnir okkar eru mát, skrifa þær mikið af annálum. Og þar sem umfang starfsemi okkar er að tryggja öryggi gagna þinna (þ.e. rólegur svefn), þá ættu annálarnir ekki aðeins að skrá hvert hnerra, heldur einnig að gera það í smáatriðum. Þetta er nauðsynlegt svo að ef eitthvað er um að ræða sé ljóst hvernig þetta „hvað“ gerðist, hverjum er um að kenna og hvað þarf að gera næst. Þetta er eins og í réttarvísindum: þú veist aldrei hvaða litli hlutur mun hjálpa þér að finna morðingja Lauru Palmer.
Þess vegna ákvað ég að skella mér í röð greina, þar sem ég mun í röð tala um hvað við skrifum á stokkana, hvar við geymum þær, hvernig á ekki að brjálast með uppbyggingu þeirra og hvað á að leita að inni í þeim.
Hvers vegna röð greina og hvers vegna ekki að lýsa öllu í einu?
Einfaldlega að skrá hvaða logg er hvar og hvað er geymt í honum er frekar hörmulegt verkefni. Og það er skelfilegt að hugsa um að halda þessum upplýsingum uppfærðum. Einföld skráning yfir allar mögulegar tegundir annála í Veeam Backup & Replication er tafla á nokkrum blöðum með smáu letri. Já, og það mun aðeins skipta máli við birtingu, vegna þess að. þegar næsti plástur er gefinn út geta nýir logs birst, rökfræði vistuðu upplýsinganna í þeim gömlu mun breytast o.s.frv. Þess vegna verður mun arðbærara að útskýra uppbyggingu þeirra og kjarna upplýsinganna sem eru í þeim. Þetta gerir þér kleift að vafra um staðina betur en banal troðning af nöfnum.
Þess vegna skulum við gera smá undirbúningsvinnu í þessari grein til þess að flýta okkur ekki beint út í laugina af textablöðum. Þess vegna, í dag, munum við ekki komast inn í annálana sjálfa, heldur fara úr fjarska: við munum taka saman orðalista og ræða Veeam uppbygginguna aðeins hvað varðar myndun logs.
Orðalisti og hrognamál
Hér er fyrst og fremst þess virði að biðja meistarana um hreinleika rússnesku afsökunar og votta orðabók Ozhegovs. Við elskum öll móðurmálið okkar mjög mikið, en helvítis upplýsingatækniiðnaðurinn starfar á ensku. Jæja, við komumst ekki upp með það, en það gerðist sögulega. Það er ekki mér að kenna, hann kom sjálfur (c)
Í viðskiptum okkar hefur vandamál anglicisms (og hrognamál) sín sérkenni. Þegar undir saklausum orðum eins og „gestgjafi“ eða „gestur“ hefur allur heimurinn lengi skilið mjög ákveðna hluti, þá heldur áfram hetjulegur ruglingur á ⅙ hluta landsins og að pæla í orðabækur. Og stranglega skylt rök "En í vinnu okkar ...".
Auk þess er það eingöngu hugtök okkar, sem felst í Veeam vörum, þó sum orð og orðasambönd hafi farið til fólksins. Þess vegna munum við nú vera sammála um hvaða hugtak þýðir hvað, og í framtíðinni, undir orðinu „gestur“, mun ég meina nákvæmlega það sem er skrifað í þessum kafla, en ekki það sem þú ert vanur í vinnunni. Og já, þetta er ekki mín persónulega duttlunga, þetta eru rótgróin hugtök í greininni. Að berjast gegn þeim er nokkuð tilgangslaust. Þó ég sé alltaf hlynntur því að slappa af í athugasemdum.
Því miður eru fullt af hugtökum í verkum okkar og vörum svo ég ætla ekki að reyna að telja þau öll upp. Aðeins helstu og nauðsynlegustu upplýsingar um öryggisafrit og logs til að lifa af í sjónum. Fyrir áhugasama get ég líka samstarfsmenn um spólur, þar sem hann gaf einnig lista yfir hugtök sem tengjast þeim hluta virkninnar.
Gestgjafi (gestgjafi): Í heimi sýndarvæðingar er þetta vél með hypervisor. Líkamlegt, raunverulegt, ský - það skiptir ekki máli. Ef eitthvað er að keyra hypervisor (ESXi, Hyper-V, KVM osfrv.), þá er þetta „eitthvað“ kallað gestgjafi. Hvort sem það er þyrping með tíu rekkum eða fartölvan þín með rannsóknarstofu fyrir eina og hálfa sýndarvél - ef þú ræstir hypervisor, þá varðstu gestgjafi. Vegna þess að hypervisor hýsir sýndarvélar. Það er meira að segja saga um að VMware hafi á sínum tíma viljað ná traustum tengslum við orðið gestgjafi við ESXi. En hún gerði það ekki.
Í nútíma heimi hefur hugtakið "gestgjafi" nánast sameinast hugtakinu "þjónn", sem veldur smá ruglingi í samskiptum, sérstaklega þegar kemur að Windows innviðum. Svo hvaða vél sem hýsir einhverja þjónustu sem vekur áhuga okkar er óhætt að kalla gestgjafa. Til dæmis, í WinSock logs er allt merkt með orðinu host. Hið klassíska „Host not found“ er dæmi um þetta. Svo við byrjum á samhenginu, en mundu - í heimi sýndarvæðingar er gestgjafi það sem hýsir gesti (nánar um þetta í tveimur línum hér að neðan).
Frá staðbundnu hrognamáli (frekar jafnvel skammstöfun, í þessu tilfelli), er minnt á hér að VMware er VI, vSphere er VC og Hyper-V er HV.
Gestur (gestur): Sýndarvélin sem keyrir á gestgjafanum. Hér er ekkert að útskýra, allt er svo rökrétt og einfalt. Hins vegar draga margir duglega hingað einhverjar aðrar merkingar.
Til hvers? Ég veit ekki.
Guest OS, hver um sig, stýrikerfi gestavélarinnar. Og svo framvegis.
Afritunar-/afritunarstarf (jobA): Hreint Wim hrognamál, táknar sum verkefnin. Öryggisvinna == Öryggisvinna. Enginn hefur fundið út hvernig á að þýða það fallega yfir á rússnesku, svo allir segja „JobA“. Með áherslu á síðasta atkvæði.
Já, þeir taka því einfaldlega og segja „joba“. Og jafnvel í bréfum skrifa þeir svona, og allt er í lagi.
Allskonar afritunarstörf, öryggisafritunarverkefni o.s.frv., takk, en engin þörf. Bara vinna, og þú munt skilja. Aðalatriðið er að leggja áherslu á síðasta atkvæði.
Öryggisafrit (Öryggisafrit, öryggisafrit. Fyrir true-oldfags, öryggisafrit er leyfilegt): Til viðbótar við hið augljósa (afrit af gögnum sem liggja einhvers staðar), þýðir það líka starfið sjálft (þrjár línur fyrir ofan, ef þú hefur þegar gleymt), sem afleiðing af því að sjálf öryggisafritið birtist. Sennilega eru herrar sem hafa ensku að móðurmáli of latir til að segja að ég hafi keyrt öryggisafritið mitt í hvert skipti, svo þeir segja bara að ég hafi keyrt öryggisafritið mitt og allir skilja hver annan fullkomlega. Ég býð ykkur að styðja þetta frábæra framtak.
Sameina (samþjöppun): Hugtak sem birtist í ESXi 5.0 Valkostur í skyndimyndavalmyndinni sem byrjar ferli við að eyða svokölluðum munaðarlausum skyndimyndum. Það er skyndimyndir sem eru líkamlega tiltækar, en féllu úr birtri rökréttri uppbyggingu. Fræðilega séð ætti þetta ferli ekki að hafa áhrif á skrárnar sem birtast í skyndimyndastjóranum, en allt getur gerst. Kjarninn í samþjöppunarferlinu er að gögnin frá skyndimyndinni (undirdiskur) eru skrifuð á aðal (foreldri) diskinn. Ferlið við að sameina diska er kallað sameining. Ef samstæðuskipun hefur verið gefin út, þá er hægt að fjarlægja skyndimyndafærsluna úr gagnagrunninum áður en skyndimyndin er sameinuð og eytt. Og ef ekki var hægt að eyða skyndimyndinni af einhverjum ástæðum, þá birtast þessar sömu munaðarlausu skyndimyndir. Um að vinna með skyndimyndir hefur VMware . Og við líka einhvern veginn um þá .
Gagnageymsla (geymsla eða geymsla): Mjög víðtækt hugtak, en í heimi sýndarvæðingar er litið á það sem staður þar sem sýndarvélaskrár eru geymdar. En í öllu falli, hér þarftu að skilja samhengið mjög skýrt og með minnsta vafa, skýra hvað viðmælandi þinn hafði í huga.
Umboð (umboð): Það er mikilvægt að skilja strax að Veeam Proxy er ekki alveg það sama og við eigum að venjast á netinu. Innan Veeam vörur er þetta eins konar eining sem fæst við að flytja gögn frá einum stað til annars. Ef þú ferð ekki í smáatriði, þá er VBR stjórnunar- og stjórnunarþjónn og umboð eru vinnuhestar hans. Það er, umboð er vél sem umferð flæðir í gegnum og þar sem VBR íhlutir eru settir upp sem hjálpa til við að stjórna þessari umferð. Til dæmis til að flytja gögn frá einni rás til annarrar, eða einfaldlega að festa diska við sjálfa sig (HotAdd háttur).
Geymsla (Repository): Tæknilega séð er þetta bara færsla í VBR gagnagrunninum sem gefur til kynna hvar afritin eru geymd og hvernig á að tengjast þessum stað. Reyndar getur það verið annað hvort bara CIFS bolti eða aðskilinn diskur, þjónn eða fötu í skýinu. Aftur, við erum í samhengi, en við skiljum að geymsla er bara staður þar sem öryggisafrit þín eru.
Skyndimynd (SnapshOt): Oxford málfræðiáhugamenn vilja frekar segja hver er skyndimynd og hver er skyndimynd, en ólæs meirihluti hagnast á stærri fjöldanum. Ef einhver veit það ekki þá er þetta tækni sem gerir þér kleift að endurheimta ástand disks á ákveðnum tímapunkti. Þetta er gert annað hvort með því að beina I/O aðgerðum tímabundið frá aðaldisknum - þá verður það kallað RoW (Redirect on Write) skyndimynd - eða með því að færa endurskrifanlegar blokkir af disknum þínum yfir á annan - þetta mun kallast CoW (Copy on Write) ) skyndimynd. Það er að þakka víðtækum möguleikum til að nota þessar aðgerðir sem Veeam getur unnið öryggisafritsgaldur sinn. Strangt til tekið, ekki bara þau, heldur er þetta spurningin um næstu útgáfur.
Það er ringulreið í kringum þetta hugtak í ESXi skjölunum og annálum, og í samhengi við að nefna skyndimyndir, geturðu fundið skyndimyndir sjálfar og endurtekið log, og jafnvel delta disk. Veeam skjölin innihalda ekki slíkt rif, og skyndimynd er skyndimynd, og endurtaka log er einmitt REDO skrá búin til af óháðum óviðvarandi diski. REDO skrám er eytt þegar slökkt er á sýndarvélinni, svo að rugla þeim saman við skyndimyndir er leið til bilunar.
Tilbúið (gerviefni): Tilbúið afrit eru öfug stigvaxandi og að eilífu áfram afrit. Ef þú hefur ekki rekist á þetta hugtak, þá er það bara einn af þeim aðferðum sem notuð eru til að byggja upp varakeðjubreytingu. Hins vegar, í annálunum er einnig hægt að finna hugtakið Transform, sem er notað í ramma þess að búa til full afrit úr þrepum (tilbúið fullt).
Verkefni (Task): Þetta er ferlið við að vinna hverja einstaka vél innan verksins. Það er: þú ert með öryggisafrit sem inniheldur þrjár vélar. Þetta þýðir að hver bíll verður afgreiddur sem hluti af sérstöku verkefni. Alls verða annálarnir fjórir: sá aðal fyrir störf og þrír fyrir verkefni. Hins vegar er hér mikilvægur blær: Með tímanum hefur orðið „verkefni“ orðið óþarflega óljóst. Þegar við tölum um almenna annála er átt við að verkefni sé einmitt VM. En það eru „verkefni“ bæði á umboðinu og á geymslunni. Þar getur það þýtt sýndardiskur, sýndarvél og allt starfið. Það er, það er mikilvægt að missa ekki samhengið.
Veeam %name% Þjónusta: Til hagsbóta fyrir árangursríkar öryggisafrit virka nokkrar þjónustur í einu, lista yfir þær er að finna í staðalbúnaðinum. Nöfn þeirra endurspegla kjarna þeirra nokkuð gegnsætt, en meðal jafningja er það mikilvægasta - Veeam Backup Service, án hennar mun restin ekki virka.
VSS: Tæknilega séð ætti VSS alltaf að standa fyrir Microsoft Volume Shadow Copy Service. Reyndar er það notað af mörgum sem samheiti fyrir forrita-meðvituð myndvinnslu. Sem er auðvitað afdráttarlaust rangt, en þetta er saga úr flokknum „Það má kalla hvaða jeppa sem er jeppi og þú munt skilja þig“.
Frábærir timbur og hvar þeir búa
Mig langar að byrja þennan kafla á því að afhjúpa hið mikla leyndarmál - hvaða tími birtist í annálunum?
Mundu:
- ESXi skrifar alltaf logs í UTC+0.
- vCenter heldur annálum í samræmi við tíma tímabeltis þess.
- Veeam heldur skrár eftir tíma og tímabelti þjónsins sem það er á.
- Og aðeins Windows atburðir á EVTX sniði þjást ekki af bindingu við neitt. Þegar opnað er er tíminn endurreiknaður fyrir bílinn sem þeir voru opnaðir á. Þægilegasti kosturinn, þó að það séu erfiðleikar við hann. Eini áþreifanlegi erfiðleikinn er munurinn á stöðum. Þetta er nánast tryggð leið að ólæsilegum annálum. Já, það eru möguleikar á því hvernig á að meðhöndla þetta, en við skulum bara ekki rífast við þá staðreynd að allt í upplýsingatækni virkar á ensku, og samþykkjum að stilla alltaf enska staðalinn á netþjónunum. Ó takk.
Nú skulum við tala um staðina þar sem stokkarnir búa og hvernig á að fá þá. Í tilviki VBR eru tvær aðferðir.
Fyrsti valkosturinn er hentugur ef þú ert ekki fús til að leita að skrám í almennu hrúgunni sem eru sérstaklega tengdar vandræðum þínum. Til að gera þetta höfum við sérstakan töframann, sem þú getur tilgreint tiltekið starf og ákveðið tímabil sem þú þarft logs fyrir. Svo fer hann sjálfur yfir möppurnar og setur allt sem þú þarft í eitt skjalasafn. Hvar á að leita að því og hvernig á að vinna með það er lýst í smáatriðum í .
Hins vegar safnar töframaðurinn ekki annálum allra verkefna og, til dæmis, ef þú þarft að rannsaka loga endurheimtingar, bilunar eða bilunar, liggur leiðin þín í möppunni %ProgramData%/Veeam/Backup. Þetta er aðal VBR logostore og %ProgramData% er falin mappa og það er allt í lagi. Við the vegur, sjálfgefna staðsetningu er hægt að endurúthluta með því að nota REG_SZ: LogDirectory tegund skrásetningarlykils í HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam öryggisafrit og afritunargrein.
Á Linux vélum ætti að leita að starfsumboðsskrám í /var/log/VeeamBackup/ef þú notar root eða sudo reikning. Ef þú hefur ekki slík réttindi skaltu leita að innskráningu /tmp/VeeamBackup.
Fyrir Veeam umboðsmann fyrir %OS_name% ætti að leita í annálum %ProgramData%/Veeam/Endapunktur (Eða %ProgramData%/Veeam/Backup/Endapunktur) Og /var/log/veeam sig.
Ef þú ert að nota forrita-meðvitaða myndvinnslu (og líklegast ertu það), þá verður ástandið nokkuð flóknara. Þú þarft loga hjálparans okkar, sem eru geymdir inni í sýndarvélinni sjálfri, og VSS logs. Um hvernig og hvar á að fá þessa hamingju, það er skrifað í smáatriðum í . Og auðvitað er það til að safna nauðsynlegum kerfisskrám.
Windows viðburðum er þægilega safnað skv . Ef þú ert að nota Hyper-V verða hlutirnir flóknari, þar sem þú þarft líka alla annála þess frá forrita- og þjónustuskrám > Microsoft > Windows útibú. Þó þú getur alltaf farið heimskulegri leiðina og bara tekið upp alla hlutina úr %SystemRoot%System32winevtLogs.
Ef eitthvað bilar við uppsetningu/uppfærslu, þá er allt sem þú þarft að finna í %ProgramData%/Veeam/Setup/Temp möppunni. Þó að ég muni ekki fela þá staðreynd að í OS atburðum er hægt að finna gagnlegri upplýsingar en í þessum logs. Afgangurinn af því áhugaverða liggur í %Temp%, en það eru aðallega uppsetningarskrár fyrir tengdan hugbúnað, eins og grunninn, .Net bókasöfn og annað. Athugaðu að Veeam er sett upp frá msi og allir íhlutir þess eru einnig settir upp sem aðskildir msi pakkar, jafnvel þótt þetta hafi ekki verið sýnt í GUI. Þess vegna, ef uppsetning eins af íhlutunum mistekst, verður allri VBR uppsetningunni hætt. Þess vegna þarftu að fara inn í logs og sjá hvað nákvæmlega brotnaði og á hvaða tímapunkti.
Og að lokum, lífshakk: ef þú færð villu við uppsetningu skaltu ekki flýta þér að smella á OK. Fyrst tökum við skrárnar og smellum síðan á OK. Þannig færðu annál sem endar á þeim tíma sem villan kemur upp, án sorps í lokin.
Og það gerist að þú þarft að komast inn í vSphere logs. Atvinnan er mjög vanþakklát, en eftir að hafa brett upp ermarnar þarf maður að gera eitthvað annað. Í einföldustu útgáfunni þurfum við loga með sýndarvélaviðburðum vmware.log, sem liggja við hliðina á .vmx skránni. Í erfiðara tilfelli, opnaðu Google og spyrðu hvar skrárnar fyrir gestgjafaútgáfuna þína eru staðsettar, þar sem VMware elskar að breyta þessum stað frá útgáfu til útgáfu. Til dæmis, , en fyrir . Fyrir vCenter logs, endurtaktu ferlið . En almennt munum við hafa áhuga á hýsingaratburðaskrám hostd.log, hýsingarviðburðum sem stjórnað er af vCenter vpxa.log, kjarnaskrám vmkernel.log og auðkenningarskrám auth.log. Jæja, í flestum vanræktum tilfellum getur SSO login, sem liggur í SSO möppunni, komið sér vel.
Fyrirferðarmikið? Ruglaður? Hræðilegt? En þetta er ekki einu sinni helmingur þeirra upplýsinga sem stuðningur okkar vinnur með daglega. Svo þeir eru virkilega, virkilega flottir.
Veeam íhlutir
Og sem niðurstaða á þessari inngangsgrein skulum við tala aðeins um íhlutina í Veeam Backup & Replication. Því þegar þú ert að leita að orsök sársauka væri gaman að skilja hvernig sjúklingurinn virkar.
Svo eins og allir vita eflaust er Veeam Backup svokallað SQL byggt forrit. Það er, allar stillingar, allar upplýsingar og almennt allt sem er aðeins nauðsynlegt fyrir eðlilega virkni - allt þetta er í gagnagrunni þess. Eða réttara sagt, í tveimur gagnagrunnum, ef við erum að tala um fullt af VBR og EM: VeeamBackup og VeeamBackupReporting, í sömu röð. Og svo gerðist það: við settum annað forrit - annar gagnagrunnur birtist. Til að geyma ekki öll eggin í einni körfu.
En til að allt þetta hagkerfi virki snurðulaust þurfum við safn þjónustu og forrita sem mun tengja alla íhluti saman. Bara sem dæmi, þetta er hvernig það lítur út í einni af rannsóknarstofum mínum:
Starfar sem aðalhljómsveitarstjóri Veeam öryggisafritunarþjónusta. Það er hann sem ber ábyrgð á upplýsingaskiptum við bækistöðvarnar. Hann er líka ábyrgur fyrir því að koma öllum verkefnum af stað, skipuleggja úthlutað fjármagn og vinna sem eins konar fjarskiptamiðstöð fyrir margs konar leikjatölvur, umboðsmenn og allt annað. Í orði, það er örugglega engin leið án hans, en það þýðir alls ekki að hann geri allt sjálfur.
Hjálpar honum að uppfylla áætlun sína Veeam Backup Manager. Þetta er ekki þjónusta, heldur eining sem setur störf af stað og fylgist með framkvæmd þeirra. Vinnandi hendur öryggisafritunarþjónustunnar, sem hún tengist vélum, býr til skyndimyndir, fylgist með varðveislu og svo framvegis.
En aftur að lista yfir þjónustu. Veeam miðlaraþjónusta. Birtist í v9.5 (og þetta er ekki dulmálsnámumaður, eins og sumir héldu þá). Safnar upplýsingum um VMware vélar og viðheldur mikilvægi þeirra. En ekki hlaupa strax til að skrifa reiðar athugasemdir um að við séum að njósna um þig og leka öllum innskráningum / lykilorðum til taschmajor. Allt er nokkuð einfaldara. Þegar þú keyrir öryggisafrit er það fyrsta sem þú þarft að gera að tengjast gestgjafanum og uppfæra öll gögn um uppbyggingu hans. Þetta er frekar hæg og vandræðaleg saga. Mundu bara hversu langan tíma það tekur fyrir þig að skrá þig inn í gegnum vefviðmótið og mundu að aðeins efsta lagið er talið þar. Og þá þarftu samt að opna allt stigveldið á réttan stað, við the vegur. Í einu orði sagt, hryllingur. Ef þú keyrir tugi afrita, þá þarf hvert verk að gera þessa aðferð. Ef við erum að tala um stóra innviði, þá getur þetta ferli tekið tíu mínútur eða meira. Því var ákveðið að úthluta sérstakri þjónustu fyrir þetta þar sem hægt verður að fá alltaf uppfærðar upplýsingar. Við ræsingu athugar og skannar það alla innviði sem bætt er við og reynir síðan að vinna aðeins á stigum stigvaxandi breytinga. Þannig að jafnvel þótt þú keyrir hundrað afrit á sama tíma, munu þeir allir biðja um upplýsingar frá miðlara okkar og munu ekki kvelja gestgjafana með beiðnum sínum. Ef þú hefur áhyggjur af auðlindum, þá þurfa 5000 sýndarvélar, samkvæmt útreikningum okkar, aðeins um 100 Mb af minni.
Næst höfum við Veeam Console. Hann er Veeam Remote Console, hann er Veeam.Backup.Shell. Þetta er sama GUI og við sjáum á skjámyndunum. Allt er einfalt og augljóst - stjórnborðið er hægt að ræsa hvar sem er, svo framarlega sem það er Windows og það er tenging við VBR netþjóninn. Það eina sem hægt er að segja er að FLR ferlið mun festa punkta á staðnum (þ.e.a.s. á vélinni þar sem stjórnborðið er í gangi). Jæja, ýmsir Veeam Explorers munu einnig keyra á staðnum, vegna þess að þeir eru hluti af stjórnborðinu. En það hefur þegar borið mig út í óbyggðirnar ...
Önnur áhugaverð þjónusta er Veeam Backup Catalog Data Service. Þekktur sem Veeam Guest Catalog Service á listanum yfir þjónustur. Hann tekur þátt í að skrá skráarkerfi á gestavélar og fyllir VBRCatalog möppuna af þessari þekkingu. Það er aðeins notað þar sem gátreiturinn fyrir flokkun er virkur. Og það er aðeins skynsamlegt að virkja það ef þú ert með Enterprise Manager. Því ráð frá hjarta mínu: ekki kveikja bara á verðtryggingu ef þú borðar ekki. Sparaðu taugarnar þínar og stuðning tíma.
Einnig frá annarri mikilvægri þjónustu er vert að taka fram Veeam uppsetningarþjónusta, með hjálp sem nauðsynlegir íhlutir eru afhentir og settir upp á umboð, geymslur og aðrar hliðar. Reyndar tekur það nauðsynlega .msi pakka á netþjónana og setur þá upp.
Veeam Data Mover - með hjálp aðstoðarumboðsmanna sem settir eru af stað á umboðsmenn (en ekki aðeins) tekur það þátt í að breyta gögnum. Til dæmis, þegar afritað er, mun einn umboðsmaður lesa skrár úr hýsingargagnageymslunni og sá seinni skrifar þær vandlega í öryggisafritið.
Sérstaklega vil ég benda á mikilvægan hlut sem viðskiptavinir bregðast oft við - þetta er munurinn á útgáfum af þjónustu og upplýsingum í forritum og eiginleikum snap-in. Já, listinn verður sá sami, en útgáfurnar geta verið algjörlega misjafnar. Það er ekki mjög flott sjónrænt séð, en það er alveg eðlilegt ef allt virkar stöðugt. Til dæmis, fyrir uppsetningarþjónustuna, er útgáfunúmerið langt á eftir nágrannanum. Hryllingur og martröð? Nei, vegna þess að það er ekki alveg sett upp aftur, en DLL þess er einfaldlega uppfært. Í plástri v9.5 U4 átti sér stað martröð fyrir tækniaðstoð: við uppfærsluna fengu allar þjónustur nýjar útgáfur, nema sú mikilvægasta. Í U4b plástrinum fór flutningaþjónustan fram úr öllum hinum um allt að tvær útgáfur (af tölunum að dæma). Og þetta er líka eðlilegt - alvarleg villa fannst í því, svo það fékk bónusuppfærslu miðað við restina. Svo til að draga það saman: útgáfumunur GÆTTI verið vandamál, en ef það er munur og allt virkar rétt, þá ætti það líklega að vera það. En enginn bannar þér að skýra þetta í tæknilegri aðstoð.
Þetta voru svokölluð skyldu- eða skylduþjónusta. Og það er fullt af aukahlutum, svo sem Spóluþjónustu, Mount Service, vPowerNFS Service og svo framvegis.
Fyrir Hyper-V, almennt, er allt eins, aðeins það er sérstakt Veeam Backup Hyper-V samþættingarþjónusta og þinn eigin bílstjóri fyrir að vinna með CBT.
Og í lokin skulum við tala um hver vinnur á sýndarvélum við öryggisafrit. Til að keyra forskriftir fyrir og eftir frystingu, búa til skuggaafrit, safna lýsigögnum, vinna með SQL viðskiptaskrár o.s.frv. Veeam gestahjálpari. Og ef skráarkerfi eru verðtryggð, Veeam Guest Indexer . Þetta er tímabundin þjónusta sem notuð er á meðan öryggisafritið stendur yfir og fjarlægð eftir hana.
Þegar um er að ræða Linux vélar er allt miklu einfaldara vegna tilvistar fjölda innbyggðra bókasöfna og getu kerfisins sjálfs. Til dæmis er verðtrygging gerð í gegnum mlocate.
Það er allt í bili
Ég þori ekki að særa þig lengur stutt Ég tel kynningu á Veeam vélarrýminu lokið. Já, við höfum ekki einu sinni komið nálægt þéttunum sjálfum, en trúðu mér, svo að upplýsingarnar sem fram koma í þeim virðast ekki vera ósamstæður vitundarstraumur, slík kynning er algjörlega nauðsynleg. Ég ætla að fara aðeins í annálana sjálfa í þriðju greininni og áætlunin fyrir þá næstu er að útskýra hver býr til logana, hvað nákvæmlega birtist í þeim og hvers vegna nákvæmlega, en ekki annað.
Heimild: www.habr.com