Ne në Veeam i duam logët. Dhe pasi shumica e zgjidhjeve tona janë modulare, ato shkruajnë mjaft logë. Dhe duke qenë se fusha jonë e veprimit është sigurimi i ruajtjes së të dhënave tuaja (dmth një gjumë të qetë), logët duhet të regjistrojnë jo vetëm çdo lëvizje, por ta bëjnë këtë në mënyrë të detajuar. Kjo është e nevojshme në mënyrë që, në rastin e ndonjë incidenti, të kuptohet si ndodhi ky incident, kush ishte përgjegjës dhe çfarë duhet të bëjmë më pas. Këtu është si në kriminalistikë: kurrë nuk e di se cila detaj do të të ndihmojë të gjesh vrasësin e Lora Palmer.
Prandaj, vendosa të nisin një seri artikujsh, ku do të tregoj sequentialisht se çfarë shkruajmë në logë, ku i ruajmë ato, si të mos çmendemi nga struktura e tyre dhe çfarë duhet të kërkojmë në to.
Pse seria e artikujve dhe pse jo ta përshkruajmë gjithçka njëherë?
Thjesht të përmendësh se ku ndodhen logët dhe çfarë përmbajnë ato është një përpjekje mjaft e vështirë. Dhe mbajtja e këtij informacioni të freskët është e frikshme. Një thjesht listim i të gjitha llojeve të mundshme të logëve në Veeam Backup & Replication është një tabelë që merr disa faqe me shkronja të vogla. Dhe do të jetë e vlefshme vetëm në momentin e publikimit, pasi me lëshimin e patch-it të ardhshëm mund të shfaqen logë të reja, logjika e informacionit të ruajtur në të vjetrit mund të ndryshojë, etj. Prandaj, shumë më e dobishme do të jetë të shpjegojmë strukturën e tyre dhe thelbin e informacionit që përmbajnë. Kjo do të lejojë që të orientohemi më mirë në terren sesa thjesht të memorizojmë emrat.
Prandaj, për të mos u hedhur me kokë në detin e fletëve të gjata tekstuale, le të bëjmë një punë përgatitore në këtë artikull. Prandaj, sot nuk do të hyjmë në vetë logët, por do të dalim nga larg: do të hartojmë një glosar dhe do të flasim pak për strukturën e Veeam nga këndvështrimi i gjenerimit të logëve.
Glosari dhe termat e argotës
Derihet së pari të kërkoj ndjesë para mbrojtësve të pastërtisë së gjuhës shqipe dhe dëshmitarëve të fjalorit të Ozhegov-it. Të gjithë ne e duam shumë gjuhën tonë të lindur, por industria e IT-së punon në anglisht. Ajo nuk është idea jonë, por kështu ka ndodhur historikisht. Nuk është faji im, ai vetë erdhi (c)
Në punën tonë, problemi i anglicizmave (dhe zhargoneve) ka specifikat e tij. Kur nën fjalët e pafajshme si "hosting" ose "mysafir", e gjithë bota gjithmonë e ka kuptuar një gjë krejt të veçantë, në ⅙ të tokës vazhdon një shpërndarje heroike dhe lëvizje me gisht në fjalorë. Dhe argumenti i patjetërsueshëm "E pra, te ne në punë...".
Përjashtova terminologjinë tonë, e cila është specifike për produktet Veeam, edhe pse disa fjalë dhe shprehje janë bërë të njohura. Prandaj tani do të biem dakord se çfarë do të thotë çdo term, dhe në të ardhmen nën fjalën "mysafir" do të kem parasysh atë që është shkruar në këtë kapitull, e jo atë që jeni mësuar në punën tuaj. Dhe po, kjo nuk është vetëm dëshira ime, janë terma të vendosur në industri. Të luftosh me to është paksa e pamundur. Megjithatë, nëse dëshiron të komentosh, unë gjithmonë jam për.
Fatkeq, numri i terminologjive në punën tonë dhe produkte është jashtëzakonisht i madh, kështu që nuk do të përpiqem t'i listoj të gjitha. Vetëm ato më themelore dhe të nevojshme për të mbijetuar në këtë det informacioni në lidhje me backup dhe log. Për ata që janë të interesuar, mund të nga kolegët mbi rrjetet, ku ai gjithashtu kishte përfshirë një listë terminologjish që lidhen me atë pjesë të funksionalitetit.
Host (Host): Në botën e virtualizimit, kjo është një makinë me hipervizor. Fizike, virtuale, në re — nuk ka rëndësi. Nëse mbi diçka është instaluar një hipervizor (ESXi, Hyper-V, KVM etj.), atëherë ky "diçka" quhet host. Qoftë një klaster me dhjetë racks ose laptopi juaj me një laborator për njëzetë virtualë — nëse keni nisur hipervizorin, atëherë jeni bërë host. Sepse hipervizori hoston makinat virtuale. Ka madje një histori, që VMware në një kohë do të përpiqej të arrinte një lidhje të fortë të fjalës host pikërisht me ESXi. Por nuk ia doli.
Në botën moderne, koncepti i "host" është praktikisht bashkuar me atë të "server", çka sjell disa keqkuptime në komunikim, sidomos kur bëhet fjalë për infrastrukturën Windows. Prandaj, çdo makinë që përmban ndonjë shërbim interesant për ne mund të quhet pa mëdyshje një host. Për shembull, në logjet e WinSock, fjala host shënon gjithçka. Një shembull klasik është "Host not found". Pra, të gjithëve duhet të mbajmë parasysh kontekstin, por të kujtojmë – në botën e virtualizimit, host është ajo që hoston mysafirët (për këtë do flasim në rreshta dy më poshtë).
Nga gjargonet lokale (më shumë se akronime, në këtë rast) na vjen ndërmend se VMware është VI, vSphere është VC, dhe Hyper-V është HV.
Guest (Mysafir): Një makinë virtuale e cila punon në host. Këtu nuk ka asgjë për të shpjeguar, aq logjike dhe e thjeshtë është. Sidoqoftë, shumë përpiqen t'i japin këtu kuptime të tjera.
Përse? Nuk e di.
Guest OS, përkatësisht, është sistemi operativ i makinës mysafire. Dhe kështu me radhë.
Backup/Replication Job (djobA): Një gjargon krejtësisht VMware, që përfaqëson një nga detyrat. Backup job == DjobA e Bekaupit. Si e përkthejmë këtë në shqip — askush nuk ka arritur ta gjejë një shprehje të bukur, kështu që të gjithë thonë "djobA", me theksin në sillin e fundit.
Po, kështu thjesht e marrin dhe thonë "job". Edhe në letra kështu shkruajnë, dhe gjithçka është në rregull.
Çdo lloj punimesh për backup, detyrat e backup-it etj., faleminderit, por nuk është nevojshme. Thjesht job, dhe do t'ju kuptojnë. E rëndësishmja është të vendosni theksin në sillin e fundit.
Backup (Bëkap, bëkap. Për të vërtetët e vjetër, lejohet bakUp): Përveç asaj që është e dukshme (një kopje rezervë e dhënave diku), do të thotë gjithashtu vetë job-in (tre rreshta lart, nëse e keni harruar), si rezultat i së cilës krijohet ai skedari bëkap. Me sa duket, zotërinj anglishtfolës janë shumë të lenë për të thënë gjithmonë I ran my backup job, prandaj ata thjesht thonë I ran my backup, dhe të gjithë kuptojnë njëri-tjetrin shumë mirë. Propozoj të mbështesim këtë iniciativë të mrekullueshme.
Consolidate (Konsolidim): Termi që u shfaq në ESXi 5.0 Opsioni në menunë e punës me snapshot-et, që aktivizon procesin e fshirjes të ashtuquajturave snapshot-e orphaned. Pra, snapshot-e të cilat fizikisht ekzistojnë, por kanë rënë nga struktura logjike e paraqitur. Teorikisht, ky proces nuk duhet të preki skedarët e paraqitur në menaxherin e snapshot-eve, megjithatë ndodhin edhe raste. Thelbi i procesit të konsolidimit është që të dhënat nga snapshot-i (disku fëmijë) shkruhen në diskun kryesor (disku prind). Procesi i bashkimit të disqeve quhet mërgimi (merge). Nëse është dhënë urdhri për konsolidim, atëherë informacioni mbi snapshot-in mund të fshihet nga baza më herët sesa snapshot-i të mërgohet dhe të fshihet. Dhe nëse snapshot-i nuk mund të fshihet për ndonjë arsye, atëherë shfaqen këto snapshot-e orphaned. Për punën me snapshot-et, VMware ka . Dhe ne gjithashtu një herë kemi .
Datastore (Shtesë ose magazinë): Një koncept shumë i gjerë, por në botën e virtualizimit nënkupton vendin ku ruhen skedarët e makinave virtuale. Megjithatë, është e rëndësishme të kuptohet qartë konteksti dhe në rast të dyshimeve të vogla të sqaroni se çfarë ka dashur të thotë biseduesi juaj.
Proxy (Përfaqësues): Është e rëndësishme të kuptohet se Veeam Proxy nuk është krejtësisht e njëjtë me atë që jemi mësuar në botën e internetit. Brenda produkteve të Veeam, kjo është një entitet që merret me transferimin e të dhënave nga një vend në tjetrin. Nëse nuk hyjmë në detaje, atëherë VBR është serveri komandon, ndërsa proksi është puna e tij. Pra, proksi është makina përmes së cilës kalon trafiku dhe për të cilën janë instaluar komponentët e VBR, të cilët ndihmojnë në menaxhimin e këtij trafiku. Për shembull, transmetimi i të dhënave nga një kanal në tjetrin ose thjesht lidhja e disqeve (HotAdd mode).
Repository (Repo): Në mënyrë teknike, kjo është thjesht një rekord në bazën e të dhënave VBR që tregon vendin ku ruhen kopjet rezerva dhe si të lidhemi me këtë vend. Në fakt, kjo mund të jetë një CIFS share e thjeshtë, një disk i veçantë, një server ose një bucket në re. Sërish, jemi në kontekst, por e kuptojmë që repo është thjesht vendi ku janë kopjet e rezerva.
Snapshot (Snapshot): Adhuruesit e gramatikës oksfordiane preferojnë të flasin për "snepshot" ose "snepshot", megjithatë shumica e paarsyetuar përfiton për shkak të numrit më të madh. Nëse dikush nuk e di - kjo është një teknologji që lejon rikthimin e gjendjes së diskut në një moment të caktuar. Kjo bëhet ose përmes ridrejtpërdrejtimit të operacioneve I/O nga disku kryesor - atëherë kjo do të quhet RoW (Redirect on Write) snapshot - ose duke transferuar bloket e ripërzgjidhura nga disku juaj në një tjetër - kjo do të quhet CoW (Copy on Write) snapshot. Falë mundësive të gjera për aplikimin e këtyre funksioneve, Veeam është në gjendje të kryejë magjinë e saj të backup-it. Rigorozisht, jo vetëm ata, por kjo është çështja e lëshimeve të afërta.
Në dokumentacionin dhe logjet e ESXi, përreth këtij termi ka kaos, dhe në kontekstin e përmendjes së snapshot-eve mund të hasni si snapshot-et, ashtu edhe redo log dhe madje edhe delta disk. Në dokumentacionin e Veeam nuk ka një kaos të tillë, dhe snapshot-i është një snapshot, ndërsa redo log është pikërisht skedari REDO, i krijuar nga një disk jo-përsëritës. Skedarët REDO fshihen kur makina virtuale mbyllet, kështu që të ngatërroni ata me snapshot-et është një rrugë për dështim.
Sintetike (Synthetic): Blegjet sintetike i përkasin bbackup-eve të rikthimit incremental dhe përjetshëm përpara. Nëse ndonjëherë nuk jeni përballur me këtë term, ai është thjesht një nga mekanizmat e përdorur për ndërtimin e shndërrimeve të zinxhirit të backup-it. Megjithatë, në log-e gjithashtu mund të hasni termin Transform, i cili përdoret në kuadër të krijimit të kopjeve të plota nga inkrementet (synthtetic full).
Task (Detyra): Ky është procesi i përpunimit të çdo makine të veçantë brenda një pune. Pra: nëse keni një punë backup-u, e cila përfshin tri makina. Kështu, secila makinë do të përpunojë në kuadër të një detyre të veçantë. Pra, do të ketë katër log-e: një kryesor për punën dhe tre për detyrat. Megjithatë, ka një nuancë të rëndësishme: me kalimin e kohës fjala "detyrë" është bërë tepër shumëznjohëse. Kur flasim për log-et e përgjithshme, nënkuptojmë se detyra është pikërisht VM. Por ka "detyra" edhe në proxy dhe në depo. Aty, kjo mund të nënkuptoj një disk virtual, një makinë virtuale, ose të gjithë punën. Pra, është e rëndësishme të mos humbasim kontekstin.
Shërbimi Veeam %name% (Shërbimi): Për të siguruar backup të suksesshëm punojnë disa shërbime, lista e të cilëve mund të gjendet në veglën standarde. Emrat e tyre zakonisht reflektuin qartazi thelbin e tyre, megjithatë midis të barabartëve ka një më të rëndësishëm – Veeam Backup Service, pa të cilin të tjerët nuk do të funksiononin.
VSS: Teknikisht VSS gjithmonë duhet të përfaqësojë Microsoft Volume Shadow Copy Service. Në fakt, përdoret nga shumë si sinonim për Application-Aware Image Processing. Çfarë, sigurisht, është kategorikisht e gabuar, megjithatë kjo është një histori nga ai grup i thënieve ‘Çdo SUV mund të quhet Jeep, dhe do të të kuptonë’.
Të jashtëzakonshmet log dhe vendet ku ata ndodhen
Dua të filloj këtë kapitull duke zbuluar një sekret të madh – çfarë koha shfaqet në log?
Merrni parasysh:
- ESXi gjithmonë shkruan log në UTC+0.
- vCenter mban log sipas kohës së zonës së tij.
- Veeam mban log sipas kohës dhe zonës së serverit ku ndodhet.
- Dhe vetëm ngjarjet në formatin EVTX për Windows nuk janë të lidhura me asgjë. Kur hapen, koha ricaktohet për makinën në të cilën hapen. E vetmja mundësi e përshtatshme, megjithatë ndodhin vështirësi edhe me të. Vështirësia e vetme e dukshme është diferenca e lokaleve. Kjo është një rrugë pothuajse e garantuar për logje të pamundura për t'u lexuar. Po, ka mundësi për ta trajtuar, por le të mos diskutojmë se gjithçka në IT funksionon në anglisht dhe të bien dakord që gjithmonë të vendosim lokalitetin anglisht në serverë. Të lutem.
Tani le të flasim për vendet ku jetojnë logjet dhe si t'i marrim ato. Në rastin e VBR, ka dy qasje.
Opsioni i parë është i përshtatshëm nëse nuk keni dëshirë të kërkoni në një grumbull të përgjithshëm skedarët që lidhen me problemin tuaj. Për këtë kemi një wizard të veçantë, i cili mund t'i tregoni një punë specifike dhe një periudhë specifike për të cilën ju duhen logjet. Më pas ai do të kalojë vetë nëpër dosje dhe do të mbledhë gjithçka të nevojshme në një arkiv. Për atë ku ta kërkoni dhe si të punoni me të, është shkruar hollësisht në .
Megjithatë, wizard-i mbledh logjet e të gjitha detyrave dhe, për shembull, në rast se është e nevojshme të studiohen logjet e restoranteve, dështimeve ose rikthimeve, rruga juaj është në folderin %ProgramData%/Veeam/Backup. Ky është depozita kryesore e logjeve të VBR, dhe %ProgramData% është një folder i fshehur dhe kjo është normale. Për më tepër, vendi i paracaktuar mund të rindezhet me ndihmën e çelësit të regjistrit të tipit REG_SZ: LogDirectory në degën HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
Në makinat Linux, logjet e agjentëve të punës duhet të kërkohen në/var/log/VeeamBackup/, nëse përdoret llogaria root ose sudo. Nëse nuk keni këto privilegje, atëherë kërkoni logjet në /tmp/VeeamBackup.
Për Veeam agent për %OS_name%, logjet duhet të kërkohen në %ProgramData%/Veeam/Endpoint (ose %ProgramData%/Veeam/Backup/Endpoint) dhe /var/log/veeam përkatësisht.
Nëse po përdorni Procesimin e Imazheve me Kujdes për Aplikacionin (dhe shumë mundësi po), situata komplikohet pak. Ju nevojiten logjet e ndihmësit tonë, që ruhen brenda vetë makinës virtuale, dhe logjet e VSS. Si dhe ku të siguroni këtë të mirat, është shkruar në mënyrë të detajuar në . Dhe, natyrisht, ka për mbledhjen e logjeve të nevojshme të sistemit.
Ngjarjet e Windows është e lehtë të mbledhën sipas . Nëse po përdorni Hyper-V, situata bëhet më e ndërlikuar, pasi do t'ju nevojiten gjithashtu të gjitha log-et e tij nga seksioni Applications and Service Logs > Microsoft > Windows. Megjithatë, gjithmonë mund të shkoni në një rrugë më të thjeshtë dhe thjesht të merrni të gjitha objektet nga %SystemRoot%System32winevtLogs.
Nëse ju ndodh diçka gjatë instalimit / përmirësimit, të gjitha informacionet e nevojshme mund t’i gjeni në folderin %ProgramData%/Veeam/Setup/Temp. Megjithatë, nuk do ta fsheh se në eventet e sistemit operativ mund të gjeni informacione më të dobishme sesa në këto log-e. Gjënë e mbetur interesante ndodhet në %Temp%, por atje kryesisht janë log-et e instalimit të softuerëve shoqërues, siç janë baza, bibliotekat .Net dhe të tjera. Mbani mend se Veeam instalohet nga msi, dhe të gjitha komponentët e tij gjithashtu instalohet si paketa të veçanta msi, edhe nëse kjo nuk tregohet në GUI. Si rezultat, nëse instalimi i njërit prej komponentëve dështon, e gjithë instalimi i VBR do të ndalet. Prandaj, duhet të shikoni në log-et dhe të shihni se çfarë saktësisht ka dështuar dhe në çfarë momenti.
Dhe një këshillë përfundimtare: kur merrni një gabim gjatë instalimit, mos u nxitoni të klikoni OK. Së pari merrni log-et, pastaj klikoni OK. Kështu do të merrni një log që përfundon në momentin e gabimit, pa papastërti në fund.
Dhe ndodh që të nevojitet të futesh në log-et e vSphere. Një detyrë e vështirë, por, duke u angazhuar, duhet të bësh edhe më shumë. Në variante më të thjeshta, na duhen log-et e ngjarjeve të virtualizimit vmware.log, të cilat ndodhen pranë skedarit të saj .vmx. Në një rast më të ndërlikuar, hapim Google dhe kërkojmë se ku ndodhen log-et për versionin tuaj të hostit, sepse VMware i pëlqen të ndryshojë këtë vend nga lëshimi në lëshim. Ja, për shembull, , dhe këtu për . Për log-et e vCenter përsërisim procedurën . Por në përgjithësi, log-et që na interesojnë janë log-et e ngjarjeve të hostit hostd.log, ngjarjet e hosteve nën menaxhimin e vCenter vpxa.log, log-et e kernelit vmkernel.log dhe log-et e autentifikimit auth.log. Në rastet më të komplikuara, mund të nevojitet log-u i SSO, i cili ndodhet në dosjen SSO.
E ngarkuar? E komplikuar? Frikësuese? Por kjo nuk është as gjysma e informacionit me të cilin operon supporti ynë në një bazë ditore. Prandaj ata janë të vërtetë shumë të shkëlqyer.
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. Kur kërkon në mënyrë që të kuptosh shkakun e dhimbjeve, është e dobishme të dish se si është e strukturuar pacienti.
Pra nda, si është e njohur nga të gjithë, Veeam Backup është një aplikacion i bazuar në SQL. Pra, të gjitha konfigurimet, informatat dhe gjithçka që nevojitet për funksionimin e duhur janë të gjitha në bazën e të dhënave të tij. Saktësisht, në dy baza, nëse flasim për lidhjen VBR dhe EM: VeeamBackup dhe VeeamBackupReporting, përkatësisht. Ashtu ka vazhduar: duke instaluar një aplikacion tjetër, shfaqet një bazë tjetër. Në mënyrë që të mos mbajmë të gjitha vezët në një kos.
Por që të gjitha këto të funksionojnë siç duhet, na nevojitet një grup shërbimesh dhe aplikacionesh që do të lidhin të gjitha komponentët së bashku. Thjesht si shembull, kështu duket në një nga laboratorët e mi:
Në rolin e dirigjentit kryesor del Shërbimi Veeam Backup. Ai është përgjegjës për shkëmbimin e informacionit me bazat. Po ashtu, ai është përgjegjës për nisjen e të gjitha detyrave, menaxhon orkestrimin e burimeve të dedikuara dhe shërben si një qendër komunikimesh për konsolat, agentët dhe gjithçka tjetër. Në një fjalë, pa të, përveç asnjë mënyre nuk shkon, por kjo nuk do të thotë se ai e bën gjithçka vetë.
Në realizimin e asaj që është menduar, e ndihmon Menaxheri Veeam Backup. Ky është një entitet, i angazhuar në ekzekutimin e punëve dhe monitorimin e procesit të tyre. Duar të punës të shërbimit të backup-it, me të cilin ai lidhet me hostet, krijon snapshot-e, monitoron retention-in dhe kështu me radhë.
Por, le të kthehemi te lista e shërbimeve. Shërbimi Veeam Broker. Ka konstatohesh në v9.5 (dhe kjo nuk është një minues kriptovalutash, siç menduan disa atëherë). Ai merret me mbledhjen e informacionit rreth hosteve VMware dhe mbajtjen e tij të azhurnuar. Por mos u nxitoni të shkruani komente të zemëruara, duke thënë se ne po ju spijonim dhe po përcillnim të gjitha përllogaritjet/passwordet tuaj. Çështja është pak më e thjeshtë. Kur aktivizoni një backup, gjëja e parë që duhet të bëni është të connectoheni me host-in dhe të azhurnoni të gjitha të dhënat për strukturën e tij. Kjo është një histori mjaft e ngadaltë dhe e ngarkuar. Thjesht kujtoni sa zgjat operacioni i login-it përmes ndërfaqes në web, dhe mbani mend se atje llogaritet vetëm sipërfaqja e sipërme. Pastaj, duhet të hapni të gjithë hierarkinë deri në vendin e duhur, për rastin. Më kratësisht, është tmerr. Nëse aktivizoni dhjetëra backup-e, do të thotë se çdo punë duhet të kalojë përmes kësaj procedure. Nëse bëhet fjalë për infrastrukturat e mëdha, ky proces mund të marrë dhjetë minuta e më shumë. Prandaj, u mor vendimi për të ndarë një shërbim të veçantë për këtë, përmes të cilit gjithmonë mund të merrni informacionin e përditësuar. Ai, kur fillon, kontrollon dhe skanon të gjithë infrastrukturat e shtuar, dhe më pas përpiqet të funksionojë vetëm në nivelin e ndryshimeve inkrementale. Kështu që edhe nëse do të aktivizoni njëqind backup-e njëkohësisht, të gjithë do të kërkojnë informacion nga brokeri ynë, dhe nuk do të vuajnë hostet me kërkesat e tyre. Nëse keni shqetësime mbi burimet, sipas llogaritjeve tona, për 5000 makina virtuale nevojiten vetëm rreth 100 Mb memorie.
Më pas, kemi Veeam Console. Kjo është gjithashtu Veeam Remote Console, e njohur si Veeam.Backup.Shell. Kjo është UI që shohim në screenshotet. Është e thjeshtë dhe e qartë — konzola mund të fillohet nga çdo vend, mjafton të jetë Windows dhe të ketë lidhje me serverin VBR. E vetmja gjë që mund të themi: procesi FLR do të montojë pikët lokalisht (dmth. në makinën ku është nisur konsola). Edhe Veeam Explorers do të fillojnë lokalish, sepse ata janë pjesë e konsolës. Por kjo më çoi në thellësi...
Shërbimi tjetër interesant është Veeam Backup Catalog Data Service. Në listën e shërbimeve, njihet si Veeam Guest Catalog Service. Merret me indeksimin e sistemeve të skedarëve në makinat gazda dhe mbush këtë informacion në folderin VBRCatalog. Përdoret vetëm aty ku është aktivizuar indeksi. Aktivizimi ka kuptim vetëm nëse keni Enterprise Manager. Prandaj, këshilla nga zemra: mos e aktivizoni indekset thjesht kështu, nëse nuk keni EM. Ruani nervat dhe kohën e suportit tuaj.
Po ashtu, nga shërbimet e tjera të rëndësishme, duhen theksuar Veeam Installer Service, me të cilin bëhet dorëzimi dhe instalimi i komponentëve të nevojshëm në proxy, depo dhe gateway të tjerë. Në fakt, ai transporton paketat .msi në servera dhe kryen instalimin e tyre.
Veeam Data Mover — përmes agentëve ndihmës që ekzekutohen në proxyt (dhe jo vetëm) merret me përcjelljen e të dhënave. Për shembull, gjatë backup-it një agjent do të lexojë skedarët nga datastoret e hostit, ndërsa tjetri do t'i regjistrojë ato me kujdes në backup.
Është e rëndësishme të theksohet një gjë, ndaj shumë nga klientët reagojnë — është dallimi midis versioneve të shërbimeve dhe informacioneve në panelin Programs and Features. Po, lista do jetë e njëjtë, por versionet mund të kenë një kaos të plotë. Kjo nuk është mitike nga këndvështrimi vizual, megjithatë është plotësisht normale nëse gjithçka punon stabilisht. Për shembull, numri i versionit të shërbimit Installer është shumë më i pasur se ai i shërbimeve të tjera. A është një tmerr? Jo, sepse ai nuk rinstalohet plotësisht, por thjesht përditësohet DLL-i i tij. Në patch-in v9.5 U4 ndodhi një makth për mbështetje teknike: gjatë përditësimit të gjitha shërbimet morën versione të reja, përveç më kryesorit. Në patch-in U4b shërbimi i transportit përparoi të gjitha të tjerët deri në dy versione (nëse gjykojmë nga numrat). Edhe kjo është normale — në të u gjet një bug i rëndësishëm, prandaj ai mori një përditësim bonus krahas të tjerëve. Prandaj, për të përmbledhur: ndryshimi i versioneve MUND TË jetë një problem, por nëse ka një ndryshim dhe gjithçka punon siç duhet, ka të ngjarë që kështu duhet të jetë. Por askush nuk ju ndalon të pyetni për këtë në mbështetje teknike.
Këto janë shërbimet e quajtura obligative ose shërbimet Mandatory. Ekzistojnë gjithashtu një grumbull shërbimesh ndihmëse, si Shërbimi i Kasetës, Shërbimi i Montimit, Shërbimi vPowerNFS dhe të tjerë.
Për Hyper-V gjithashtu është e njëjta gjë, vetëm se ka specifika. Shërbimi i Integrimit të Backup-it Veeam për Hyper-V dhe një pajisje e saj për të punuar me CBT.
Dhe në fund do të flasim për ata që punojnë në makina virtuale gjatë backup-it. Për të nisur skriptet pre- dhe post-freeze, për të krijuar kopje të hijezuara, për të mbledhur metadatat, për të punuar me log-jet e transaksioneve SQL dhe të tjera përdoret Veeam Guest Helper. Dhe nëse ndodh indeksoni sistemi i skedarëve, Veeam Guest Indexer . Këto janë shërbime përkohshme, të cilat aktivizohen gjatë backup-it dhe fshihen pas tij.
Në rastin e makinave Linux, çdo gjë është shumë më e thjeshtë për shkak të numrit të madh të librarive të integruara dhe mundësive të vetë sistemit. Për shembull, indeksoni bëhet përmes mlocate.
Për tani mjafton
Nuk dëshiroj të ju shqetësoj më dhe një përmbledhje Përfundimi i prezantimit në hapësirën nën kapakët e Veeam-it është i përfunduar. Po, as që e kemi arritur përmbajtjen e logëve dhe, besoni, që informatat e paraqitura në to të mos duken si një rrjedhë mendimi e lidhur ngushtë, ky prezantim është me të vërtetë i nevojshëm. Planifikoj të kaloj në logët e vetë në artikullin e tretë, dhe plani për të ardhmen është të shpjegoj se kush i gjeneron logët, çfarë saktësisht reflektohet në to dhe pse është ashtu dhe jo ndryshe.
Burimi: habr.com
