Me Veeamissa rakastamme tukia. Ja koska suurin osa ratkaisuistamme on modulaarisia, ne kirjoittavat melko paljon lokeja. Ja koska toimintamme tavoitteena on varmistaa tietojesi turvallisuus (eli levollinen uni), niin lokien tulee paitsi tallentaa jokainen aivastelu, myös tehdä se melko yksityiskohtaisesti. Tämä on välttämätöntä, jotta jos jotain tapahtuu, on selvää, kuinka tämä "mitä" tapahtui, kuka on syyllinen ja mitä on tehtävä seuraavaksi. Se on kuin rikoslääketieteessä: et koskaan tiedä, mikä pieni asia auttaa sinua löytämään Laura Palmerin tappajan.
Siksi päätin käynnistää artikkelisarjan, jossa kerron johdonmukaisesti siitä, mitä kirjoitamme lokeihin, mihin niitä säilytämme, kuinka ei tule hulluksi niiden rakenteeseen ja mitä niiden sisältä kannattaa etsiä.
Miksi artikkelisarja ja miksi ei kuvata kaikkea kerralla?
Yksinkertaisesti luettelemalla, mikä loki sijaitsee ja mitä siihen on tallennettu, on melko tuhoisa idea. Ja on pelottavaa edes ajatella näiden tietojen pitämistä ajan tasalla. Yksinkertainen luettelo kaikista mahdollisista lokityypeistä Veeam Backup & Replication -sovelluksessa on useiden arkkien taulukko pienellä painettuna. Ja se on merkityksellinen vasta julkaisuhetkellä, koska... Kun seuraava korjaustiedosto julkaistaan, uusia lokeja saattaa ilmestyä, vanhoihin tallennettujen tietojen logiikka voi muuttua jne. Siksi on paljon hyödyllisempää selittää niiden rakenne ja niiden sisältämän tiedon olemus. Näin voit navigoida paikoissa paremmin kuin banaalin nimien ahmiminen.
Siksi, jotta et ryntäisi päätä myöten tekstiarkkien joukkoon, tehdään valmistelutyötä tässä artikkelissa. Siksi emme tänään syvenny varsinaisiin tukiin, vaan menemme kaukaa: kokoamme sanaston ja keskustelemme hieman Veeamin rakenteesta tukkien generoinnin näkökulmasta.
Sanasto ja ammattikieltä
Tässä on ensinnäkin syytä pyytää anteeksi venäjän kielen puhtauden mestareilta ja Ožegovin sanakirjan todistajilta. Me kaikki rakastamme äidinkieltämme kovasti, mutta pirun IT-ala toimii englanniksi. No, emme keksineet tätä, mutta näin se tapahtui historiallisesti. Se ei ole minun vikani, hän tuli itse (c)
Liiketoiminnassamme anglismien (ja jargonin) ongelmalla on omat erityispiirteensä. Kun viattomilla sanoilla, kuten "isäntä" tai "vieras", koko maailma on jo pitkään ymmärtänyt hyvin tiettyjä asioita, niin ⅙ maata jatkuu sankarillinen hämmennys ja vaeltaminen sanakirjoissa tökertäen. Ja ehdottomasti pakollinen argumentti "Mutta työssämme...".
Lisäksi on puhtaasti meidän terminologiamme, joka on ominaista nimenomaan Veeam-tuotteille, vaikka joistakin sanoista ja lauseista on tullut suosittuja. Siksi sovimme nyt, mitä termi tarkoittaa, ja tulevaisuudessa sanalla "vieras" tarkoitan juuri sitä, mitä tässä luvussa on kirjoitettu, en sitä, mihin olet tottunut työssä. Ja kyllä, tämä ei ole henkilökohtainen päähänpistoni, nämä ovat alalla vakiintuneita termejä. On vähän turhaa taistella niitä vastaan. Vaikka kannatan aina mukavaa olemista kommenteissa.
Valitettavasti työssämme on paljon termejä ja tuotteita, joten en yritä luetella niitä kaikkia. Vain perustiedot varmuuskopioista ja lokeista, joita tarvitaan selviytymiseen merellä. Kiinnostuneille voin myös kollegoille syötteistä, jossa hän toimitti myös luettelon toiminnon kyseiseen osaan liittyvistä termeistä.
Isäntä: Virtualisoinnin maailmassa tämä on kone, jossa on hypervisor. Fyysinen, virtuaalinen, pilvi – sillä ei ole väliä. Jos jokin käyttää hypervisoria (ESXi, Hyper-V, KVM jne.), tätä "jotain" kutsutaan isänniksi. Olipa kyseessä kymmenen telineen klusteri tai kannettava tietokone, jossa on laboratorio XNUMX virtuaalikoneelle, jos käynnistit hypervisorin, sinusta tuli isäntä. Koska hypervisor isännöi virtuaalikoneita. On jopa tarina, jonka mukaan VMware halusi aikoinaan saada aikaan vahvan assosioinnin sanalle isäntä ESXi:n kanssa. Mutta hän ei voinut tehdä sitä.
Nykymaailmassa käsite "isäntä" on käytännössä sulautunut käsitteeseen "palvelin", mikä tuo tiettyä sekaannusta viestintään, varsinkin kun kyse on Windows-infrastruktuurista. Joten mitä tahansa konetta, jolla jokin meitä kiinnostava palvelu sijaitsee, voidaan kutsua turvallisesti isäntäkoneeksi. Esimerkiksi WinSockin lokeissa kaikki on merkitty sanalla isäntä. Klassinen "Isäntää ei löydy" on esimerkki tästä. Lähdemme siis kontekstista, mutta muista - virtualisoinnin maailmassa isäntä isännöi vieraita (lisätietoja tästä kahdesta rivistä alla).
Paikallisesta ammattikieltä (tässä tapauksessa todennäköisemmin jopa lyhenteet) muistan, että VMware on VI, vSphere on VC ja Hyper-V on HV.
Vieras: Virtuaalikone, joka toimii isännässä. Tässä ei ole edes mitään selitettävää, kaikki on niin loogista ja yksinkertaista. Monet kuitenkin vetävät ahkerasti tänne joitain muita merkityksiä.
Minkä vuoksi? Minä en tiedä.
Vieraskäyttöjärjestelmä on vastaavasti vieraskoneen käyttöjärjestelmä. Ja niin edelleen.
Varmuuskopiointi/replikointityö (jobA): Puhdas Wim-salasana, joka tarkoittaa yhtä tehtävistä. Varmuuskopiointityö == Varmuuskopiointityö. Kukaan ei ole keksinyt kuinka kääntää tämä kauniisti venäjäksi, joten kaikki sanovat "jobA". Viimeistä tavua painottaen.
Kyllä, niin he vain menevät ja sanovat "joba". Ja he jopa kirjoittavat niin kirjeissä, ja kaikki on hyvin.
Kaikenlaiset varmuuskopiointityöt, varmuuskopiointitehtävät jne., kiitos, mutta ei tarvetta. Tee vain työtä, niin he ymmärtävät sinua. Tärkeintä on painottaa viimeinen tavu.
Varmuuskopiointi (Varmuuskopiointi. Varmuuskopiointi on sallittu tosi-oldfageille): Ilmeisen (jossain makaavan datan varmuuskopio) lisäksi se tarkoittaa myös itse työtä (kolme riviä yllä, jos olet jo unohtanut), jonka seurauksena sama varmuuskopiotiedosto ilmestyy. Todennäköisesti, herrat, englanninkieliset ovat liian laiskoja sanomaan, että tein varmuuskopiointityöni joka kerta, joten he vain sanovat, että tein varmuuskopioni, ja kaikki ymmärtävät toisiaan täydellisesti. Ehdotan tämän upean aloitteen tukemista.
Lujittaa: Termi, joka esiintyi ESXi 5.0:ssa Tilannekuvavalikon vaihtoehto, joka käynnistää niin kutsuttujen orpojen tilannekuvien poistamisen. Toisin sanoen tilannekuvia, jotka ovat fyysisesti saatavilla, mutta jotka ovat pudonneet näytetystä loogisesta rakenteesta. Teoriassa tämän prosessin ei pitäisi vaikuttaa tilannekuvanhallinnassa näytettäviin tiedostoihin, mutta mitä tahansa voi tapahtua. Konsolidointiprosessin ydin on, että tilannevedoksen (lapsilevyn) tiedot kirjoitetaan päälevylle (emolevylle). Levyjen yhdistämisprosessia kutsutaan yhdistämiseksi. Jos annettiin konsolidointikomento, tilannekuvatietue voidaan poistaa tietokannasta ennen kuin tilannevedos yhdistetään ja poistetaan. Ja jos tilannekuvaa ei voitu poistaa jostain syystä, nämä samat orvot tilannekuvat tulevat näkyviin. VMwarella on tietoa tilannekuvien kanssa työskentelystä . Ja me myös jotenkin puhumme niistä .
Tietosäilö (Stora tai simtaj): Hyvin laaja käsite, mutta virtualisoinnin maailmassa se viittaa paikkaa, johon virtuaalikoneen tiedostot tallennetaan. Mutta joka tapauksessa sinun on ymmärrettävä erittäin selvästi konteksti ja, jos sinulla on pienintäkään epäilystä, selvennettävä, mitä keskustelukumppanisi tarkalleen tarkoitti.
Välityspalvelin: On tärkeää ymmärtää välittömästi, että Veeam Proxy ei ole täsmälleen sama kuin mihin olemme tottuneet Internetissä. Veeam-tuotteissa tämä on tietty kokonaisuus, joka siirtää tietoja paikasta toiseen. Yksityiskohtiin menemättä VBR on komentopalvelin, ja välityspalvelimet ovat sen työhevosia. Toisin sanoen välityspalvelin on kone, jonka kautta liikenne kulkee ja johon on asennettu VBR-komponentteja, jotka auttavat ohjaamaan tätä liikennettä. Voit esimerkiksi siirtää tietoja kanavalta toiselle tai liittää levyjä itsellesi (HotAdd-tila).
Arkisto: Teknisesti tämä on vain merkintä VBR-tietokannassa, joka osoittaa varmuuskopioiden tallennuspaikan ja yhteyden muodostamisen tähän sijaintiin. Itse asiassa se voi olla joko vain CIFS-jako tai erillinen levy, palvelin tai ämpäri pilvessä. Olemme jälleen kontekstissa, mutta ymmärrämme, että arkisto on vain paikka, jossa varmuuskopiosi sijaitsevat.
Tilannekuva: Oxfordin kieliopin ystävät sanovat mieluummin, kuka on tilannekuva, kuka tilannekuva, mutta lukutaidoton enemmistö voittaa suuremman massan vuoksi. Jos joku ei tiedä, tämä on tekniikka, jonka avulla voit palauttaa levyn tilan tietyllä hetkellä. Tämä tehdään joko ohjaamalla I/O-toiminnot väliaikaisesti pois päälevyltä - sitten tätä kutsutaan RoW (Redirect on Write) -tilannevedoksi - tai siirtämällä uudelleenkirjoitettavat lohkot levyltäsi toiselle - tätä kutsutaan nimellä CoW (Copy on Kirjoita) tilannekuva. Näiden toimintojen laajojen käyttömahdollisuuksien ansiosta Veeam voi tehdä varmuuskopioita. Tarkkaan ottaen, ei vain heille, vaan tämä on kysymys tulevista julkaisuista.
Dokumentaatiossa ja ESXi-lokeissa tämän termin ympärillä vallitsee kaaos, ja tilannekuvien mainitsemisen yhteydessä voit löytää itse otoksia, redo log ja jopa delta-levyn. Veeam-dokumentaatiossa ei ole tällaista ristiriitaa, ja tilannekuva on tilannekuva, ja redo-loki on täsmälleen REDO-tiedosto, jonka on luonut riippumaton ei-pysyvä levy. REDO-tiedostot poistetaan, kun virtuaalikone sammutetaan, joten niiden sekoittaminen tilannekuviin on epäonnistumisen resepti.
Synteettinen: Synteettiset varmuuskopiot viittaavat käänteisiin inkrementaalisiin ja ikuisesti eteenpäin tapahtuviin varmuuskopioihin. Jos et ole törmännyt tähän termiin, se on yksinkertaisesti yksi mekanismeista, joita käytetään varaketjumuunnoksen rakentamiseen. Lokeista löytyy kuitenkin myös Transform-käsite, jota käytetään osana kokonaisten kopioiden luomista lisäyksistä (synteettinen täysi).
Tehtävä: Tämä on jokaisen yksittäisen koneen käsittely työssä. Eli: sinulla on varmuuskopiotyö, joka sisältää kolme konetta. Tämä tarkoittaa, että jokainen kone käsitellään erillisessä tehtävässä. Lokia tulee yhteensä neljä: pääasiallinen työlle ja kolme tehtäville. On kuitenkin tärkeä vivahde: ajan myötä sana "taska" on tullut liian moniselitteiseksi. Kun puhumme yleisistä lokeista, tarkoitamme, että tehtävä on VM. Mutta sekä välityspalvelimella että arkistolla on omat "tehtävänsä". Siellä tämä voi tarkoittaa virtuaalilevyä, virtuaalikonetta tai koko työtä. Eli on tärkeää olla menettämättä kontekstia.
Veeam %name% Palvelu: Onnistuneiden varmuuskopiointien vuoksi toimii useita palveluita kerralla, joista luettelo löytyy vakiovarusteista. Heidän nimensä heijastavat niiden olemusta melko läpinäkyvästi, mutta tasavertaisten joukossa on tärkein - Veeam Backup Service, jota ilman loput eivät toimi.
VSS: Teknisesti VSS:n tulisi aina tarkoittaa Microsoft Volume Shadow Copy Service. Itse asiassa monet käyttävät sitä synonyymina sovellustietoiselle kuvankäsittelylle. Mikä on tietysti kategorisesti väärä, mutta tämä on tarina kategoriasta "Mitä tahansa maastoautoa voidaan kutsua jeepiksi, ja he ymmärtävät sinut."
Upeita hirsiä ja niiden asuinpaikkoja
Haluan aloittaa tämän luvun paljastamalla suuren salaisuuden - mikä aika näkyy lokeissa?
Muistaa:
- ESXi kirjoittaa lokit aina UTC+0:ssa.
- vCenter pitää lokeja aikavyöhykkeensä ajan mukaan.
- Veeam pitää lokeja sen palvelimen ajan ja aikavyöhykkeen perusteella, johon se on asennettu.
- Ja vain tuulitapahtumat EVTX-muodossa eivät kärsi siitä, että ne on sidottu mihinkään. Avattaessa aika lasketaan uudelleen sen koneen mukaan, jolla ne avattiin. Kätevin vaihtoehto, vaikka sen kanssa on vaikeuksia. Ainoa havaittava vaikeus on alueiden ero. Tämä on lähes taattu polku lukukelvottomiin lokeihin. Kyllä, on olemassa vaihtoehtoja tämän hoitamiseen, mutta älkäämme kiistkö sen kanssa, että kaikki IT:ssä toimii englanniksi, ja suostumme asettamaan palvelimille aina englanninkielisen kieliasetuksen. Voi kiitos.
Puhutaanpa nyt paikoista, joissa tukit elävät ja kuinka niitä saa. VBR:n tapauksessa on kaksi lähestymistapaa.
Vaihtoehto yksi sopii, jos et halua etsiä yleisestä kasosta tiedostoja, jotka liittyvät erityisesti ongelmaasi. Tätä varten meillä on erillinen ohjattu toiminto, johon voit määrittää tietyn työn ja tietyn ajanjakson, jolle tarvitset lokeja. Seuraavaksi hän käy kansiot itse läpi ja laittaa kaiken tarvitsemansa yhteen arkistoon. Tietoja siitä, mistä etsiä ja kuinka työskennellä sen kanssa, on kirjoitettu yksityiskohtaisesti .
Ohjattu toiminto ei kuitenkaan kerää lokeja kaikista tehtävistä ja esimerkiksi jos haluat tutkia ravintolan lokeja, vikasietoa tai vikasietoa, polkusi on kansiossa %ProgramData%/Veeam/Varmuuskopio. Tämä on tärkein VBR-lokin tallennustila, ja %ProgramData% on piilotettu kansio, ja se on hyvä. Muuten, oletussijainti voidaan määrittää uudelleen käyttämällä rekisteriavainta, jonka tyyppi on REG_SZ: LogDirectory HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication -haarassa.
Linux-koneissa toimivien agenttien lokit pitäisi löytyä hakemistosta /var/log/VeeamBackup/, jos käytät root- tai sudo-tiliä. Jos sinulla ei ole tällaisia oikeuksia, etsi kirjautumiset /tmp/VeeamBackup.
Veeam-agentille %OS_name%:lle tulee etsiä lokit %ProgramData%/Veeam/päätepiste (tai %ProgramData%/Veeam/Varmuuskopio/päätepiste) Ja /var/log/veeam vastaavasti.
Jos käytät Application-Aware Image Processingia (ja todennäköisesti käytät), tilanne muuttuu hieman monimutkaisemmaksi. Tarvitset avustajalokejamme, jotka on tallennettu itse virtuaalikoneen sisään, ja VSS-lokeja. Kuinka ja mistä saada tämä onnellisuus, on kirjoitettu yksityiskohtaisesti . Ja tietysti on kerätäksesi tarvittavat järjestelmälokit.
Windows-tapahtumien kerääminen on kätevää . Jos käytät Hyper-V:tä, asia muuttuu monimutkaisemmaksi, koska tarvitset myös kaikki sen lokit Sovellukset ja palvelulokit > Microsoft > Windows haarasta. Vaikka voit aina valita typerämmän reitin ja yksinkertaisesti ottaa kaikki objektit %SystemRoot%System32winevtLogsista.
Jos jokin menee rikki asennuksen/päivityksen aikana, kaikki tarvitsemasi löytyy %ProgramData%/Veeam/Setup/Temp-kansiosta. Vaikka en piilota sitä tosiasiaa, että käyttöjärjestelmän tapahtumista löydät enemmän hyödyllistä tietoa kuin näistä lokeista. Loput mielenkiintoiset jutut ovat %Temp%, mutta siellä on pääasiassa asennuslokeja vastaavista ohjelmistoista, kuten tietokannasta, .Net-kirjastoista ja muista asioista. Huomaa, että Veeam asennetaan msi:stä ja kaikki sen komponentit asennetaan myös erillisinä msi-paketteina, vaikka tämä ei näkynyt graafisessa käyttöliittymässä. Siksi, jos jonkin komponentin asennus epäonnistuu, koko VBR-asennus pysähtyy. Siksi sinun on mentävä lokeihin ja katsottava, mikä tarkalleen hajosi ja millä hetkellä.
Ja viimeinen elämänmurto: jos saat virheilmoituksen asennuksen aikana, älä kiirehdi napsauttamaan OK. Otamme ensin lokit ja napsauta sitten OK. Näin saat lokin, joka päättyy virheen hetkellä, ilman roskaa lopussa.
Ja tapahtuu, että sinun on päästävä vSphere-lokeihin. Se on erittäin kiittämätöntä työtä, mutta kun käärii hihat, sinun on tehtävä jotain muuta. Yksinkertaisimmassa versiossa tarvitsemme lokeja virtuaalikoneen tapahtumilla vmware.log, jotka sijaitsevat sen .vmx-tiedoston vieressä. Monimutkaisemmassa tapauksessa avaa Google ja kysy, missä isäntäversiosi lokit ovat, koska VMware rakastaa vaihtaa tätä sijaintia julkaisusta toiseen. Esimerkiksi, , mutta varten . vCenter-lokeille toistamme menettelyn . Yleisesti ottaen olemme kuitenkin kiinnostuneita isäntätapahtumalokeista hostd.log, isäntätapahtumista, joita hallinnoi vCenter vpxa.log, ytimen lokeista vmkernel.log ja todennuslokeista auth.log. Edistyneimmissä tapauksissa kertakirjautumisloki, joka sijaitsee SSO-kansiossa, voi olla hyödyllinen.
Hankalaa? Hämmentynyt? Pelottava? Mutta tämä ei ole edes puolet niistä tiedoista, joita tukimme työskentelee päivittäin. Joten ne ovat todella, todella siistejä.
Veeam komponentit
Tämän johdantoartikkelin päätteeksi puhutaanpa hieman Veeam Backup & Replication -komponenteista. Sillä kun etsit kivun syytä, olisi kiva ymmärtää, miten potilas toimii.
Joten, kuten kaikki luultavasti tietävät, Veeam Backup on niin kutsuttu SQL-pohjainen sovellus. Eli kaikki asetukset, kaikki tiedot ja yleensä kaikki normaaliin toimintaan tarvittava - kaikki tämä on sen tietokannassa. Tai pikemminkin kahdessa tietokannassa, jos puhumme VBR:n ja EM:n yhdistelmästä: VeeamBackup ja VeeamBackupReporting, vastaavasti. Ja niin tapahtui: asennamme toisen sovelluksen - toinen tietokanta ilmestyy. Jotta kaikkia munia ei säilytetä samassa korissa.
Mutta jotta tämä koko yritys toimisi sujuvasti, tarvitsemme joukon palveluita ja sovelluksia, jotka yhdistävät kaikki komponentit yhteen. Esimerkiksi tältä se näyttää yhdessä laboratorioistani:
Toimii ylikapellimestarina Veeam varmuuskopiointipalvelu. Hän on vastuussa tiedonvaihdosta tietokantojen kanssa. Hän vastaa myös kaikkien tehtävien käynnistämisestä, allokoitujen resurssien järjestämisestä ja toimii eräänlaisena viestintäkeskuksena erilaisille konsoleille, agenteille ja kaikelle muulle. Sanalla sanoen, ilman häntä ei ole mitään keinoa, mutta se ei tarkoita ollenkaan, että hän tekisi kaiken itse.
Auttaa häntä toteuttamaan suunnitelmansa Veeam Backup Manager. Tämä ei ole palvelu, vaan kokonaisuus, joka käynnistää töitä ja valvoo niiden toteutusta. Varmuuskopiopalvelun työskentelevät kädet, joiden avulla se muodostaa yhteyden isäntiin, luo tilannekuvia, valvoo säilytystä ja niin edelleen.
Mutta palataanpa palveluluetteloon. Veeam Broker Service. Ilmestyi versiossa 9.5 (ja tämä ei ole krypto-kaivostyö, kuten jotkut silloin luulivat). Kerää tietoa VMware-isännistä ja pitää ne ajan tasalla. Älä kuitenkaan juokse heti kirjoittamaan vihaisia kommentteja siitä, että vakoilemme sinua ja vuodatamme kaikki kirjautumistunnuksesi/salasanasi vetämismajoriin. Kaikki on vähän yksinkertaisempaa. Kun aloitat varmuuskopioinnin, sinun on ensin muodostettava yhteys isäntään ja päivitettävä kaikki tiedot sen rakenteesta. Se on melko hidas ja raskas tarina. Muista vain, kuinka kauan sisäänkirjautuminen verkkokäyttöliittymän kautta kestää, ja muista, että siinä huomioidaan vain ylin kerros. Ja sitten sinun on vielä laajennettava koko hierarkia oikeaan paikkaan. Sanalla sanoen kauhua. Jos käynnistät tusina varmuuskopiota, jokaisen työn on käytävä läpi tämä menettely. Jos puhumme suurista infrastruktuureista, tämä prosessi voi kestää kymmenen minuuttia tai enemmän. Siksi tähän päätettiin osoittaa erillinen palvelu, jonka kautta on mahdollista saada aina ajan tasalla olevaa tietoa. Käynnistettäessä se tarkistaa ja skannaa kaiken lisätyn infrastruktuurin ja yrittää sitten toimia vain vähittäisten muutosten tasolla. Joten vaikka sinulla olisi sata varmuuskopiota käynnissä samanaikaisesti, ne kaikki pyytävät tietoja välittäjältämme eivätkä kiusaa isäntiä pyyntöillään. Jos olet huolissasi resursseista, tarvitset laskelmiemme mukaan 5000 virtuaalikonetta varten vain noin 100 Mt muistia.
Seuraavaksi meillä on Veeam konsoli. Aka Veeam Remote Console eli Veeam.Backup.Shell. Tämä on sama käyttöliittymä, jonka näemme kuvakaappauksissa. Kaikki on yksinkertaista ja ilmeistä - konsoli voidaan käynnistää mistä tahansa, kunhan se on Windows ja siinä on yhteys VBR-palvelimeen. Ainoa asia, joka voidaan sanoa, on, että FLR-prosessi liittää pisteitä paikallisesti (eli koneeseen, jossa konsoli on käynnissä). No, erilaiset Veeam Explorerit toimivat myös paikallisesti, koska ne ovat osa konsolia. Mutta tämä on jo vienyt minut erämaahan...
Seuraava mielenkiintoinen palvelu on Veeam Backup Catalog Data Service. Palveluluettelossa se tunnetaan nimellä Veeam Guest Catalog Service. Hän on mukana indeksoimassa tiedostojärjestelmiä vieraskoneissa ja täyttää VBRCatalog-kansion tällä tiedolla. Käytetään vain, jos indeksointivalintaruutu on käytössä. Ja se on järkevää ottaa käyttöön vain, jos sinulla on Enterprise Manager. Siksi neuvo sydämeni pohjasta: älä ota indeksointia käyttöön vain niin, jos sinulla ei ole EM: tä. Säästä hermojasi ja tukiaikaasi.
Myös muista tärkeistä palveluista kannattaa huomioida Veeam-asennuspalvelu, jonka avulla tarvittavat komponentit toimitetaan ja asennetaan välityspalvelimiin, tietovarastoihin ja muihin yhdyskäytäviin. Itse asiassa hän toimittaa tarvittavat .msi-paketit palvelimille ja asentaa ne.
Veeam Data Mover — välityspalvelimilla (eikä vain) käynnistettyjen apuagenttien avulla se siirtää tietoja. Esimerkiksi varmuuskopioinnin aikana yksi agentti lukee tiedostoja isäntätietosäilöstä ja toinen kirjoittaa ne huolellisesti varmuuskopioon.
Haluaisin erikseen mainita tärkeän asian, johon asiakkaat usein reagoivat - Palveluiden versioiden ja tietojen erot Ohjelmat ja ominaisuudet -laajennuksessa. Kyllä, luettelo on sama, mutta versiot voivat olla täysin epäjohdonmukaisia. Tämä ei ole kovin hienoa visuaalisesta näkökulmasta, mutta on täysin normaalia, jos kaikki toimii vakaasti. Esimerkiksi Installer-palvelun versionumero on paljon jäljessä naapureistaan. Kauhu ja painajainen? Ei, koska sitä ei asenneta kokonaan uudelleen, vaan sen DLL yksinkertaisesti päivitetään. V9.5 U4 -korjauksessa tapahtui teknisen tuen painajainen: päivityksen aikana kaikki palvelut saivat uudet versiot, paitsi tärkein. U4b-patchissa kuljetuspalvelu oli kaikkia muita edellä jopa kahdella versiolla (luvuista päätellen). Ja tämä on myös normaalia - siitä löydettiin vakava bugi, joten se sai bonuspäivityksen muihin verrattuna. Yhteenvetona: versioerot VOIVAT olla ongelma, mutta jos eroa on ja kaikki toimii oikein, niin todennäköisesti sen pitäisi olla. Mutta kukaan ei kiellä sinua selventämään tätä teknisen tuen avulla.
Nämä olivat niin sanottuja pakollisia tai pakollisia palveluita. Ja siellä on koko paketti lisälaitteita, kuten Tape Service, Mount Service, vPowerNFS Service ja niin edelleen.
Hyper-V:lle yleensä kaikki on sama, vain on olemassa tietty Veeam Backup Hyper-V -integraatiopalvelu ja oma ajuri työskentelyyn CBT:n kanssa.
Ja lopuksi puhumme siitä, kuka työskentelee virtuaalikoneissa varmuuskopioinnin aikana. Sitä käytetään esi- ja jälkijäähdytysskriptien suorittamiseen, varjokopioiden luomiseen, metatietojen keräämiseen, SQL-tapahtumalokien käsittelyyn jne. Veeam Vierasapulainen. Ja jos tiedostojärjestelmät on indeksoitu, Veeam Vierasindeksi . Nämä ovat tilapäisiä palveluita, jotka otetaan käyttöön varmuuskopion ajaksi ja poistetaan sen jälkeen.
Linux-koneiden tapauksessa kaikki on paljon yksinkertaisempaa, koska siinä on suuri määrä sisäänrakennettuja kirjastoja ja itse järjestelmän ominaisuuksia. Esimerkiksi indeksointi tehdään mlocaten kautta.
Tässä kaikki tältä erää
En uskalla kiusata sinua enää ja lyhyt Pidän Veeam-moottoritilan esittelyä täydellisenä. Kyllä, emme ole päässeet lähellekään itse lokeja, mutta uskokaa minua, jotta niissä esitetty tieto ei vaikuta epäjohdonmukaiselta tietoisuuden virralta, tällainen esittely on ehdottoman välttämätöntä. Itse lokeihin aion siirtyä vasta kolmannessa artikkelissa, ja seuraavan suunnitelmana on selittää kuka lokit generoi, mitä niissä tarkalleen näytetään ja miksi juuri näin, ei muuten.
Lähde: will.com