Komponentët dhe Fjalori i Veeam Log Diving

Komponentët dhe Fjalori i Veeam Log Diving

Ne në Veeam i duam regjistrat. Dhe meqenëse shumica e zgjidhjeve tona janë modulare, ato shkruajnë shumë regjistra. Dhe meqenëse qëllimi i aktivitetit tonë është të garantojmë sigurinë e të dhënave tuaja (d.m.th., gjumë të qetë), atëherë regjistrat jo vetëm që duhet të regjistrojnë çdo teshtitje, por edhe ta bëjnë atë në disa detaje. Kjo është e nevojshme që në rast të diçkaje të jetë e qartë se si ndodhi kjo "çfarë", kush është fajtor dhe çfarë duhet bërë më pas. Është si në shkencën e mjekësisë ligjore: kurrë nuk e dini se çfarë gjëje e vogël do t'ju ndihmojë të gjeni vrasësin e Laura Palmer.

Prandaj, vendosa të bëj një lëkundje në një seri artikujsh, ku do të flas në vazhdimësi për atë që shkruajmë në regjistrat, ku i ruajmë, si të mos çmendemi me strukturën e tyre dhe çfarë të kërkojmë brenda tyre.

Pse një seri artikujsh dhe pse të mos përshkruani gjithçka menjëherë?

Thjesht renditja se cili regjistër është ku dhe çfarë ruhet në të është një ndërmarrje mjaft katastrofike. Dhe është e frikshme të mendosh edhe për mbajtjen e këtij informacioni të përditësuar. Një listë e thjeshtë e të gjitha llojeve të mundshme të regjistrave në Veeam Backup & Replication është një tabelë në disa fletë me shkronja të vogla. Po, dhe do të jetë e rëndësishme vetëm në kohën e publikimit, sepse. kur të lëshohet patch-i tjetër, mund të shfaqen regjistra të rinj, logjika e informacionit të ruajtur në të vjetrat do të ndryshojë, etj. Prandaj, do të jetë shumë më fitimprurëse të shpjegohet struktura e tyre dhe thelbi i informacionit që përmbahet në to. Kjo do t'ju lejojë të lundroni më mirë në vendet sesa grumbullimi banal i emrave.

Prandaj, për të mos nxituar me kokë në grupin e fletëve të tekstit, le të bëjmë disa punë përgatitore në këtë artikull. Prandaj, sot nuk do të futemi në vetë regjistrat, por do të shkojmë nga larg: do të përpilojmë një fjalor dhe do të diskutojmë pak strukturën Veeam për sa i përket gjenerimit të regjistrave.

Fjalori dhe zhargoni

Këtu, para së gjithash, ia vlen t'u kërkojmë falje kampionëve të pastërtisë së gjuhës ruse dhe dëshmitarëve të fjalorit të Ozhegov. Ne të gjithë e duam shumë gjuhën tonë amtare, por industria e mallkuar e IT-së funksionon në anglisht. Epo, ne nuk e kemi menduar, por ka ndodhur historikisht. Nuk është faji im, ai erdhi vetë (c)

Në biznesin tonë, problemi i anglicizmave (dhe zhargonit) ka specifikat e veta. Kur me fjalë të pafajshme si "mikpritës" ose "mysafir" e gjithë bota ka kuptuar prej kohësh gjëra shumë specifike, atëherë në ⅙ të tokës, konfuzioni heroik dhe tronditja me futjen në fjalorë vazhdon. Dhe argumenti rreptësisht i detyrueshëm "Por në punën tonë ...".

Plus, ekziston thjesht terminologjia jonë, e cila është e natyrshme në produktet Veeam, megjithëse disa fjalë dhe fraza u kanë shkuar njerëzve. Prandaj, tani do të biem dakord se çfarë do të thotë termi, dhe në të ardhmen, nën fjalën "mysafir", do të nënkuptoj saktësisht atë që shkruhet në këtë kapitull, dhe jo atë që jeni mësuar në punë. Dhe po, kjo nuk është teka ime personale, këto janë terma të vendosura mirë në industri. Luftimi i tyre është disi i pakuptimtë. Edhe pse unë jam gjithmonë në favor të qetësimit në komente.

