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
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Lithuanian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish