Ne jemi në Veeam dhe i duam logët. Dhe ndonjëherë, duke qenë se shumica e zgjidhjeve të nostres janë modulare, ato shkruajnë shumë logë. Duke qenë se fusha jonë e veprimit është ruajtja e të dhënave tuaja (dmth. për të garantuar një gjumë të qetë), logët duhet jo vetëm të regjistrojnë çdo ngjarje, por edhe ta bëjnë këtë në detaje. Kjo është e nevojshme për të qenë të sigurt se në rast ndonjë problemi, do të kuptohet se çfarë ndodhi, kush është fajtor dhe çfarë duhet të bëjmë më pas. Këtu si në kriminalistikë: kurrë nuk e di se cila detaj mund të ndihmojë për të zbuluar vrasësin e Laura Palmer.
Prandaj, vendosa të filloj një seri artikujsh ku do të tregoj radhazi se çfarë shkruajmë në logë, ku i ruajmë ato, si të mos dalim të çmendur nga struktura e tyre dhe çfarë duhet të kërkojmë brenda tyre.
Pse një seri artikujsh dhe pse jo ta përshkruajmë gjithçka njëherësh?
Thjesht të renditosh se cili log ndodhet ku dhe çfarë përmban ai — është një ide e komplikuar. Dhe për të mbajtur këtë informacion të azhurnuar, madje, është një mendim që tremb. Një renditje e të gjithë llojeve të mundshme të logëve në Veeam Backup & Replication — është një tabelë që zë disa faqe me shkronja të vogla. Dhe ajo do të jenë e vlefshme vetëm në momentin e publikimit, pasi me daljen e patch-it të ardhshëm mund të shfaqen logë të rinj, logjika e të dhënave në ato të vjetra mund të ndryshojë, etj. Prandaj, do të ishte shumë më e dobishme të shpjegoheshin struktura e tyre dhe thelbi i informacionit brenda tyre. Kjo do të ndihmojë në orientimin më të mirë në terren, sesa thjesht të mësosh nga memorizimi emrave.
Prandaj, në mënyrë që të mos hidhemi me kokë në greminën e panumërt të teksteve, le të bëjmë një punë përgatitore në këtë artikull. Prandaj sot nuk do të futemi në logët vetë, por do t'i afrohemi nga ana tjetër: do të krijojmë një glosar dhe pak do të diskutojmë mbi strukturën e Veeam nga këndvështrimi i krijimit të logëve.
Glosari dhe gjuhë argotike
Këtu së pari duhet të kërkoj falje para mbrojtësve të pastrimit të gjuhës ruse dhe dëshmitarëve të fjalorit të Oжегов. Ne të gjithë e duam shumë gjuhën tonë amtare, por industria e mallrave IT funksionon në anglisht. Ne nuk e shpikëm këtë, por kështu e solli historia. Nuk jam fajtore, ai vetë erdhi (c)
Në fushën tonë, problemi i anglicizmave (dhe gjargonit) ka specifikën e vet. Kur fjalë të pafajshme si "host" apo "guest" kuptohen prej kohësh në gjithë botën si gjëra shumë të caktuara, në ⅙ të sipërfaqes së tokës vazhdojnë betejat heroike dhe përplasje mes fjalorëve. Dhe argumenti i detyrueshëm "Ndërsa ne në punë...".
Përveç kësaj, kemi terminologjinë tonë specifike që i përket pikërisht produkteve Veeam, edhe pse disa fjalë dhe fraza kanë dalë në përdorim të gjerë. Prandaj tani ne do të biem dakord se çfarë do të thotë çdo term, dhe në vazhdim, kur them "guest", do të kem parasysh pikërisht atë që është shkruar në këtë kapitull, dhe jo atë që ju jeni mësuar në punën tuaj. Dhe po, kjo nuk është ndonjë çmenduri personale e imja, janë terma të ngulitura në industri. Të luftosh me to është disi e kotë. Megjithatë, gjithmonë jam për të diskutuar në komentet.
Fatkeqësisht, terminologjia në punën tonë dhe për produktet është jashtëzakonisht e madhe, kështu që nuk do të përpiqem të lista të gjitha. Vetëm ato më bazike dhe të nevojshme për mbijetesë në detin e informacionit mbi backupet dhe log-et. Për ata që janë të interesuar, mund të nga kolegët që përmendin llogaritë, ku ai gjithashtu ka dhënë një listë terma që lidhen me atë pjesë funksionaliteti.
Host (Host): Në botën e virtualizimit, kjo është makina me hipervizorin. Fizike, virtuale, cloud — nuk ka rëndësi. Nëse mbi ndonjë gjë është instaluar një hipervizor (ESXi, Hyper-V, KVM etj.), atëherë kjo "diçka" quhet host. Qoftë një klasë me dhjetë raftesh apo laptopi juaj me një laboratori me një të vetëm virtual — nëse keni aktivizuar hipervizorin, atëherë keni bërë host. Sepse hipervizori hoston makina virtuale. Ka madje një legjendë që VMware në kohën e saj donte të arrinte një asociacion të fortë të fjalës host me ESXi. Por nuk e arriti.
Në botën moderne, koncepti i "host" praktikisht është bashkuar me atë të "server", që sjell një konfuzion të caktuar në komunikim, sidomos nëse flasim për infrastrukturën Windows. Pra, çdo makinë që ka ndonjë shërbim të interesit tonë, mund të quhet me siguri host. Për shembull, në log-et e WinSock, çdo gjë etiketohet si host. Një shembull klasik është "Host not found". Pra, le të nisemi nga konteksti, por mos harroni — në botën e virtualizimit, host është ajo që hoston mysafirët (për këtë flitet dy rreshta më poshtë).
Nga argotët lokalë (madje akronimet, në këtë rast) përmendim se VMware është VI, vSphere është VC, dhe Hyper-V është HV.
Guest (E Huaj): Një makinë virtuale që punon në host. Këtu madje nuk ka nevojë për shpjegim, gjithçka është kaq logjike dhe e thjeshtë. Megjithatë, shumë përpiqen t'i japin këtu disa kuptime të tjera.
Pse? Nuk e di.
Guest OS, përkatësisht, sistema operativ i makinës së huaj. Dhe kështu me radhë.
Backup/Replication Job (punë e rezervës): Një argot i pastër i VMware, që përfaqëson ndonjë nga detyrat. Backup job == Puna e Rezervës. Si të përkthehet kjo bukur në shqip — askush nuk e ka menduar, prandaj të gjithë thonë 'punë'. Me theksin në sillën e fundit.
Po, kështu thjesht e marrin dhe thonë 'punë'. Madje e shkruajnë edhe në letra, dhe gjithçka është në rregull.
Llojet e punëve të rezervës, detyrat e rezervës etj., faleminderit, por nuk nevojiten. Thjesht punë, dhe do t'ju kuptojnë. E rëndësishme është të vendosni theksin në sillën e fundit.
Backup (Rezerva, rezervim. Për vërtetë-pleqtë e vërtetë lejohet edhe rezervim): Përveç asaj që është e qartë (një kopje rezervë që ndodhet diku), do të thotë gjithashtu edhe vetë punën (tre rreshta më lart, nëse e keni harruar), për shkak të së cilës krijohet ai skedari rezervë. Ka shumë mundësi që zotërinjtë mbajtës të anglishtes janë tepër të lenë për të thënë gjithmonë 'I ran my backup job', prandaj thonë thjesht 'I ran my backup' dhe të gjithë e kuptojnë njëri-tjetrin. Propozoj të mbështesim këtë iniciativë të shkëlqyer.
Consolidate (Konsolidimi): Term që u shfaq në ESXi 5.0 Opsioni në menunë e punës me snapshotet, që nis procesin e fshirjes së ashtuquajturve snapshot të braktisur. Pra, snapshot që janë fizikisht aty, por kanë rënë nga struktura logjike e dukshme. Teorikisht, ky proces nuk duhet të preki skedarët e shfaqur në menaxherin e snapshot-eve, megjithatë ndodhin gjëra të tjera. Qëllimi i procesit të konsolidimit është që të dhënat nga snapshoti (disku fëmijë) shkruhen në diskun kryesor (disku prind). Procesi i bashkimit të diskeve quhet mërg (merge). Nëse është dhënë komanda për konsolidim, regjistrimi i snapshotit mund të hiqet nga baza më përpara se sa snapshoti të mërgohet dhe fshihet. Dhe nëse snapshoti nuk mund të fshihet për ndonjë arsye, atëherë shfaqen këta snapshot të braktisur. një KB të mirë. .
shkruar për to në Habrë (Habré). Një koncept mjaft i gjerë, por në botën e virtualizimit nënkupton vendin ku ruhen skedarët e makinave virtuale. Megjithatë, në çdo rast, duhet të kuptoni shumë qartë kontekstin dhe, në rast të dyshimeve të vogla, të sqaroni se çfarë pati në mendje biseduesi juaj.
Proxy (Proksi): Është e rëndësishme të kuptohet menjëherë se Veeam Proxy nuk është aq e njëjtë sa jemi mësuar në fushën e internetit. Brenda produkteve të Veeam, ky është një entitet që merret me transferimin e të dhënave nga një vend në një tjetër. Pa u menduar shumë në detaje, VBR është serveri komandues, ndërsa proksi është “kali” i tij i punës. Pra, proksi është makina përmes së cilës rrjedh trafiku dhe mbi të cilën janë instaluar komponentët e VBR që ndihmojnë në menaxhimin e këtij trafiku. Për shembull, të transferoni të dhëna nga një kanal në një tjetër ose thjesht të lidhni disqe (režimi HotAdd).
Repository (Repozitari): Teknikisht, kjo është thjesht një regjistrim në bazën e të dhënave të VBR që tregon vendin ku ruhen kopjet rezervë dhe si të lidhesh me këtë vend. Në thelb, kjo mund të jetë një ndarje simple CIFS, një disk i veçantë, një server apo një kovë në re. Sërish, jemi brenda kontekstit, por kuptojmë se repo e shkurtuar është thjesht vendi ku qëndrojnë kopjet rezervë të tua.
Snapshot (SnapshOt): Adhuruesit e gramatikës oksfordiane preferojnë të flasin për kush është snEpShot, kush është snEpShot; megjithatë, shumica e analfabetëve fiton 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 në kohë. Ky proces bëhet ose përmes ridrejtimeve të përkohshme të operacioneve I/O nga disku kryesor — ky do të quhet një snapshot RoW (Redirect on Write) — ose duke i marrë blloqet e riprogramueshme nga disku juaj në një tjetër — kjo do të quhet një snapshot CoW (Copy on Write). Pikërisht falë mundësive të gjera të përdorimit të këtyre funksioneve, Veeam mund të realizojë magjinë e saj të backupit. Saktësisht, jo vetëm ata, por kjo është çështja e lëshimeve të afërta.
Në dokumentacionin dhe logjet e ESXi, rreth këtij termi ka kaos, dhe në kontekstin e përmendjes së snapshots, mund të hasni si snapshotet, ashtu edhe redo log dhe madje edhe delta disk. Në dokumentacionin e Veeam nuk ka një përçarje të tillë, dhe snapshot është një snapshot, ndërsa redo log është pikërisht skedari REDO, i krijuar nga një disk jo-përhershëm. Skedarët REDO fshihen kur fikni makinat virtuale, kështu që ngatërresa e tyre me snapshotet është një rrugë drejt dështimit.
Sintetik (Synthetic): Backup-et sintetike i përkasin backup-eve reverse incremental dhe forever forward. Nëse ndonjëherë nuk keni hasur këtë term, atëherë ky është thjesht një nga mekanizmat e përdorur për ndërtimin e zinxhirit të backup-it. Megjithatë, në logje gjithashtu mund të hasni konceptin Transform, i cili përdoret për krijimin e kopjeve të plota nga incrementet (synthetic full).
Detyra (Task): Ky është procesi i përpunimit të çdo makine të veçantë brenda një punë. Pra, nëse keni një punë backup që përfshin tri makina. Kështu, çdo makinë do të përpunohen në kuadër të një detyre të veçantë. Pra, do të ketë katër logje: një kryesore për punën dhe tri për detyrat. Megjithatë, këtu ka një nuancë të rëndësishme: me kalimin e kohës, fjala “detyrë” ka marrë shumë kuptime. Kur flasim për logjet e zakonshme, nënkuptojmë se detyra është pikërisht VM. Por ka “detyrat” e veta edhe në proxy dhe në depo. Aty mund të nënkuptojë si një disk virtual, ashtu edhe një makinë virtuale, ose të gjithë punën. Pra, është e rëndësishme të mos humbni kontekstin.
Shërbimi Veeam %name% (Service): Për mirëqenien e backup-eve të suksesshme punojnë menjëherë disa shërbime, lista e të cilave mund të gjendet në veglën standarde. Emrat e tyre mjaft hapur pasqyrojnë thelbin e tyre, megjithatë mes të barabartëve ka një më të rëndësishëm - Shërbimi i Backup-it Veeam, pa të cilin të tjerat nuk do të funksiononin.
VSS: Teknikisht, VSS gjithmonë duhet të nënkuptojë Shërbimin për Kopjimin e Hijes së Volumit të Microsoft. Në fakt, përdoret nga shumë si sinonim për Procesimin e Imazheve të Ndërgjegjshëm për Aplikacionin. Çka, sigurisht, është kategorikisht e gabuar, megjithatë kjo është një histori nga ajo lloj që thotë "Çdo SUV mund të quhet Jeep, dhe do të kuptohet".
Logjet fantastike dhe vendet ku ato banojnë
Dua të filloj këtë kapitull me zbërthimin e një misteri të madh - cilin kohë shfaqet në logje?
Mbani mend:
- ESXi gjithmonë shkruan logjet në UTC+0.
- vCenter mban logjet sipas kohës së zonës së tij temporale.
- Veeam mban logjet sipas kohës dhe zonës temporale të serverit ku ndodhet.
- Dhe vetëm ngjarjet Windows në formatin EVTX nuk lidhin asgjë. Kur hapen, koha rregullohet në përputhje me makinën në të cilën i hapin. Zgjidhja më e përshtatshme, megjithatë, ndodhin vështirësi me të. Vështirësia e vetme e dukshme është ndryshimi i lokalizimeve. Kjo është një rrugë praktikisht e garantuar për log-e të papërshkrueshme. Po, ka mundësi se si ta zgjidhni këtë, por le të mos debatojmë se gjithçka në IT funksionon në anglisht dhe le të bien dakord të vendosim gjithmonë lokalizimin anglez në serverat. Ju lutem.
Tani, le të flasim për vendet ku jetojnë log-et dhe si mund t'i merrni 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 mes gjithë grumbullit të skedarëve, që lidhen me problemin tuaj. Për këtë, kemi një wizard të veçantë, të cilit mund t'i jepni një punë specifike dhe një periudhë specifike, për të cilën ju nevojiten log-et. Më pas ai do të kalojë vetë përmes dosjeve dhe do t'i grumbullojë të gjitha nevojat në një arkiv. Për informacionin se ku mund ta kërkoni dhe si të punoni me të, është shkruar në detaje në .
Megjithatë, wizard-i grumbullon log-et vetëm për disa detyra dhe, për shembull, nëse keni nevojë të studioni log-et e restorantit, dështimit ose rikthimit, rruga juaj është në dosjen %ProgramData%/Veeam/Backup. Ky është ruajtësi kryesor i log-eve VBR, dhe %ProgramData% është një dosje e fshehur dhe kjo është në rregull. Për më tepër, vendi me të drejtë mund të ribëhet me çelësin e regjistrit si REG_SZ: LogDirectory në degën HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
Në makinat Linux, log-et e agjentëve të punës duhet të kërkohen në /var/log/VeeamBackup/, nëse përdoret një llogari root ose sudo. Nëse nuk keni këto privilegje, atëherë kërkoni log-et në /tmp/VeeamBackup.
Për agjentin Veeam për %OS_name%, log-et 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 Imazhit me Ndihmë të Aplikacionit (dhe ndoshta jeni duke e përdorur), atëherë situata paksa komplikohet. Ju nevojiten log-et e ndihmës tonë, që ruhen brenda vetë makinë virtuale, dhe log-et VSS. Për informacionin se si dhe ku të merrni këtë, është shkruar në detaje në . Dhe, sigurisht, ka për grumbullimin e log-eve të nevojshme të sistemit.
Ngjarjet Windows janë të lehta për t'u grumbulluar sipas . Nëse po përdorni Hyper-V, puna komplikohet, pasi do t'ju nevojiten gjithashtu të gjitha log-et e tij nga dega Application and Service Logs > Microsoft > Windows. Megjithatë, gjithmonë mund të zgjidhni një rrugë më të thjeshtë dhe të marrni të gjitha objekte nga %SystemRoot%\System32\winevt\Logs.
Nëse diçka prishet gjatë instalimit/upgradimit, e gjitha e nevojshme mund të gjendet në dosjen %ProgramData%/Veeam/Setup/Temp. Megjithatë, nuk do ta fsheh, se në eventet e sistemit mund të gjeni informacione më të dobishme sesa në këto loge. Informacioni tjetër interesant ndodhet në %Temp%, por atje kryesisht janë loge instalimi të softuerëve të ndihmës, si baza, bibliotekat .Net dhe të tjera. Kini parasysh se Veeam instalohet nga msi, dhe të gjithë komponentët e tij po ashtu instalohet si paketa të veçanta msi, edhe nëse kjo nuk është treguar në GUI. Prandaj, nëse instalimi i njërit nga komponentët dështon, i gjithë instalimi i VBR do të ndalet. Kështu që duhet të shikoni në loge dhe të shihni çfarë ka shkuar keq dhe kur.
Dhe një këshillë përfundimtare: kur merrni një gabim gjatë instalimit, mos u nxitoni të klikoni OK. Së pari merrni loget, pastaj klikoni OK. Kështu do të merrni logun që përfundon në momentin e gabimit, pa mbeturina në fund.
Dhe ndonjëherë ndodh që duhet të hulumtoni loget e vSphere. Një aktivitet shumë i pafalshëm, por me mëngët e zbutura, duhet ta bëni dhe gjëra të tilla. Në variantin më të thjeshtë, na duhen loget me eventet e makinës virtuale vmware.log, të cilat ndodhen pranë skedarit të saj .vmx. Në rastin më të komplikuar, hapni Google dhe pyesni ku ndodhen loget për versionin tuaj të hostit, pasi VMware e adhuron të ndryshojë këtë vend nga një version në tjetrin. Ja, për shembull, , dhe kjo është për . Për loget e vCenter përsërisim procedurën . Por në përgjithësi, do na interesojnë loget e eventeve të hostit hostd.log, eventet e hosteve nën menaxhimin e vCenter vpxa.log, loget e bërthamës vmkernel.log dhe loget e autentifikimit auth.log. Në rastet më të vështira, mund të nevojitet logu SSO, i cili ndodhet në dosjen SSO.
E ndërlikuar? E ndërlikuar? E frikshme? Epo, kjo nuk është as gjysma e informacionit me të cilin punon mbështetja jonë në një bazë të përditshme. Pra, ata janë me të vërtetë shumë të shkëlqyer.
Komponentët e Veeam
Dhe si përfundim i këtij artikulli hyrës, do të flasim pak për komponentët e Veeam Backup & Replication. Sepse kur kërkoni shkakun e dhembjeve, është mirë të dini se si është strukturuar pacienti.
Pra ndoshta është e njohur për të gjithë, Veeam Backup është një aplikacion i bazuar në SQL. Pra, të gjitha konfigurimet, të gjitha informacionet dhe gjithçka që nevojitet për funksionimin normal, ndodhet në bazën e tij. Në fakt, në dy baza, nëse flasim për lidhjen VBR dhe EM: VeeamBackup dhe VeeamBackupReporting, përkatësisht. Kështu është zakon: ne vendosim një aplikacion tjetër - shfaqet një bazë tjetër. Që të mos i mbajmë të gjitha vezët në një shportë.
Por për që të gjitha këto të funksionojnë në harmoni, na nevojitet një grup shërbimesh dhe aplikacionesh që do të lidhin të gjitha komponentët së bashku. Thjesht për shembull, kështu duket në një nga laboratorët e mi:
Në rolin e dirigjentit kryesor Veeam Backup Service. Ai është përgjegjës për shkëmbimin e informacionit me bazat. Ai gjithashtu për gjenerimin e të gjitha detyrave, merret me orkestrimin e burimeve të ndara dhe funksionon si një qendër komunikimesh për konsollet e ndryshme, agjentët dhe gjëra të tjera. Në fjalë, pa të nuk ka asnjë mundësi, por kjo nuk do të thotë që ai e bën gjithçka vetë.
Për realizimin e të menduarit, ai ndihmohet nga Veeam Backup Manager. Kjo nuk është një shërbim, por një entitet që merret me fillimin e punëve dhe monitoron procesin e përfundimit të tyre. Dorezat punuese të shërbimit të backup, me të cilat ai lidhet me hostët, krijon snapshot-e, monitoron ruajtjen dhe kështu me radhë.
Por le të kthehemi te lista e shërbimeve. Veeam Broker Service. Shfaqur në v9.5 (dhe kjo nuk është minues kriptovalute, siç menduan disa atëherë). Merret me mbledhjen e informacionit mbi hostet VMware dhe mbajtjen e tij të përditësuar. Por mos u nxitoni të shkruani komente të zemëruara, se ne po ju spiunojmë dhe po ia kalojmë të gjitha logjet/faqet ta shmajorit. Gjithçka është pak më e thjeshtë. Kur ju filloni një back-up, e para që duhet të bëni është të lidheni me hostin dhe të përditësoni të gjitha të dhënat mbi strukturën e tij. Kjo është një histori mjaft e ngadaltë dhe e rëndë. Thjesht kujtoni se sa zgjat operacioni i login-it përmes ndërfaqes web, dhe mbani mend se atje merret parasysh vetëm sipërfaqja e sipërme. Pastaj duhet të hapet e gjithë hierarkia deri në vendin e duhur, për të cilin mund të thuash se është tmerr. Nëse ju ndiheni të shqetësuar në lidhje me burimet, sipas llogarive tona, për 5000 virtualka nevojiten vetëm rreth 100 Mb memorie.
Më pas kemi Konsolën Veeam. E njëjta Konsolë e Largët Veeam, e njohur edhe si Veeam.Backup.Shell. Kjo është GUI ajo që ne e shohim në screenshot-e. Të gjitha janë të thjeshta dhe të qarta — konsolën mund ta nisni nga kudo, mjafton të jetë Windows dhe të ketë lidhje deri te serveri VBR. E vetmja gjë që mund të themi: procesi FLR do të montohet lokal (dmth. në makinen ku është e hapur konsola). Dhe eksploruesit e ndryshëm Veeam gjithashtu do të nisin lokal, sepse ata janë pjesë e konsolës. Por kjo më mori në thellësi…
Shërbimi tjetër interesant është— Shërbimi i të Dhënave të Katalogut të Backup-it Veeam. Në listën e shërbimeve njihet si Veeam Guest Catalog Service. Merret me indeksimin e sistemeve të skedarëve në makinat pritëse dhe mbush këtë njohuri në dosjen VBRCatalog. Përdoret vetëm aty ku është aktivizuar indeksi. Aktivizimi ka kuptim vetëm nëse keni Enterprise Manager. Pra, një këshillë e sinqertë: mos e aktivizoni indeksimin thjesht për ta bërë këtë, nëse nuk keni EM. Ruani nervat tuaja dhe kohën e mbështetjes.
Po ashtu nga shërbimet e tjera të rëndësishme meritojnë të përmenden Veeam Installer Service, me anë të së cilës ndodhi dorëzimi dhe instalimi i komponenteve të nevojshme në proxy, repository dhe gateway të tjera. Në fakt, ajo dërgon paketat .msi në serverat dhe kryen instalimin e tyre.
Veeam Data Mover — me anë të agjentëve ndihmës që drejtohen në proxy (dhe jo vetëm) merret me zhvendosjen e të dhënave. Për shembull, gjatë një backup-i, një agjent do të lexojë skedarët nga datastoret e hostit, ndërsa tjetri do t'i regjistrojë me kujdes në backup.
Veçanërisht dua të theksoj një gjë e cila shpesh i reagon klientët — kjo është ndryshimi i versioneve të shërbimeve dhe informacionit në veglën Programs and Features. Po, lista do të jetë e njëjtë, por versionet mund të jenë krejtësisht të ndryshme. Kjo nuk është shumë e këndshme nga pikëpamja vizuale, por është plotësisht normale, nëse gjithçka funksionon stabilisht. Për shembull, numri i versionit të shërbimit Installer është shumë pas në krahasim me të tjerët. Është një katastrofë? Jo, pasi ai nuk riinstalohet plotësisht, por thjesht përditësohet DLL e tij. Në patchin v9.5 U4 ndodhi një makth për mbështetje teknike: gjatë përditësimit, të gjithë shërbimet morën versione të reja, përveç atij më të rëndësishëm. Në patchin U4b, shërbimi i transportit e tejkaloi të tjerët me dy versione (nëse gjykojmë sipas numrave). Dhe kjo gjithashtu është normale — u zbulua një bug serioz, prandaj ai mori një përditësim bonus në krahasim me të tjerët. Prandaj, duke përfunduar: ndryshimi i versioneve MUND TË jetë një problem, por nëse ndodhet ndryshimi dhe gjithçka funksionon mirë, ndoshta ashtu është. Por askush nuk ju ndalon ta verifikoni këtë në mbështetje teknike.
Ishin këto shërbime të ashtuquajtura të detyrueshme ose Mandatory services. Por ka gjithashtu një grup të tërë shërbimesh ndihmës, si Tape Service, Mount Service, vPowerNFS Service dhe kështu me radhë.
Për Hyper-V gjithçka është e njëjtë, vetëm se ka një Veeam Backup Hyper-V Integration Service dhe një drejtues të vet për të punuar me CBT.
Dhe në fund do të flasim për ata që punojnë në virtuale gjatë back-up-it. Për të nisur skriptet pre- dhe post-freeze, për të krijuar kopje shadow, për të mbledhur metadata, për të punuar me log-ët e transaksioneve SQL dhe për të tjera përdoret Veeam Guest Helper. Dhe nëse ndodh indeksimi i sistemeve të skedarëve, Veeam Guest Indexer . Këto janë shërbime të përkohshme, që janë krijuar përkohësisht gjatë back-up-it dhe fshihen pas tij.
Në rastin e makinave Linux, gjithçka është shumë më e thjeshtë për shkak të numrit të madh të bibliotekave të brendshme dhe mundësive të sistemit vetë. Për shembull, indeksimi bëhet përmes mlocate.
Për këtë, deri tani mjafton
Nuk do t'ju mundësoj më shumë dhe një përmbledhje e hapësirës nën kapak në Veeam e konsideroj përfunduar. Po, as nuk kemi arritur afër log-ëve të vetë, por besoni, që informacioni i paraqitur në to të mos duket si një rrjedhë e pandërprerë mendimesh, një hyrje e tillë është absolutisht e nevojshme. Plani për të kaluar te log-ët vetë e kam vetëm në artikullin e tretë, ndërsa plani për të ardhmen — të shpjegoj se kush i gjeneron log-ët, çfarë saktësisht tregohet në to dhe pse ashtu dhe jo ndryshe.
Burimi: habr.com