Fatkeqësisht, ka shumë terma në punën dhe produktet tona, kështu që nuk do të përpiqem t'i rendit të gjitha. Vetëm informacioni më bazë dhe i nevojshëm në lidhje me kopjet rezervë dhe shkrimet për mbijetesë në det. Per te interesuarit mundem edhe une sugjeroni një artikull kolegët për kaseta, ku dha edhe një listë termash që lidhen me atë pjesë të funksionalitetit.

Pritësi (Host): Në botën e virtualizimit, kjo është një makinë me një hipervizor. Fizike, virtuale, re - nuk ka rëndësi. Nëse diçka po ekzekuton një hipervizor (ESXi, Hyper-V, KVM etj), atëherë kjo "diçka" quhet host. Qoftë nëse është një grup me dhjetë rafte ose laptopi juaj me një laborator për një makinë e gjysmë virtuale - nëse hapni një hipervizor, do të bëheshit host. Sepse hipervizori pret makina virtuale. Ekziston madje një histori që VMware në një kohë donte të arrinte një lidhje të fortë të fjalës host me ESXi. Por ajo nuk e bëri.

Në botën moderne, koncepti i "host" praktikisht është shkrirë me konceptin "server", i cili sjell një farë konfuzioni në komunikim, veçanërisht kur bëhet fjalë për infrastrukturën Windows. Pra, çdo makinë që pret ndonjë shërbim me interes për ne mund të quhet në mënyrë të sigurtë një host. Për shembull, në regjistrat e WinSock çdo gjë shënohet me fjalën host. Klasik "Host nuk u gjet" është një shembull i kësaj. Pra, ne fillojmë nga konteksti, por mbani mend - në botën e virtualizimit, një host është ai që pret mysafirët (më shumë për këtë në dy rreshta më poshtë).

Nga zhargoni lokal (përkundrazi edhe akronime, në këtë rast), kujtohet këtu se VMware është VI, vSphere është VC dhe Hyper-V është HV.

I ftuar (i ftuar): Makina virtuale që funksionon në host. Nuk ka asgjë për të shpjeguar këtu, gjithçka është kaq logjike dhe e thjeshtë. Megjithatë, shumë me zell tërheqin këtu disa kuptime të tjera.

Per cfare? Une nuk e di.
Guest OS, përkatësisht, sistemi operativ i makinës mysafir. Dhe kështu me radhë.

Punë rezervë/përsëritjeje (jobA): Zhargoni i pastër Wim, që tregon disa nga detyrat. Punë rezervë == Punë rezervë. Askush nuk e ka kuptuar se si ta përkthejë bukur në rusisht, kështu që të gjithë thonë "JobA". Me theks në rrokjen e fundit.

Po, thjesht e marrin dhe thonë “joba”. Dhe madje edhe në letra ata shkruajnë kështu, dhe gjithçka është në rregull.
Të gjitha llojet e punëve rezervë, detyra rezervë, etj., faleminderit, por nuk ka nevojë. Vetëm një punë dhe do të kuptohesh. Gjëja kryesore është të vendosni theksin në rrokjen e fundit.

Rezervimi (Rezervimi, rezervimi. Për true-oldfags, rezervimi lejohet): Përveç të dukshmes (një kopje rezervë e të dhënave që shtrihet diku), nënkupton edhe vetë punën (tre rreshta më lart, nëse e keni harruar tashmë), si rezultat i së cilës shfaqet vetë skedari rezervë. Ndoshta, zotërinj folësit e gjuhës amtare angleze janë shumë dembelë për të thënë se unë e kam drejtuar punën time rezervë çdo herë, kështu që ata thjesht thonë se kam ekzekutuar kopjen time rezervë dhe të gjithë e kuptojnë njëri-tjetrin në mënyrë perfekte. Ju ftoj të mbështesni këtë nismë të mrekullueshme.

Konsolidimi (Konsolidimi): Një term që u shfaq në ESXi 5.0 Një opsion në menynë e fotografive që fillon procesin e fshirjes së të ashtuquajturave fotografi jetime. Kjo do të thotë, fotografi që janë fizikisht të disponueshme, por kanë dalë jashtë strukturës logjike të shfaqur. Teorikisht, ky proces nuk duhet të ndikojë në skedarët e shfaqur në menaxherin e fotografive, por gjithçka mund të ndodhë. Thelbi i procesit të konsolidimit është që të dhënat nga fotografia (disku i fëmijës) të shkruhen në diskun kryesor (prind). Procesi i kombinimit të disqeve quhet bashkim. Nëse është lëshuar një komandë konsolidimi, atëherë regjistrimi i fotografisë mund të hiqet nga baza e të dhënave përpara se fotografia e çastit të bashkohet dhe fshihet. Dhe nëse fotografia nuk mund të fshihej për ndonjë arsye, atëherë shfaqen të njëjtat fotografi jetimë. Në lidhje me punën me fotografitë e çastit, VMware ka KB e mirë. Dhe ne gjithashtu disi rreth tyre shkroi në Habré.

Magazina e të dhënave (Stora ose ruajtja):  Një koncept shumë i gjerë, por në botën e virtualizimit, kuptohet si një vend ku ruhen skedarët e makinës virtuale. Por në çdo rast, këtu ju duhet të kuptoni shumë qartë kontekstin dhe, me dyshimin më të vogël, të sqaroni se çfarë saktësisht kishte në mendje bashkëbiseduesi juaj. 

Proxy (Proxy): Është e rëndësishme të kuptohet menjëherë se Veeam Proxy nuk është plotësisht i njëjtë me atë që jemi mësuar në internet. Brenda produkteve Veeam, ky është një lloj entiteti që merret me transferimin e të dhënave nga një vend në tjetrin. Nëse nuk hyni në detaje, atëherë VBR është një server komandimi dhe kontrolli, dhe proxies janë shtylla e tij e punës. Kjo do të thotë, një përfaqësues është një makinë përmes së cilës rrjedh trafiku dhe në të cilën janë instaluar komponentë VBR që ndihmojnë në drejtimin e këtij trafiku. Për shembull, për të transferuar të dhëna nga një kanal në tjetrin, ose thjesht për të kapur disqet pas vetes (modaliteti HotAdd).

Depoja (depo):  Teknikisht, kjo është vetëm një hyrje në bazën e të dhënave VBR, që tregon vendin ku ruhen kopjet rezervë dhe si të lidheni me këtë vend. Në fakt, mund të jetë ose thjesht një top CIFS ose një disk, server ose kovë e veçantë në re. Përsëri, ne jemi në kontekst, por ne e kuptojmë se një depo është thjesht një vend ku janë rezervat tuaja.

 Foto e çastit (SnapshOt): Adhuruesit e gramatikës së Oksfordit preferojnë të thonë se kush është fotografi e çastit dhe kush është fotografi, por shumica analfabete përfitojnë nga masa më e madhe. Nëse dikush nuk e di, kjo është një teknologji që ju lejon të rivendosni gjendjen e një disku në një moment të caktuar kohor. Kjo bëhet ose duke ridrejtuar përkohësisht operacionet I/O larg nga disku kryesor - më pas do të quhet RoW (Redirect on Write) foto - ose duke lëvizur blloqe të rishkruash nga disku juaj në një tjetër - kjo do të quhet CoW (Kopjo në Shkrim ) fotografi. Falë mundësive të gjera për përdorimin e këtyre funksioneve, Veeam mund të bëjë magjinë e tij rezervë. Me fjalë të rrepta, jo vetëm ata, por kjo është çështja e publikimeve të radhës.

