Ni ĉe Veeam amas ŝtipojn. Kaj ĉar la plej multaj el niaj solvoj estas modulaj, ili skribas multajn protokolojn. Kaj ĉar la amplekso de nia agado estas certigi la sekurecon de viaj datumoj (t.e. trankvila dormo), tiam la protokoloj devas ne nur registri ĉiun ternon, sed ankaŭ fari ĝin iom detale. Ĉi tio estas necesa por ke en kazo de io estu klare kiel ĉi tiu "kio" okazis, kiu kulpas, kaj kio devas esti farita poste. Estas kiel en krimmedicina scienco: vi neniam scias, kia aĵo helpos vin trovi la murdinton de Laura Palmer.
Tial mi decidis svingi serion da artikoloj, kie mi sinsekve parolos pri tio, kion ni skribas al la ŝtipoj, kie ni stokas ilin, kiel ne freneziĝi kun ilia strukturo kaj kion serĉi en ili.
Kial serio de artikoloj kaj kial ne priskribi ĉion samtempe?
Simple listigi kiu protokolo estas kie kaj kio estas konservita en ĝi estas sufiĉe katastrofa entrepreno. Kaj estas timige eĉ pensi pri teni ĉi tiun informon ĝisdatigita. Simpla listo de ĉiuj eblaj tipoj de protokoloj en Veeam Backup & Replication estas tabelo sur pluraj folioj en malgrandaj literoj. Jes, kaj ĝi estos grava nur en la momento de la publikigo, ĉar. kiam la sekva flikaĵo estas liberigita, novaj protokoloj povas aperi, la logiko de la konservitaj informoj en la malnovaj ŝanĝiĝos, ktp. Tial, estos multe pli profite klarigi ilian strukturon kaj la esencon de la informoj enhavitaj en ili. Ĉi tio permesos al vi pli bone navigi la lokojn ol la banala amaso de nomoj.
Sekve, por ne rapidi en la naĝejon de tekstaj folioj, ni faru preparlaboron en ĉi tiu artikolo. Sekve, hodiaŭ ni ne eniros la protokolojn mem, sed iros de malproksime: ni kompilos glosaron kaj priparolos la strukturon de Veeam iomete rilate al generado de protokoloj.
Terminaro kaj ĵargono
Ĉi tie, antaŭ ĉio, indas pardonpeti al la ĉampionoj de la pureco de la rusa lingvo kaj la atestantoj de la vortaro de Oĵegov. Ni ĉiuj tre amas nian gepatran lingvon, sed la malbenita IT-industrio funkcias en la angla. Nu, ni ne elpensis ĝin, sed ĝi okazis historie. Ne estas mia kulpo, li mem venis (c)
En nia komerco, la problemo de anglismoj (kaj ĵargono) havas siajn proprajn specifaĵojn. Kiam sub senkulpaj vortoj kiel "gastiganto" aŭ "gasto" la tuta mondo delonge komprenis tre specifajn aferojn, tiam sur ⅙ de la tero, heroa konfuzo kaj ŝanceliĝo kun pikado en vortarojn daŭras. Kaj la strikte deviga argumento "Sed ĉe nia laboro...".
Plie, ekzistas pure nia terminologio, kiu estas eneca en Veeam-produktoj, kvankam kelkaj vortoj kaj frazoj iris al la homoj. Tial, nun ni konsentos pri kia termino signifas kion, kaj estonte, sub la vorto "gasto", mi signifos ĝuste tion, kio estas skribita en ĉi tiu ĉapitro, kaj ne kion vi kutimas ĉe la laboro. Kaj jes, ĉi tio ne estas mia persona kaprico, ĉi tiuj estas bone establitaj terminoj en la industrio. Batali ilin estas iom sencela. Kvankam mi ĉiam favoras ripozi en komentoj.
Bedaŭrinde, estas multaj terminoj en nia laboro kaj produktoj, do mi ne provos listigi ilin ĉiujn. Nur la plej bazaj kaj necesaj informoj pri sekurkopioj kaj protokoloj por postvivado en la maro. Por tiuj, kiuj interesiĝas, mi povas ankaŭ kolegoj pri sonbendoj, kie li ankaŭ donis liston de terminoj rilataj al tiu parto de la funkcieco.
Gastiganto (Gastiganto): En la mondo de virtualigo, ĉi tio estas maŝino kun hiperviziero. Fizika, virtuala, nuba - ne gravas. Se io funkcias per hiperviziero (ESXi, Hyper-V, KVM ktp), tiam ĉi tiu "io" nomiĝas gastiganto. Ĉu temas pri areto kun dek rakoj aŭ via tekokomputilo kun laboratorio por unu kaj duono virtualaj maŝinoj - se vi lanĉis hiperviziilon, vi fariĝis gastiganto. Ĉar la hiperviziero gastigas virtualajn maŝinojn. Estas eĉ rakonto, ke VMware iam volis atingi firman asocion de la vorto gastiganto kun ESXi. Sed ŝi ne faris.
En la moderna mondo, la koncepto de "gastiganto" praktike kunfandiĝis kun la koncepto de "servilo", kiu alportas iom da konfuzo al komunikado, precipe se temas pri Vindoza infrastrukturo. Do ajna maŝino kiu gastigas iun servon interesan al ni povas esti sekure nomita gastiganto. Ekzemple, en la WinSock protokoloj ĉio estas markita per la vorto gastiganto. La klasika "Gastiganto ne trovita" estas ekzemplo de tio. Do ni komencas de la kunteksto, sed memoru - en la mondo de virtualigo, gastiganto estas kio gastigas gastojn (pli pri tio en du linioj sube).
El loka ĵargono (prefere eĉ akronimoj, ĉi-kaze), oni memoras ĉi tie, ke VMware estas VI, vSphere estas VC kaj Hyper-V estas HV.
Gasto (Gasto): La virtuala maŝino kuranta sur la gastiganto. Estas nenio por klarigi ĉi tie, ĉio estas tiel logika kaj simpla. Tamen multaj diligente trenas ĉi tien iujn aliajn signifojn.
Por kio? Mi ne scias.
Guest OS, respektive, la operaciumo de la gastmaŝino. Kaj tiel plu.
Rezerva/Reprodukta Laboro (laboroA): Pura Wim-ĵargono, indikante kelkajn el la taskoj. Rezerva laboro == Rezerva laboro. Neniu eltrovis kiel traduki ĝin bele en la rusan, do ĉiuj diras "JobA". Kun emfazo sur la lasta silabo.
Jes, ili simple prenas ĝin kaj diras "joba". Kaj eĉ en leteroj oni skribas tiel, kaj ĉio estas en ordo.
Ĉiaj Rezervaj laboroj, Rezervaj Taskoj ktp., dankon, sed ne necesas. Nur laboro, kaj vi estos komprenata. La ĉefa afero estas meti la akcenton sur la lasta silabo.
Sekurkopio (Sekurkopio, sekurkopio. Por veraj oldfags, sekurkopio estas permesita): Krom la evidenta (rezerva kopio de datumoj kuŝantaj ie), ĝi ankaŭ signifas la laboron mem (tri linioj supre, se vi jam forgesis), rezulte de kiu la tre rezerva dosiero aperas. Verŝajne, sinjoroj denaskaj anglalingvanoj estas tro maldiligentaj por diri, ke mi plenumis mian rezervan laboron ĉiufoje, do ili simple diras, ke mi prizorgis mian rezervan, kaj ĉiuj komprenas unu la alian perfekte. Mi invitas vin subteni ĉi tiun mirindan iniciaton.
Plifirmigi (Filimigo): Termino, kiu aperis en ESXi 5.0 Opcio en la momentmenuo, kiu komencas la procezon de forigo de tiel nomataj orfaj fotoj. Tio estas, momentfotoj kiuj estas fizike haveblaj, sed falis el la montrata logika strukturo. Teorie, ĉi tiu procezo ne devus influi la dosierojn montritajn en la momentfotomanaĝero, sed io ajn povas okazi. La esenco de la solidiga procezo estas, ke la datumoj de la momentfoto (infana disko) estas skribitaj al la ĉefa (gepatra) disko. La procezo de kombinado de diskoj nomiĝas kunfandi. Se solidiga komando estis elsendita, tiam la momentfoto-rekordo povas esti forigita de la datumbazo antaŭ ol la momentfoto estas kunfandita kaj forigita. Kaj se la momentfoto ial ne povus esti forigita, tiam aperas ĉi tiuj samaj orfigitaj fotoj. Pri laborado kun momentfotoj, VMware havas . Kaj ni ankaŭ iel pri ili .
Datumbutiko (Stokado aŭ stokado): Tre larĝa koncepto, sed en la mondo de virtualigo, ĝi estas komprenata kiel loko kie virtualaj maŝinaj dosieroj estas stokitaj. Sed ĉiukaze, ĉi tie vi devas kompreni la kuntekston tre klare kaj, kun la plej eta dubo, klarigi kion ĝuste via interparolanto havis en menso.
Prokurilo (Prokurilo): Gravas tuj kompreni, ke Veeam Proxy ne estas tute sama kiel al kio ni kutimas en Interreto. Ene de Veeam-produktoj, ĉi tio estas speco de ento, kiu okupiĝas pri translokado de datumoj de unu loko al alia. Se vi ne eniras detalojn, tiam VBR estas komanda kaj kontrola servilo, kaj prokuriloj estas ĝiaj laborĉevaloj. Tio estas, prokurilo estas maŝino tra kiu trafiko fluas kaj sur kiuj VBR-komponentoj estas instalitaj, kiuj helpas stiri ĉi tiun trafikon. Ekzemple, por transdoni datumojn de unu kanalo al alia, aŭ simple alkroĉi diskojn al si (HotAdd-reĝimo).
Deponejo (Deponejo): Teknike, ĉi tio estas nur eniro en la datumbazo de VBR, indikante la lokon, kie la sekurkopioj estas konservitaj, kaj kiel konekti al ĉi tiu loko. Fakte, ĝi povas esti aŭ nur CIFS-pilko aŭ aparta disko, servilo aŭ sitelo en la nubo. Denove, ni estas en kunteksto, sed ni komprenas, ke deponejo estas nur loko, kie estas viaj sekurkopioj.
Momentfoto (SnapshOt): Oksfordaj gramatikemuloj preferas diri kiu estas momentfoto kaj kiu estas momentfoto, sed la analfabeta plimulto profitas el la pli granda amaso. Se iu ne scias, ĉi tio estas teknologio, kiu permesas restarigi la staton de disko en certa momento. Ĉi tio estas farita aŭ provizore redirektante I/O-operaciojn for de la ĉefdisko - tiam ĝi estos nomita RoW (Redirect on Write) momentfoto - aŭ movante reverkeblajn blokojn de via disko al alia - ĉi tio nomos CoW (Kopiu sur Skribo). ) momentfoto. Estas danke al la larĝaj eblecoj por uzi ĉi tiujn funkciojn ke Veeam povas funkcii sian rezervan magion. Strikte parolante, ne nur ili, sed ĉi tio estas la afero de la venontaj eldonoj.
Estas kaoso ĉirkaŭ ĉi tiu termino en la ESXi-dokumentado kaj protokoloj, kaj en la kunteksto de mencio de momentfotoj, vi povas trovi momentfotojn mem, kaj refari protokolon, kaj eĉ delta disko. La dokumentado de Veeam ne enhavas tian ŝireton, kaj momentfoto estas momentfoto, kaj refari protokolo estas ĝuste REDO-dosiero kreita de sendependa nepersistenta disko. REDO-dosieroj estas forigitaj kiam la virtuala maŝino estas malŝaltita, do konfuzi ilin kun momentfotoj estas vojo al fiasko.
Sintezaj (Sintezaj): Sintezaj sekurkopioj estas inversaj pliigaj kaj eterne antaŭenaj sekurkopioj. Se vi ne renkontis ĉi tiun terminon, ĝi estas nur unu el la mekanismoj uzataj por konstrui rezervan ĉentransformon. Tamen, en la protokoloj vi ankaŭ povas trovi la koncepton de Transformo, kiu estas uzata en la kadro de kreado de plenaj kopioj el pliigoj (sinteza plena).
Tasko (Tasko): Ĉi tiu estas la procezo de prilaborado de ĉiu individua maŝino ene de la laboro. Tio estas: vi havas rezervan laboron, kiu inkluzivas tri maŝinojn. Ĉi tio signifas, ke ĉiu aŭto estos prilaborita kiel parto de aparta tasko. Entute estos kvar protokoloj: la ĉefa por laboroj kaj tri por taskoj. Tamen ĉi tie estas grava nuanco: kun la tempo, la vorto "tasko" fariĝis nenecese ambigua. Kiam ni parolas pri ĝeneralaj protokoloj, ni volas diri, ke tasko estas ĝuste VM. Sed estas "taskoj" kaj sur la prokurilo kaj sur la deponejo. Tie ĝi povas signifi virtualan diskon, virtualan maŝinon kaj la tutan laboron. Tio estas, gravas ne perdi la kuntekston.
Veeam %name% Servo: Por la profito de sukcesaj sekurkopioj, pluraj servoj funkcias samtempe, kies listo troviĝas en la norma ekipaĵo. Iliaj nomoj sufiĉe travideble reflektas sian esencon, sed inter egaluloj estas la plej grava - Veeam Backup Service, sen kiu la resto ne funkcios.
VSS: Teknike, VSS ĉiam devus stari por Microsoft Volume Shadow Copy Service. Fakte, ĝi estas uzata de multaj kiel sinonimo de Apliko-Konscia Bilda Pretigo. Kio, kompreneble, estas kategorie malĝusta, sed ĉi tio estas rakonto el la kategorio "Ĉiu SUV povas esti nomata ĵipo, kaj vi estos komprenata."
Mirindaj ŝtipoj kaj kie ili loĝas
Mi volas komenci ĉi tiun ĉapitron malkaŝante la grandan sekreton - kioma horo estas montrata en la protokoloj?
Memoru:
- ESXi ĉiam skribas protokolojn en UTC+0.
- vCenter konservas protokolojn laŭ la tempo de sia horzono.
- Veeam konservas protokolojn laŭ tempo kaj horzono de la servilo en kiu ĝi estas.
- Kaj nur Vindozaj eventoj en formato EVTX ne suferas de ligado al io ajn. Se malfermite, la tempo estas rekalkulita por la aŭto sur kiu ili estis malfermitaj. La plej oportuna opcio, kvankam estas malfacilaĵoj kun ĝi. La nura palpebla malfacilaĵo estas la diferenco en lokoj. Ĉi tio estas praktike garantiita vojo al nelegeblaj protokoloj. Jes, ekzistas ebloj pri kiel trakti ĉi tion, sed ni simple ne argumentu pri tio, ke ĉio en IT funkcias en la angla, kaj ni konsentu ĉiam agordi la anglan lokaĵon en la serviloj. Ho bonvolu.
Nun ni parolu pri la lokoj kie loĝas la ŝtipoj kaj kiel akiri ilin. En la kazo de VBR, ekzistas du aliroj.
La unua opcio taŭgas se vi ne volas serĉi dosierojn en la ĝenerala amaso, kiuj specife rilatas al via problemo. Por fari tion, ni havas apartan sorĉiston, al kiu vi povas specifi specifan laboron kaj specifan periodon, por kiu vi bezonas protokolojn. Tiam li mem ekzamenos la dosierujojn kaj metos ĉion, kion vi bezonas en unu arkivon. Kie serĉi ĝin kaj kiel labori kun ĝi estas detale priskribitaj en .
Tamen, la sorĉisto ne kolektas la protokolojn de ĉiuj taskoj kaj, ekzemple, se vi bezonas studi la protokolojn de la restarigo, malfunkciigo aŭ malfunkciigo, via vojo kuŝas en la dosierujo. %ProgramData%/Veeam/Backup. Ĉi tio estas la ĉefa VBR-logobutiko kaj %ProgramData% estas kaŝita dosierujo kaj tio estas bone. Cetere, la defaŭlta loko povas esti reasignita uzante la REG_SZ: LogDirectory tipo registra ŝlosilo en la HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Rezerva kaj Replica branĉo.
Sur Linuksaj maŝinoj, protokoloj de laboristaj agentoj devas esti serĉataj en /var/log/VeeamBackup/se vi uzas radikon aŭ sudo-konton. Se vi ne havas tiajn privilegiojn, tiam serĉu ensalutilojn /tmp/VeeamBackup.
Por Veeam agento por %OS_name% protokoloj estu serĉataj %ProgramData%/Veeam/Endpoint (aŭ %ProgramData%/Veeam/Backup/Endpoint) kaj /var/log/veeam laŭe.
Se vi uzas Aplik-Konscian Bildtraktadon (kaj plej verŝajne vi estas), tiam la situacio fariĝas iom pli komplika. Vi bezonos la protokolojn de nia helpanto, kiuj estas konservitaj ene de la virtuala maŝino mem, kaj la VSS-protokolojn. Pri kiel kaj kie akiri ĉi tiun feliĉon, ĝi estas skribita detale en . Kaj kompreneble ekzistas por kolekti la necesajn sistemajn protokolojn.
Vindozaj eventoj estas oportune kolektitaj laŭ . Se vi uzas Hyper-V, aferoj fariĝas pli komplikaj, ĉar vi ankaŭ bezonos ĉiujn ĝiajn protokolojn de la Aplikoj kaj Servaj Protokoloj > Microsoft > Vindoza branĉo. Kvankam vi ĉiam povas iri la pli stultan vojon kaj simple preni ĉiujn objektojn el %SystemRoot%System32winevtLogs.
Se io rompiĝas dum instalado/ĝisdatigo, ĉio, kion vi bezonas, troviĝas en la dosierujo %ProgramData%/Veeam/Setup/Temp. Kvankam mi ne kaŝos la fakton, ke en OS-eventoj vi povas trovi pli utilajn informojn ol en ĉi tiuj protokoloj. La resto de la interesaj kuŝas en %Temp%, sed estas ĉefe instal-protokoloj por rilata programaro, kiel la bazo, .Net-bibliotekoj kaj aliaj aferoj. Notu, ke Veeam estas instalita de msi kaj ĉiuj ĝiaj komponantoj ankaŭ estas instalitaj kiel apartaj msi-pakaĵoj, eĉ se tio ne estis montrita en la GUI. Tial, se la instalado de unu el la komponantoj malsukcesas, la tuta instalado de VBR estos ĉesigita. Sekve, vi devas eniri la ŝtipojn kaj vidi kio precize rompiĝis kaj je kiu punkto.
Kaj finfine, vivhako: se vi ricevas eraron dum instalado, ne rapidu klaki OK. Unue ni prenas la protokolojn, tiam alklaku OK. Tiel vi ricevos protokolon kiu finiĝas je la tempo de la eraro, sen rubo ĉe la fino.
Kaj okazas, ke vi devas eniri la protokolojn de vSphere. La okupo estas tre sendanka, sed, kunvolvinte la manikojn, oni devas fari ion alian. En la plej simpla versio, ni bezonas protokolojn kun virtualaj maŝinaj eventoj vmware.log, kiuj kuŝas apud ĝia .vmx-dosiero. En pli malfacila kazo, malfermu Guglon kaj demandu kie troviĝas la protokoloj por via gastiga versio, ĉar VMware amas ŝanĝi ĉi tiun lokon de eldono al eldono. Ekzemple, , sed por . Por vCenter protokoloj, ripetu la proceduron . Sed ĝenerale, ni interesiĝos pri gastigaj evento-protokoloj hostd.log, gastigaj eventoj administritaj de vCenter vpxa.log, kernaj protokoloj vmkernel.log kaj aŭtentikaj protokoloj auth.log. Nu, en la plej neglektitaj kazoj, la SSO-protokolo, kiu kuŝas en la SSO-dosierujo, povas esti utila.
Maloportuna? Konfuzita? Timiga? Sed ĉi tio ne estas eĉ duono de la informoj, kun kiuj nia subteno funkcias ĉiutage. Do ili estas vere, vere bonegaj.
Veeam Komponantoj
Kaj kiel konkludo de ĉi tiu enkonduka artikolo, ni parolu iomete pri la komponantoj de Veeam Backup & Replication. Ĉar kiam vi serĉas la kaŭzon de doloro, estus bone kompreni kiel funkcias la paciento.
Do, kiel ĉiuj verŝajne scias, Veeam Backup estas tiel nomata SQL-bazita aplikaĵo. Tio estas, ĉiuj agordoj, ĉiuj informoj kaj ĝenerale ĉio, kio estas nur necesa por normala funkciado - ĉio ĉi estas en ĝia datumbazo. Aŭ pli ĝuste, en du datumbazoj, se ni parolas pri amaso da VBR kaj EM: VeeamBackup kaj VeeamBackupReporting, respektive. Kaj tiel okazis: ni metas alian aplikaĵon - aperas alia datumbazo. Por ne konservi ĉiujn ovojn en unu korbo.
Sed por ke ĉi tiu tuta ekonomio funkciu glate, ni bezonas aron da servoj kaj aplikoj, kiuj kunligos ĉiujn komponantojn. Nur kiel ekzemplo, jen kiel ĝi aspektas en unu el miaj laboratorioj:
Agas kiel ĉefdirektisto Veeam Rezerva Servo. Estas li, kiu respondecas pri la interŝanĝo de informoj kun la bazoj. Li ankaŭ respondecas pri lanĉo de ĉiuj taskoj, orkestrado de asignitaj rimedoj kaj laborado kiel speco de komunika centro por diversaj konzoloj, agentoj kaj ĉio alia. Unuvorte, sendube ne ekzistas maniero sen li, sed tio tute ne signifas, ke li faras ĉion mem.
Helpas lin en la plenumo de lia plano Veeam Rezerva Administranto. Ĉi tio ne estas servo, sed ento, kiu lanĉas laborpostenojn kaj kontrolas la procezon de ilia ekzekuto. La labormanoj de rezerva servo, per kiuj ĝi konektas al gastigantoj, kreas momentfotojn, kontrolas retenon, ktp.
Sed revenu al la listo de servoj. Veeam Broker Service. Aperis en v9.5 (kaj ĉi tio ne estas kripta ministo, kiel iuj pensis tiam). Kolektas informojn pri VMware-gastigantoj kaj konservas ĝian gravecon. Sed ne tuj kuru por skribi kolerajn komentojn, ke ni spionas vin kaj likas ĉiujn ensalutojn / pasvortojn al la taschmajor. Ĉio estas iom pli simpla. Kiam vi rulas sekurkopion, la unua afero, kiun vi devas fari, estas konekti al la gastiganto kaj ĝisdatigi ĉiujn datumojn pri ĝia strukturo. Ĉi tio estas sufiĉe malrapida kaj ĝena rakonto. Nur memoru kiom da tempo necesas por vi ensaluti per la retinterfaco, kaj memoru, ke nur la supra tavolo estas kalkulita tie. Kaj tiam vi ankoraŭ bezonas malfermi la tutan hierarkion al la ĝusta loko, cetere. Unuvorte, teruro. Se vi funkcias dekduon da sekurkopioj, tiam ĉiu laboro devas fari ĉi tiun proceduron. Se ni parolas pri grandaj infrastrukturoj, tiam ĉi tiu procezo povas daŭri dek minutojn aŭ pli. Tial oni decidis asigni por tio apartan servon, per kiu eblos ricevi ĉiam aktualajn informojn. Ĉe ekfunkciigo, ĝi kontrolas kaj skanas ĉiujn aldonitajn infrastrukturojn, kaj poste provas funkcii nur je la nivelo de pliigaj ŝanĝoj. Do eĉ se vi kuras cent sekurkopiojn samtempe, ili ĉiuj petos informojn de nia makleristo, kaj ne turmentos la gastigantojn per siaj petoj. Se vi zorgas pri rimedoj, tiam laŭ niaj kalkuloj, 5000 virtualaj maŝinoj bezonas nur ĉirkaŭ 100 Mb da memoro.
Poste ni havas Veeam Konzolo. Li estas Veeam Remote Console, li estas Veeam.Backup.Shell. Ĉi tio estas la sama GUI, kiun ni vidas en la ekrankopioj. Ĉio estas simpla kaj evidenta - la konzolo povas esti lanĉita de ie ajn, kondiĉe ke ĝi estas Vindozo kaj ekzistas konekto al la VBR-servilo. La nura afero, kiun oni povas diri, estas, ke la FLR-procezo montos punktojn loke (t.e. sur la maŝino, kie la konzolo funkcias). Nu, diversaj Veeam Explorers ankaŭ funkcios loke, ĉar ili estas parto de la konzolo. Sed ĝi jam portis min en la sovaĝejon ...
Alia interesa servo estas Veeam Rezerva Katalogo-Datumservo. Konata kiel Veeam Guest Catalog Service en la listo de servoj. Li okupiĝas pri indeksado de dosiersistemoj sur gastmaŝinoj kaj plenigas la dosierujon VBRCatalog per ĉi tiu scio. Ĝi estas uzata nur kie la indeksa markobutono estas ebligita. Kaj nur havas sencon ebligi ĝin se vi havas Enterprise Manager. Tial, konsilo el la fundo de mia koro: ne ŝaltu indeksadon ĝuste tiel, se vi ne havas MANĜI. Ŝparu viajn nervojn kaj subtenu tempon.
Ankaŭ de aliaj gravaj servoj indas noti Veeam Instalilo-Servo, kun la helpo de kiuj la necesaj komponantoj estas liveritaj kaj instalitaj sur prokuriloj, deponejoj kaj aliaj enirejoj. Fakte, ĝi prenas la necesajn .msi-pakaĵojn al la serviloj kaj instalas ilin.
Veeam Data Mover - helpe de helpaj agentoj lanĉitaj sur prokuriloj (kaj ne nur) ĝi okupiĝas pri movo de datumoj. Ekzemple, dum sekurkopio, unu agento legos dosierojn de la gastiga datumvendejo, kaj la dua zorge skribos ilin al la sekurkopio.
Aparte, mi ŝatus noti gravan aferon, pri kiu klientoj ofte reagas - ĉi tio estas la diferenco en versioj de servoj kaj informoj en la programo Programoj kaj Trajtoj. Jes, la listo estos la sama, sed la versioj povas esti tute malkongruaj. Ĝi ne estas tre mojosa el vida vidpunkto, sed estas tute normale se ĉio stabile funkcias. Ekzemple, por la Instalilo-servo, la versio-numero estas multe malantaŭ la najbaraj. Teruro kaj koŝmaro? Ne, ĉar ĝi ne estas tute reinstalita, sed ĝia DLL estas simple ĝisdatigita. En diakilo v9.5 U4, teknika subtena koŝmaro okazis: dum la ĝisdatigo, ĉiuj servoj ricevis novajn versiojn, krom la plej grava. En la flikaĵo U4b, la transportservo preterpasis ĉiujn aliajn je eĉ du versioj (se juĝante laŭ la nombroj). Kaj ĉi tio ankaŭ estas normala - grava cimo estis trovita en ĝi, do ĝi ricevis bonusan ĝisdatigon rilate al la resto. Do por resumi: versiodiferencoj POVAS esti problemo, sed se estas diferenco kaj ĉio funkcias ĝuste, tiam verŝajne devus esti. Sed neniu malpermesas al vi klarigi tion en teknika subteno.
Ĉi tiuj estis la tielnomitaj devigaj aŭ Devigaj servoj. Kaj ekzistas tuta aro da helpaj, kiel Tape Service, Mount Service, vPowerNFS Service ktp.
Por Hyper-V, ĝenerale, ĉio estas la sama, nur ekzistas specifa Veeam Backup Hyper-V Integration Service kaj via propra ŝoforo por labori kun CBT.
Kaj finfine, ni parolu pri kiu laboras sur virtualaj maŝinoj dum sekurkopio. Por ruli antaŭ- kaj post-frostigi skriptojn, krei ombran kopion, kolekti metadatenojn, labori kun SQL-transakciaj protokoloj, ktp. Veeam Gasta Helpanto. Kaj se dosiersistemoj estas indeksitaj, Veeam Gasta Indeksilo . Ĉi tiuj estas provizoraj servoj deplojitaj dum la daŭro de la sekurkopio kaj forigitaj post ĝi.
En la kazo de Linuksaj maŝinoj, ĉio estas multe pli simpla pro la ĉeesto de granda nombro da enkonstruitaj bibliotekoj kaj la kapabloj de la sistemo mem. Ekzemple, indeksado estas farita per mlocate.
Tio estas ĉio por nun
Mi ne plu kuraĝas vundi vin mallonga Mi opinias, ke la enkonduko al la motorsekcio Veeam finiĝis. Jes, ni eĉ ne alproksimiĝis al la kavoj mem, sed kredu min, por ke la informoj en ili prezentitaj ne ŝajnu nekohera konscifluo, tia enkonduko estas nepre necesa. Mi planas iri al la protokoloj mem nur en la tria artikolo, kaj la plano por la sekva estas klarigi kiu generas la protokolojn, kio precize estas montrata en ili kaj kial ĝuste, kaj ne alie.
fonto: www.habr.com
