Ons by Veeam is mal oor logs. En aangesien die meeste van ons oplossings modulêr is, skryf hulle baie logs. En aangesien die omvang van ons aktiwiteit is om die veiligheid van jou data te verseker (d.w.s. rustige slaap), moet die logboeke nie net elke nies aanteken nie, maar dit ook in 'n mate in detail doen. Dit is nodig sodat dit in geval van iets duidelik is hoe hierdie "wat" gebeur het, wie die skuld kry en wat volgende gedoen moet word. Dit is soos in forensiese wetenskap: jy weet nooit watter dingetjie jou sal help om Laura Palmer se moordenaar te vind nie.
Daarom het ek besluit om 'n draai by 'n reeks artikels te maak, waar ek opeenvolgend sal praat oor wat ons aan die stompe skryf, waar ons dit stoor, hoe om nie mal te raak met hul struktuur nie en waarna om binne-in hulle te soek.
Hoekom 'n reeks artikels en hoekom nie alles op een slag beskryf nie?
Om bloot te lys watter log waar is en wat daarin gestoor word, is 'n taamlik rampspoedige onderneming. En dit is skrikwekkend om selfs daaraan te dink om hierdie inligting op datum te hou. 'n Eenvoudige lys van alle moontlike soorte logs in Veeam Backup & Replication is 'n tabel op verskeie velle in kleindruk. Ja, en dit sal slegs relevant wees ten tyde van publikasie, want. wanneer die volgende pleister vrygestel word, kan nuwe logs verskyn, die logika van die gestoorde inligting in die oues sal verander, ens. Daarom sal dit baie meer winsgewend wees om hul struktuur en die essensie van die inligting daarin te verduidelik. Dit sal jou toelaat om die plekke beter te navigeer as die banale propvol name.
Laat ons dus 'n paar voorbereidende werk in hierdie artikel doen, om nie die poel teksvelle in te jaag nie. Daarom gaan ons vandag nie in die logs self in nie, maar gaan van ver af: ons sal 'n woordelys saamstel en die Veeam-struktuur 'n bietjie bespreek in terme van die generering van logs.
Woordelys en jargon
Hier is dit eerstens die moeite werd om verskoning te vra aan die kampvegters van die suiwerheid van die Russiese taal en die getuies van Ozhegov se woordeboek. Ons is almal baie lief vir ons moedertaal, maar die verdomde IT-industrie werk in Engels. Wel, ons het nie daarmee vorendag gekom nie, maar dit het histories gebeur. Dit is nie my skuld nie, hy het self gekom (c)
In ons besigheid het die probleem van anglisismes (en jargon) sy eie besonderhede. Wanneer onder onskuldige woorde soos "gasheer" of "gas" die hele wêreld lankal baie spesifieke dinge verstaan het, dan gaan op ⅙ van die land heldhaftige verwarring en verbystering met inloer in woordeboeke voort. En die streng verpligte argument "Maar by ons werk ...".
Boonop is daar suiwer ons terminologie, wat inherent is aan Veeam-produkte, hoewel sommige woorde en frases na die mense gegaan het. Daarom sal ons nou ooreenkom oor watter term wat beteken, en in die toekoms, onder die woord “gas”, sal ek presies bedoel wat in hierdie hoofstuk geskryf staan, en nie waaraan jy gewoond is by die werk nie. En ja, dit is nie my persoonlike gril nie, dit is goed gevestigde terme in die bedryf. Om teen hulle te veg is ietwat sinneloos. Al is ek altyd ten gunste daarvan om in kommentaar te ontspan.
Ongelukkig is daar baie terme in ons werk en produkte, so ek sal nie probeer om almal te lys nie. Slegs die mees basiese en nodige inligting oor rugsteun en logboeke vir oorlewing in die see. Vir die belangstellendes kan ek ook kollegas oor bande, waar hy ook 'n lys van terme gegee het wat verband hou met daardie deel van die funksionaliteit.
Gasheer (gasheer): In die wêreld van virtualisering is dit 'n masjien met 'n hipervisor. Fisies, virtueel, wolk - dit maak nie saak nie. As iets 'n hypervisor (ESXi, Hyper-V, KVM ens.) bestuur, word hierdie "iets" 'n gasheer genoem. Of dit nou 'n groep met tien rakke is of jou skootrekenaar met 'n laboratorium vir een en 'n half virtuele masjiene - as jy 'n hiperviser bekendgestel het, het jy 'n gasheer geword. Omdat die hypervisor virtuele masjiene huisves. Daar is selfs 'n storie dat VMware op 'n tyd 'n vaste assosiasie van die woord gasheer met ESXi wou bereik. Maar sy het nie.
In die moderne wêreld het die konsep van "gasheer" feitlik saamgesmelt met die konsep van "bediener", wat 'n mate van verwarring by kommunikasie bring, veral wanneer dit by Windows-infrastruktuur kom. So enige masjien wat die een of ander diens van belang vir ons huisves, kan veilig 'n gasheer genoem word. Byvoorbeeld, in die WinSock logs is alles gemerk met die woord gasheer. Die klassieke "Host not found" is 'n voorbeeld hiervan. Ons begin dus by die konteks, maar onthou - in die wêreld van virtualisering is 'n gasheer wat gaste huisves (meer hieroor in twee reëls hieronder).
Uit plaaslike jargon (eerder selfs akronieme, in hierdie geval), word hier onthou dat VMware VI is, vSphere is VC, en Hyper-V is HV.
Gas (Gas): Die virtuele masjien wat op die gasheer loop. Hier is niks om te verduidelik nie, alles is so logies en eenvoudig. Baie mense sleep egter ywerig 'n paar ander betekenisse hierheen.
Vir wat? Ek weet nie.
Gaste-bedryfstelsel, onderskeidelik, die bedryfstelsel van die gasmasjien. En so aan.
Rugsteun/replikasie werk (jobA): Suiwer Wim-jargon, wat sommige van die take aandui. Rugsteun werk == Rugsteun werk. Niemand het uitgepluis hoe om dit pragtig in Russies te vertaal nie, so almal sê "JobA". Met klem op die laaste lettergreep.
Ja, hulle vat dit eenvoudig en sê “joba”. En selfs in briewe skryf hulle so, en alles is reg.
Allerhande rugsteuntake, rugsteuntake, ens., dankie, maar nie nodig nie. Net 'n werk, en jy sal verstaan word. Die belangrikste ding is om die klem op die laaste lettergreep te plaas.
Rugsteun (Rugsteun, rugsteun. Vir ware ou vakke word rugsteun toegelaat): Benewens die ooglopende ('n rugsteunkopie van data wat iewers lê), beteken dit ook die taak self (drie reëls hierbo, as jy reeds vergeet het), as gevolg waarvan die einste rugsteunlêer verskyn. Waarskynlik, here inheemse Engelssprekendes is te lui om te sê ek het my rugsteunwerk elke keer gedoen, so hulle sê net ek het my rugsteun uitgevoer, en almal verstaan mekaar perfek. Ek nooi jou uit om hierdie wonderlike inisiatief te ondersteun.
Konsolideer (Konsolidasie): 'n Term wat in ESXi 5.0 verskyn het. 'n Opsie in die kiekiekieslys wat die proses begin om sogenaamde wees kiekies uit te vee. Dit wil sê, momentopnames wat fisies beskikbaar is, maar uit die vertoonde logiese struktuur geval het. Teoreties behoort hierdie proses nie die lêers wat in die momentopnamebestuurder vertoon word, te beïnvloed nie, maar enigiets kan gebeur. Die kern van die konsolidasieproses is dat die data vanaf die momentopname (kinderskyf) na die hoof (ouer) skyf geskryf word. Die proses om skywe te kombineer word samesmelting genoem. As 'n konsolidasie-opdrag uitgereik is, kan die momentopname-rekord van die databasis verwyder word voordat die momentopname saamgevoeg en uitgevee word. En as die kiekie om enige rede nie uitgevee kon word nie, verskyn hierdie selfde wees kiekies. Oor die werk met foto's, het VMware . En ons ook op een of ander manier oor hulle .
Datastoor (stoor of berging): 'n Baie breë konsep, maar in die wêreld van virtualisering word dit verstaan as 'n plek waar virtuele masjienlêers gestoor word. Maar in elk geval, hier moet jy die konteks baie duidelik verstaan en, met die geringste twyfel, duidelik maak wat presies jou gespreksgenoot in gedagte gehad het.
Volmag (volmag): Dit is belangrik om dadelik te verstaan dat Veeam Proxy nie heeltemal dieselfde is as waaraan ons gewoond is op die internet nie. Binne Veeam-produkte is dit 'n soort entiteit wat te doen het met die oordrag van data van een plek na 'n ander. As jy nie in besonderhede ingaan nie, dan is VBR 'n opdrag- en beheerbediener, en gevolmagtigdes is sy werkesels. Dit wil sê, 'n proxy is 'n masjien waardeur verkeer vloei en waarop VBR-komponente geïnstalleer is wat help om hierdie verkeer te stuur. Byvoorbeeld, om data van een kanaal na 'n ander oor te dra, of bloot om skywe aan homself vas te klou (HotAdd-modus).
Bewaarplek (bewaarplek): Tegnies is dit net 'n inskrywing in die VBR-databasis, wat die plek aandui waar die rugsteun gestoor word, en hoe om aan hierdie plek te koppel. Trouens, dit kan óf net 'n CIFS-bal wees óf 'n aparte skyf, bediener of emmer in die wolk. Weereens, ons is in konteks, maar ons verstaan dat 'n bewaarplek net 'n plek is waar u rugsteun is.
Snapshot (SnapshOt): Oxford grammatika buffs verkies om te sê wie is momentopname en wie is momentopname, maar die ongeletterde meerderheid trek voordeel uit die groter massa. As iemand nie weet nie, is dit 'n tegnologie wat jou toelaat om die toestand van 'n skyf op 'n sekere tydstip te herstel. Dit word gedoen óf deur I/O-bewerkings tydelik van die hoofskyf af te herlei - dan sal dit RoW (Redirect on Write) momentopname genoem word - óf deur herskryfbare blokke van jou skyf na 'n ander te skuif - dit sal CoW (Copy on Write) genoem word ) momentopname. Dit is te danke aan die wye moontlikhede om hierdie funksies te gebruik dat Veeam sy rugsteunmagie kan werk. Streng gesproke, nie net hulle nie, maar dit is die kwessie van die volgende vrystellings.
Daar is chaos rondom hierdie term in die ESXi-dokumentasie en -logboeke, en in die konteks van die noem van foto's, kan jy self foto's vind, en logboek oordoen, en selfs deltaskyf. Die Veeam-dokumentasie bevat nie so 'n skeur nie, en 'n momentopname is 'n momentopname, en 'n oordoen-log is presies 'n REDO-lêer wat deur 'n onafhanklike nie-aanhoudende skyf geskep is. REDO-lêers word uitgevee wanneer die virtuele masjien afgeskakel is, so om dit met momentopnames te verwar is 'n pad na mislukking.
Sinteties (Sintetiese): Sintetiese rugsteun is omgekeerde inkrementele en vir ewig vorentoe rugsteun. As jy nog nie hierdie term teëgekom het nie, is dit net een van die meganismes wat gebruik word om 'n rugsteunkettingtransformasie te bou. In die logs kan jy egter ook die konsep van Transform vind, wat gebruik word in die raamwerk van die skep van volledige kopieë van inkremente (sintetiese vol).
Taak (Taak): Dit is die proses om elke individuele masjien binne die werk te verwerk. Dit wil sê: jy het 'n rugsteuntaak, wat drie masjiene insluit. Dit beteken dat elke motor as deel van 'n aparte taak verwerk sal word. In totaal sal daar vier logs wees: die hoof een vir werk en drie vir take. Hier is egter 'n belangrike nuanse: mettertyd het die woord "taak" onnodig dubbelsinnig geword. Wanneer ons oor algemene logs praat, bedoel ons dat 'n taak presies 'n VM is. Maar daar is "take" beide op die instaanbediener en op die bewaarplek. Daar kan dit 'n virtuele skyf, 'n virtuele masjien en die hele werk beteken. Dit wil sê, dit is belangrik om nie die konteks te verloor nie.
Veeam %name% diens: Vir die voordeel van suksesvolle rugsteun werk verskeie dienste gelyktydig, waarvan 'n lys in die standaardtoerusting gevind kan word. Hul name weerspieël hul wese redelik deursigtig, maar onder gelykes is daar die belangrikste een - Veeam Backup Service, waarsonder die res nie sal werk nie.
VSS: Tegnies moet VSS altyd staan vir Microsoft Volume Shadow Copy Service. Trouens, dit word deur baie gebruik as 'n sinoniem vir toepassingsbewuste beeldverwerking. Wat natuurlik kategories verkeerd is, maar dit is 'n storie uit die kategorie "Enige SUV kan 'n jeep genoem word, en jy sal verstaan word."
Fantastiese houtblokke en waar hulle woon
Ek wil hierdie hoofstuk begin deur die groot geheim te openbaar - hoe laat word in die logboeke vertoon?
Onthou:
- ESXi skryf altyd logs in UTC+0.
- vCenter hou logs volgens die tyd van sy tydsone.
- Veeam hou logboeke volgens tyd en tydsone van die bediener waarop dit is.
- En net Windows-gebeure in EVTX-formaat ly nie aan binding aan enigiets nie. Wanneer dit oopgemaak word, word die tyd herbereken vir die motor waarop hulle oopgemaak is. Die gerieflikste opsie, alhoewel daar probleme daarmee is. Die enigste tasbare probleem is die verskil in plekke. Dit is 'n feitlik gewaarborgde pad na onleesbare logs. Ja, daar is opsies vir hoe om dit te hanteer, maar laat ons net nie stry met die feit dat alles in IT in Engels werk nie, en instem om altyd die Engelse lokaal op die bedieners te stel. Ag asseblief.
Kom ons praat nou oor die plekke waar die stompe woon en hoe om dit te kry. In die geval van VBR is daar twee benaderings.
Die eerste opsie is geskik as jy nie gretig is om lêers in die algemene hoop te soek wat spesifiek met jou probleme verband hou nie. Om dit te doen, het ons 'n aparte towenaar, waarin u 'n spesifieke werk en 'n spesifieke tydperk kan spesifiseer waarvoor u logs benodig. Dan gaan hy self deur die dopgehou en sit alles wat jy nodig het in een argief. Waar om dit te soek en hoe om daarmee te werk, word in detail beskryf in .
Die towenaar versamel egter nie logs van alle take nie en, byvoorbeeld, as jy die logs van herstel, failover of failback moet bestudeer, lê jou pad in die gids %ProgramData%/Veeam/Backup. Dit is die hoof VBR-logowinkel en %ProgramData% is 'n versteekte vouer en dit is goed. Terloops, die verstekligging kan hertoegewys word deur gebruik te maak van die REG_SZ: LogDirectory-tipe registersleutel in die HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Rugsteun en Replikasie tak.
Op Linux-masjiene moet werkeragentlogboeke gesoek word in /var/log/VeeamBackup/as u 'n root- of sudo-rekening gebruik. As jy nie sulke voorregte het nie, soek dan logs in /tmp/VeeamBackup.
Vir Veeam-agent vir %OS_name% moet logs ingesoek word %ProgramData%/Veeam/Eindpunt (Of %ProgramData%/Veeam/Backup/Eindpunt) En /var/log/veeam onderskeidelik.
As jy toepassingsbewuste beeldverwerking gebruik (en heel waarskynlik is jy), dan word die situasie ietwat meer ingewikkeld. U benodig die logs van ons helper, wat in die virtuele masjien self gestoor word, en die VSS-logs. Oor hoe en waar om hierdie geluk te kry, is dit in detail geskryf in . En natuurlik is daar om die nodige stelsellogboeke te versamel.
Windows-geleenthede word gerieflik ingesamel volgens . As jy Hyper-V gebruik, word dinge meer ingewikkeld, want jy sal ook al sy logs van die toepassings en dienslogboeke > Microsoft > Windows-tak benodig. Alhoewel jy altyd die meer dom manier kan gaan en net al die voorwerpe van %SystemRoot%System32winevtLogs optel.
As iets breek tydens installasie/opgradering, kan alles wat jy nodig het in die %ProgramData%/Veeam/Setup/Temp-lêergids gevind word. Alhoewel ek nie die feit sal verberg dat u in OS-gebeure meer nuttige inligting kan vind as in hierdie logs nie. Die res van die interessante lê in %Temp%, maar daar is hoofsaaklik installasie logs vir verwante sagteware, soos die basis, .Net biblioteke en ander dinge. Let daarop dat Veeam vanaf msi geïnstalleer is en al sy komponente word ook as aparte msi-pakkette geïnstalleer, selfs al is dit nie in die GUI gewys nie. As die installering van een van die komponente dus misluk, sal die hele VBR-installasie gestop word. Daarom moet jy in die logs gaan en sien wat presies gebreek het en op watter punt.
En laastens, 'n life hack: as jy 'n fout tydens installasie ontvang, moenie haastig wees om OK te klik nie. Eers neem ons die logs, klik dan OK. Op hierdie manier sal jy 'n log kry wat eindig ten tyde van die fout, sonder vullis aan die einde.
En dit gebeur dat jy by die vSphere-logboeke moet ingaan. Die beroep is baie ondankbaar, maar, nadat jy die moue opgerol het, moet mens iets anders doen. In die eenvoudigste weergawe het ons logs nodig met virtuele masjiengebeurtenisse vmware.log, wat langs sy .vmx-lêer geleë is. In 'n moeiliker geval, maak Google oop en vra waar die logs vir jou gasheerweergawe geleë is, aangesien VMware graag hierdie plek van vrystelling na vrystelling verander. Byvoorbeeld, , maar vir . Vir vCenter-logs, herhaal die prosedure . Maar oor die algemeen sal ons belangstel in gasheergebeurtenislogboeke hostd.log, gasheergebeurtenisse wat deur vCenter vpxa.log bestuur word, kernlogboeke vmkernel.log en verifikasielogboeke auth.log. Wel, in die mees verwaarloosde gevalle kan die SSO-logboek, wat in die SSO-lêergids lê, handig te pas kom.
Omslagtig? Verward? Skrikwekkend? Maar dit is nie eers die helfte van die inligting waarmee ons ondersteuning daagliks werk nie. So hulle is regtig baie cool.
Veeam-komponente
En as 'n afsluiting van hierdie inleidende artikel, kom ons praat 'n bietjie oor die komponente van Veeam Backup & Replication. Want wanneer jy die oorsaak van pyn soek, sal dit lekker wees om te verstaan hoe die pasiënt werk.
So, soos almal waarskynlik weet, is Veeam Backup 'n sogenaamde SQL-gebaseerde toepassing. Dit wil sê, alle instellings, alle inligting en in die algemeen alles wat net nodig is vir normale funksionering - dit alles is in sy databasis. Of eerder, in twee databasisse, as ons van 'n klomp VBR en EM praat: VeeamBackup en VeeamBackupReporting, onderskeidelik. En so het dit gebeur: ons het 'n ander toepassing geplaas - 'n ander databasis verskyn. Om nie al die eiers in een mandjie te stoor nie.
Maar vir al hierdie ekonomie om glad te werk, het ons 'n stel dienste en toepassings nodig wat al die komponente saam sal bind. Net as 'n voorbeeld, dit is hoe dit in een van my laboratoriums lyk:
Tree op as hoofdirigent Veeam-rugsteundiens. Dit is hy wat verantwoordelik is vir die uitruil van inligting met die basisse. Hy is ook verantwoordelik vir die bekendstelling van alle take, die orkestreer van toegekende hulpbronne en werk as 'n soort kommunikasiesentrum vir 'n verskeidenheid konsoles, agente en alles anders. In 'n woord, daar is beslis geen manier sonder hom nie, maar dit beteken glad nie dat hy alles self doen nie.
Help hom in die vervulling van sy plan Veeam-rugsteunbestuurder. Dit is nie 'n diens nie, maar 'n entiteit wat werksgeleenthede bekendstel en die proses van die uitvoering daarvan monitor. Rugsteundiens se werkende hande, waarmee dit aan gashere koppel, skep kiekies, monitor retensie, ensovoorts.
Maar terug na die lys van dienste. Veeam Makelaar Diens. Het in v9.5 verskyn (en dit is nie 'n kripto-mynwerker nie, soos sommige toe gedink het). Versamel inligting oor VMware-gashere en behou die relevansie daarvan. Maar moenie dadelik hardloop om kwaad kommentaar te skryf dat ons op jou spioeneer en alle logins / wagwoorde na die taschmajor uitlek nie. Alles is ietwat eenvoudiger. Wanneer u 'n rugsteun gebruik, is die eerste ding wat u moet doen om aan die gasheer te koppel en alle data oor die struktuur daarvan op te dateer. Hierdie is 'n taamlik stadige en omslagtige storie. Onthou net hoe lank dit neem vir jou om deur die webkoppelvlak aan te meld, en onthou dat slegs die boonste laag daar getel word. En dan moet jy terloops nog die hele hiërargie op die regte plek oopmaak. In 'n woord, afgryse. As jy 'n dosyn rugsteune uitvoer, moet elke taak hierdie prosedure doen. As ons van groot infrastruktuur praat, kan hierdie proses tien minute of meer neem. Daarom is besluit om 'n aparte diens hiervoor toe te ken, waardeur dit moontlik sal wees om altyd bygewerkte inligting te ontvang. By opstart gaan dit alle bygevoegde infrastruktuur na en skandeer dit, en probeer dan om slegs op die vlak van inkrementele veranderinge te werk. So selfs as jy 'n honderd rugsteun op dieselfde tyd hardloop, sal hulle almal inligting van ons makelaar aanvra, en sal nie die gashere met hul versoeke torring nie. As jy bekommerd is oor hulpbronne, dan benodig 5000 virtuele masjiene volgens ons berekeninge slegs ongeveer 100 Mb geheue.
Volgende het ons Veeam-konsole. Hy is Veeam Remote Console, hy is Veeam.Backup.Shell. Dit is dieselfde GUI wat ons in die skermkiekies sien. Alles is eenvoudig en voor die hand liggend - die konsole kan vanaf enige plek bekendgestel word, solank dit Windows is en daar 'n verbinding met die VBR-bediener is. Die enigste ding wat gesê kan word, is dat die FLR-proses punte plaaslik sal monteer (d.w.s. op die masjien waar die konsole loop). Wel, verskeie Veeam Explorers sal ook plaaslik loop, want hulle is deel van die konsole. Maar dit het my reeds die wildernis ingedra ...
Nog 'n interessante diens is Veeam Backup Catalog Data Service. Bekend as Veeam Guest Catalog Service in die lys van dienste. Hy is besig met die indeksering van lêerstelsels op gasmasjiene en vul die VBRCatalog-lêergids met hierdie kennis. Dit word slegs gebruik waar die indekseringsmerkblokkie geaktiveer is. En dit maak net sin om dit te aktiveer as jy Enterprise Manager het. Daarom, raad uit die diepte van my hart: moenie indeksering net so aanskakel as jy nie EAT het nie. Spaar jou senuwees en ondersteun tyd.
Ook van ander belangrike dienste is dit opmerklik Veeam-installeerderdiens, met behulp waarvan die nodige komponente afgelewer en geïnstalleer word op gevolmagtigdes, bewaarplekke en ander poorte. Trouens, dit neem die nodige .msi-pakkette na die bedieners en installeer dit.
Veeam Data Mover - met die hulp van hulpagente wat op gevolmagtigdes geloods is (en nie net nie) is dit besig met die verskuiwing van data. Byvoorbeeld, wanneer u rugsteun, sal een agent lêers van die gasheerdatastoor lees, en die tweede sal dit versigtig na die rugsteun skryf.
Afsonderlik wil ek op 'n belangrike ding let waarop kliënte dikwels reageer - dit is die verskil in weergawes van dienste en inligting in die Programs and Features snap-in. Ja, die lys sal dieselfde wees, maar die weergawes kan heeltemal verskillend wees. Dit is nie baie cool uit 'n visuele oogpunt nie, maar dit is heeltemal normaal as alles stabiel werk. Byvoorbeeld, vir die Installer-diens is die weergawenommer ver agter die naburiges. Gruwel en nagmerrie? Nee, want dit is nie heeltemal weer geïnstalleer nie, maar sy DLL word eenvoudig opgedateer. In patch v9.5 U4 het 'n tegniese ondersteuningsnagmerrie plaasgevind: tydens die opdatering het alle dienste nuwe weergawes ontvang, behalwe vir die belangrikste een. In die U4b-pleister het die vervoerdiens al die ander met soveel as twee weergawes verbygesteek (te oordeel aan die getalle). En dit is ook normaal - 'n ernstige fout is daarin gevind, so dit het 'n bonusopdatering relatief tot die res ontvang. So om dit op te som: weergawe verskille KAN 'n probleem wees, maar as daar 'n verskil is en alles werk behoorlik, dan behoort dit waarskynlik te wees. Maar niemand verbied jou om dit in tegniese ondersteuning te verduidelik nie.
Dit was die sogenaamde verpligte of Verpligte dienste. En daar is 'n hele klomp bykomstiges, soos Tape Service, Mount Service, vPowerNFS Service ensovoorts.
Vir Hyper-V, oor die algemeen, is alles dieselfde, net daar is 'n spesifieke Veeam Backup Hyper-V-integrasiediens en jou bestuurder om met CBT te werk.
En op die ou end, kom ons praat oor wie op virtuele masjiene werk tydens rugsteun. Om voor- en na-vries skrifte uit te voer, 'n skadu-kopie te skep, metadata te versamel, met SQL-transaksielogboeke te werk, ens. Veeam Gas Helper. En as lêerstelsels geïndekseer word, Veeam Guest Indexer . Dit is tydelike dienste wat vir die duur van die rugsteun ontplooi word en daarna verwyder word.
In die geval van Linux-masjiene is alles baie eenvoudiger as gevolg van die teenwoordigheid van 'n groot aantal ingeboude biblioteke en die vermoëns van die stelsel self. Indeksering word byvoorbeeld deur mlocate gedoen.
Dit is al vir nou
Ek durf nie meer jou seermaak nie kort Ek beskou die inleiding tot die Veeam-enjinkompartement as verby. Ja, ons het nog nie eers naby die holtes self gekom nie, maar glo my, sodat die inligting wat daarin aangebied word nie na 'n onsamehangende stroom van bewussyn lyk nie, so 'n inleiding is absoluut noodsaaklik. Ek beplan om eers in die derde artikel na die logs self te gaan, en die plan vir die volgende een is om te verduidelik wie die logs genereer, wat presies daarin vertoon word en hoekom presies, en nie anders nie.
Bron: will.com