Ka kaos rreth këtij termi në dokumentacionin dhe regjistrat e ESXi, dhe në kontekstin e përmendjes së fotografive të çastit, mund të gjeni vetë fotografitë e çastit, dhe të ribërni regjistrin, madje edhe diskun delta. Dokumentacioni Veeam nuk përmban një grisje të tillë, dhe një fotografi është një fotografi e çastit dhe një regjistër i ribërjes është pikërisht një skedar REDO i krijuar nga një disk i pavarur jo i qëndrueshëm. Skedarët REDO fshihen kur makina virtuale është e fikur, kështu që ngatërrimi i tyre me fotografitë e çastit është një rrugë drejt dështimit.

Sintetike (Sintetike): Rezervimet sintetike janë kopje rezervë në rritje të kundërt dhe përgjithmonë përpara. Në rast se nuk e keni hasur këtë term, është vetëm një nga mekanizmat e përdorur për të ndërtuar një transformim të zinxhirit rezervë. Sidoqoftë, në regjistra mund të gjeni edhe konceptin e Transformimit, i cili përdoret në kuadrin e krijimit të kopjeve të plota nga inkrementet (plot sintetik).

Detyrë (Detyrë): Ky është procesi i përpunimit të secilës makinë individuale brenda punës. Kjo është: ju keni një punë rezervë, e cila përfshin tre makina. Kjo do të thotë se çdo makinë do të përpunohet si pjesë e një detyre të veçantë. Në total, do të ketë katër regjistra: kryesori për punë dhe tre për detyra. Sidoqoftë, këtu ka një nuancë të rëndësishme: me kalimin e kohës, fjala "detyrë" është bërë e paqartë e panevojshme. Kur flasim për regjistrat e përgjithshëm, nënkuptojmë që një detyrë është pikërisht një VM. Por ka "detyra" si në përfaqësues ashtu edhe në depo. Atje mund të nënkuptojë një disk virtual, një makinë virtuale dhe të gjithë punën. Kjo do të thotë, është e rëndësishme të mos humbasësh kontekstin.

Veeam %name% Shërbimi:  Për përfitimin e kopjeve rezervë të suksesshme, disa shërbime funksionojnë menjëherë, një listë e të cilave mund të gjendet në pajisjet standarde. Emrat e tyre pasqyrojnë në mënyrë mjaft transparente thelbin e tyre, por midis të barabartëve ekziston më e rëndësishmja - Veeam Backup Service, pa të cilin pjesa tjetër nuk do të funksionojë.

VSS: Teknikisht, VSS duhet të qëndrojë gjithmonë për Microsoft Volume Shadow Copy Service. Në fakt, ai përdoret nga shumë njerëz si sinonim për Përpunimin e Imazhit në Application-Aware. E cila, natyrisht, është kategorikisht e gabuar, por kjo është një histori nga kategoria "Çdo SUV mund të quhet xhip dhe do të kuptohesh".

Shkrime fantastike dhe ku jetojnë

Dua ta filloj këtë kapitull duke zbuluar sekretin e madh - sa ora shfaqet në regjistra?

Mbani mend:

  • ESXi gjithmonë shkruan regjistrat në UTC+0.
  • vCenter mban regjistrat sipas kohës së zonës së saj kohore.
  • Veeam mban regjistrat sipas kohës dhe zonës kohore të serverit në të cilin është.
  • Dhe vetëm ngjarjet e Windows në formatin EVTX nuk vuajnë nga detyrimi për asgjë. Kur hapen, koha rillogaritet për makinën në të cilën janë hapur. Opsioni më i përshtatshëm, megjithëse ka vështirësi me të. Vështirësia e vetme e prekshme është ndryshimi në vendndodhje. Kjo është një rrugë praktikisht e garantuar drejt regjistrave të palexueshëm. Po, ka opsione se si ta trajtojmë këtë, por le të mos debatojmë me faktin se gjithçka në IT funksionon në anglisht dhe bien dakord që gjithmonë të vendosni vendndodhjen angleze në serverë. Oh te lutem. 

Tani le të flasim për vendet ku jetojnë shkrimet dhe si t'i marrim ato. Në rastin e VBR, ekzistojnë dy qasje. 

Opsioni i parë është i përshtatshëm nëse nuk jeni të etur të kërkoni skedarë në grumbullin e përgjithshëm që lidhen posaçërisht me problemet tuaja. Për ta bërë këtë, ne kemi një magjistar të veçantë, në të cilin mund të specifikoni një punë specifike dhe një periudhë specifike për të cilën keni nevojë për regjistra. Pastaj ai do të kalojë vetë dosjet dhe do të vendosë gjithçka që ju nevojitet në një arkiv. Ku ta kërkoni dhe si të punoni me të përshkruhet në detaje në kjo HF.

Sidoqoftë, magjistari nuk mbledh regjistrat e të gjitha detyrave dhe, për shembull, nëse keni nevojë të studioni regjistrat e restauruesit, dështimin ose dështimin, rruga juaj qëndron në dosje %ProgramData%/Veeam/Backup. Ky është dyqani kryesor i logos VBR dhe %ProgramData% është një dosje e fshehur dhe kjo është në rregull. Meqë ra fjala, vendndodhja e paracaktuar mund të ricaktohet duke përdorur çelësin e regjistrit të tipit REG_SZ: LogDirectory në degën HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.

Në makinat Linux, regjistrat e agjentëve të punëtorëve duhet të kërkohen në /var/log/VeeamBackup/nëse përdorni një llogari rrënjë ose sudo. Nëse nuk keni privilegje të tilla, atëherë kërkoni hyrje /tmp/VeeamBackup

Për agjentin Veeam për %OS_name% regjistrat duhet të kërkohen %ProgramData%/Veeam/Endpoint (Ose %ProgramData%/Veeam/Backup/Endpoint) Dhe /var/log/veeam respektivisht.

Nëse jeni duke përdorur Application-Aware Image Processing (dhe ka shumë të ngjarë që po), atëherë situata bëhet disi më e ndërlikuar. Do t'ju duhen regjistrat e ndihmësit tonë, të cilat ruhen brenda vetë makinës virtuale, dhe regjistrat VSS. Për mënyrën dhe ku ta merrni këtë lumturi, është shkruar në detaje në Ky artikull. Dhe sigurisht që ka artikull i veçantë për të mbledhur regjistrat e nevojshëm të sistemit. 

Ngjarjet e Windows mblidhen në mënyrë të përshtatshme sipas kjo HF. Nëse jeni duke përdorur Hyper-V, gjërat bëhen më të ndërlikuara, pasi do t'ju nevojiten gjithashtu të gjitha regjistrat e tij nga aplikacionet dhe regjistrat e shërbimit > Microsoft > dega Windows. Edhe pse gjithmonë mund të shkoni në rrugën më budallaqe dhe thjesht të merrni të gjitha objektet nga %SystemRoot%System32winevtLogs.

Nëse diçka prishet gjatë instalimit/përmirësimit, atëherë gjithçka që ju nevojitet mund të gjendet në dosjen %ProgramData%/Veeam/Setup/Temp. Megjithëse nuk do ta fsheh faktin që në ngjarjet e OS mund të gjeni më shumë informacione të dobishme sesa në këto regjistra. Pjesa tjetër e interesit qëndron në %Temp%, por ka kryesisht regjistra instalimi për softuer të lidhur, si baza, bibliotekat .Net dhe gjëra të tjera. Vini re se Veeam është instaluar nga msi dhe të gjithë përbërësit e tij janë instaluar gjithashtu si paketa të veçanta msi, edhe nëse kjo nuk është shfaqur në GUI. Prandaj, nëse instalimi i njërit prej komponentëve dështon, i gjithë instalimi VBR do të ndalet. Prandaj, duhet të futeni në regjistrat dhe të shihni se çfarë u prish saktësisht dhe në cilën pikë.

Dhe së fundi, një hak jetësor: nëse merrni një gabim gjatë instalimit, mos nxitoni të klikoni OK. Fillimisht marrim regjistrat, pastaj klikojmë OK. Në këtë mënyrë ju do të merrni një regjistër që përfundon në momentin e gabimit, pa mbeturina në fund.

Dhe ndodh që ju duhet të futeni në regjistrat e vSphere. Okupimi është shumë mosmirënjohës, por, duke përveshur mëngët, duhet bërë diçka tjetër. Në versionin më të thjeshtë, na duhen regjistrat me ngjarjet e makinës virtuale vmware.log, të cilat ndodhen pranë skedarit të tij .vmx. Në një rast më të vështirë, hapni Google dhe pyesni se ku ndodhen regjistrat për versionin tuaj të hostit, pasi VMware pëlqen ta ndryshojë këtë vend nga lëshimi në lëshim. Për shembull, artikull për 7.0, por për 5.5. Për regjistrat e vCenter, përsëritni procedurën googling. Por në përgjithësi, ne do të jemi të interesuar për regjistrat e ngjarjeve të hostit hostd.log, ngjarjet pritëse të menaxhuara nga vCenter vpxa.log, regjistrat e kernelit vmkernel.log dhe regjistrat e vërtetimit auth.log. Epo, në rastet më të neglizhuara, regjistri SSO, i cili ndodhet në dosjen SSO, mund të jetë i dobishëm.

I rëndë? Të hutuar? E frikshme? Por kjo nuk është as gjysma e informacionit me të cilin mbështetja jonë punon në baza ditore. Pra, ata janë vërtet, shumë të lezetshëm.

Komponentët Veeam

Dhe si përfundim i këtij artikulli hyrës, le të flasim pak për komponentët e Veeam Backup & Replication. Sepse kur kërkoni shkakun e dhimbjes, do të ishte mirë të kuptoni se si funksionon pacienti.

Pra, siç e dinë të gjithë, Veeam Backup është një aplikacion i ashtuquajtur i bazuar në SQL. Kjo do të thotë, të gjitha cilësimet, të gjitha informacionet dhe në përgjithësi gjithçka që është e nevojshme vetëm për funksionimin normal - e gjithë kjo është në bazën e të dhënave të saj. Ose më mirë, në dy baza të të dhënave, nëse po flasim për një grup VBR dhe EM: VeeamBackup dhe VeeamBackupReporting, respektivisht. Dhe kështu ndodhi: vendosëm një aplikacion tjetër - shfaqet një bazë tjetër e të dhënave. Për të mos ruajtur të gjitha vezët në një shportë.

Por që e gjithë kjo ekonomi të funksionojë pa probleme, ne kemi nevojë për një sërë shërbimesh dhe aplikacionesh që do të lidhin të gjithë komponentët së bashku. Vetëm si shembull, kjo është se si duket në një nga laboratorët e mi:

Komponentët dhe Fjalori i Veeam Log Diving
Vepron si kryedirigjent Shërbimi rezervë Veeam. Është ai që është përgjegjës për shkëmbimin e informacionit me bazat. Ai është gjithashtu përgjegjës për fillimin e të gjitha detyrave, orkestrimin e burimeve të alokuara dhe punën si një lloj qendre komunikimi për një sërë konzolash, agjentësh dhe gjithçka tjetër. Me një fjalë, definitivisht nuk ka asnjë mënyrë pa të, por kjo nuk do të thotë aspak se ai bën gjithçka vetë.

E ndihmon atë në përmbushjen e planit të tij Veeam Backup Manager. Ky nuk është një shërbim, por një subjekt që hap punë dhe monitoron procesin e ekzekutimit të tyre. Duart e punës të shërbimit rezervë, me të cilat lidhet me hostet, krijon fotografi, monitoron mbajtjen, etj.

Por përsëri në listën e shërbimeve. Shërbimi i ndërmjetësit Veeam. U shfaq në v9.5 (dhe ky nuk është një minator i kriptove, siç menduan disa atëherë). Mbledh informacione rreth hosteve të VMware dhe ruan rëndësinë e tij. Por mos vraponi menjëherë të shkruani komente të zemëruara se ne po ju spiunojmë dhe po ju nxjerrim të gjitha hyrjet / fjalëkalimet te taschmajor. Gjithçka është disi më e thjeshtë. Kur kryeni një kopje rezervë, gjëja e parë që duhet të bëni është të lidheni me hostin dhe të përditësoni të gjitha të dhënat rreth strukturës së tij. Kjo është një histori mjaft e ngadaltë dhe e rëndë. Vetëm mbani mend se sa kohë ju duhet për t'u identifikuar përmes ndërfaqes së internetit dhe mbani mend se aty llogaritet vetëm shtresa e sipërme. Dhe pastaj ju ende duhet të hapni të gjithë hierarkinë në vendin e duhur, meqë ra fjala. Me një fjalë, tmerr. Nëse keni një duzinë kopje rezervë, atëherë çdo punë duhet ta bëjë këtë procedurë. Nëse po flasim për infrastruktura të mëdha, atëherë ky proces mund të zgjasë dhjetë minuta ose më shumë. Prandaj, u vendos që për këtë të ndahet një shërbim i veçantë, përmes të cilit do të mundësohet marrja e informacionit gjithmonë të përditësuar. Në fillim, ai kontrollon dhe skanon të gjithë infrastrukturën e shtuar, dhe më pas përpiqet të funksionojë vetëm në nivelin e ndryshimeve në rritje. Pra, edhe nëse kryeni njëqind kopje rezervë në të njëjtën kohë, ata të gjithë do të kërkojnë informacion nga ndërmjetësi ynë dhe nuk do t'i mundojnë hostet me kërkesat e tyre. Nëse jeni të shqetësuar për burimet, atëherë sipas llogaritjeve tona, 5000 makina virtuale kanë nevojë për vetëm rreth 100 Mb memorie.

Tjetra kemi Konsola Veeam. Ai është Veeam Remote Console, ai është Veeam.Backup.Shell. Ky është i njëjti GUI që shohim në pamjet e ekranit. Gjithçka është e thjeshtë dhe e dukshme - tastiera mund të lëshohet nga kudo, për sa kohë që është Windows dhe ka një lidhje me serverin VBR. E vetmja gjë që mund të thuhet është se procesi FLR do të montojë pikat në nivel lokal (d.m.th. në makinën ku funksionon konsola). Epo, eksploruesit e ndryshëm të Veeam do të funksionojnë gjithashtu në nivel lokal, sepse ato janë pjesë e tastierës. Por ajo tashmë më ka çuar në të egra ...

Një tjetër shërbim interesant është Shërbimi i të dhënave të Katalogut Rezervues Veeam. I njohur si Shërbimi i Katalogut të Vizitorëve Veeam në listën e shërbimeve. Ai është i angazhuar në indeksimin e sistemeve të skedarëve në makinat e ftuar dhe mbush dosjen VBRCatalog me këtë njohuri. Përdoret vetëm kur kutia e kontrollit të indeksimit është e aktivizuar. Dhe ka kuptim ta aktivizoni atë vetëm nëse keni Menaxher të Ndërmarrjes. Prandaj, këshilla nga thellësia e zemrës sime: mos e aktivizoni indeksimin ashtu sikur nuk keni EAT. Kurseni nervat dhe kohën e mbështetjes.

Gjithashtu nga shërbime të tjera të rëndësishme vlen të përmendet Shërbimi i instaluesit Veeam, me ndihmën e të cilit dorëzohen dhe instalohen komponentët e nevojshëm në proxies, depo dhe porta të tjera. Në fakt, ajo merr paketat e nevojshme .msi në serverë dhe i instalon ato. 

Lëvizës i të dhënave Veeam - me ndihmën e agjentëve ndihmës të lëshuar në proxy (dhe jo vetëm) është i angazhuar në zhvendosjen e të dhënave. Për shembull, kur krijoni kopje rezervë, një agjent do të lexojë skedarë nga dyqani i të dhënave të hostit dhe i dyti do t'i shkruajë me kujdes ato në rezervë.

Më vete, do të doja të shënoja një gjë të rëndësishme për të cilën klientët reagojnë shpesh - ky është ndryshimi në versionet e shërbimeve dhe informacionit në snap-in e Programeve dhe Veçorive. Po, lista do të jetë e njëjtë, por versionet mund të jenë krejtësisht të papajtueshme. Nuk është shumë e lezetshme nga pikëpamja vizuale, por është krejtësisht normale nëse gjithçka funksionon në mënyrë të qëndrueshme. Për shembull, për shërbimin Installer, numri i versionit është shumë prapa atyre fqinjë. Tmerr dhe makth? Jo, sepse nuk është riinstaluar plotësisht, por DLL-ja e tij thjesht përditësohet. Në patch v9.5 U4, ndodhi një makth i mbështetjes teknike: gjatë përditësimit, të gjitha shërbimet morën versione të reja, përveç atij më të rëndësishëm. Në patch-in U4b, shërbimi i transportit i kapërceu të gjithë të tjerët me sa dy versione (duke gjykuar nga numrat). Dhe kjo është gjithashtu normale - u gjet një gabim serioz në të, kështu që mori një përditësim bonus në lidhje me pjesën tjetër. Pra, për ta përmbledhur: dallimet e versioneve MUND të jenë një problem, por nëse ka një ndryshim dhe gjithçka po funksionon siç duhet, atëherë ndoshta duhet të jetë. Por askush nuk ju ndalon ta sqaroni këtë në mbështetjen teknike.

Këto ishin të ashtuquajturat shërbime të detyrueshme ose të detyrueshme. Dhe ka një bandë të tërë ndihmëse, të tilla si Tape Service, Mount Service, vPowerNFS Service e kështu me radhë.

Për Hyper-V, në përgjithësi, gjithçka është e njëjtë, vetëm ka një specifikë Shërbimi i Integrimit të Veeam Backup Hyper-V dhe shoferin tuaj për të punuar me CBT.

Dhe në fund, le të flasim se kush punon në makinat virtuale gjatë kopjimit. Për të ekzekutuar skriptet para dhe pas ngrirjes, për të krijuar një kopje hije, për të mbledhur metadata, për të punuar me regjistrat e transaksioneve SQL, etj. Veeam Guest Helper. Dhe nëse sistemet e skedarëve janë të indeksuar, Veeam Guest Indexer . Këto janë shërbime të përkohshme të vendosura për kohëzgjatjen e rezervimit dhe të hequra pas tij.

Në rastin e makinave Linux, gjithçka është shumë më e thjeshtë për shkak të pranisë së një numri të madh bibliotekash të integruara dhe aftësive të vetë sistemit. Për shembull, indeksimi bëhet përmes mlocate.

Kjo është e gjitha për tani

Nuk guxoj të të lëndoj më i shkurtër Unë e konsideroj të mbaruar prezantimin në ndarjen e motorit Veeam. Po, as vetë strofkat nuk i jemi afruar, por më besoni, në mënyrë që informacioni i paraqitur në to të mos duket si një rrjedhë jokoherente e vetëdijes, një hyrje e tillë është absolutisht e nevojshme. Kam në plan të shkoj te vetë regjistrat vetëm në artikullin e tretë, dhe plani për artikullin tjetër është të shpjegoj se kush i gjeneron regjistrat, çfarë saktësisht shfaqet në to dhe pse saktësisht, dhe jo ndryshe.

Burimi: www.habr.com

Shto një koment