Bij Veeam houden we van logboeken. En aangezien de meeste van onze oplossingen modulair zijn, schrijven ze veel logs. En aangezien de reikwijdte van onze activiteit is om de veiligheid van uw gegevens (d.w.z. een goede nachtrust) te waarborgen, moeten de logboeken niet alleen elke niesbui registreren, maar dit ook tot in detail doen. Dit is nodig zodat in het geval van iets duidelijk is hoe dit "wat" is gebeurd, wie de schuldige is en wat er vervolgens moet gebeuren. Het is net als in de forensische wetenschap: je weet nooit welk klein ding je zal helpen om de moordenaar van Laura Palmer te vinden.
Daarom besloot ik een serie artikelen te lezen, waarin ik achtereenvolgens zal praten over wat we naar de logboeken schrijven, waar we ze opslaan, hoe we niet gek kunnen worden van hun structuur en wat we erin moeten zoeken.
Waarom een serie artikelen en waarom niet alles in één keer beschrijven?
Simpelweg opsommen welk log waar is en wat erin is opgeslagen, is een nogal rampzalige onderneming. En het is eng om er zelfs maar aan te denken om deze informatie up-to-date te houden. Een eenvoudige lijst van alle mogelijke soorten logs in Veeam Backup & Replication is een tabel op verschillende bladen in kleine lettertjes. Ja, en het zal alleen relevant zijn op het moment van publicatie, omdat. wanneer de volgende patch wordt uitgebracht, kunnen er nieuwe logs verschijnen, zal de logica van de opgeslagen informatie in de oude veranderen, enz. Daarom zal het veel winstgevender zijn om hun structuur en de essentie van de informatie die erin staat uit te leggen. Hierdoor kunt u beter door de plaatsen navigeren dan door het banale proppen van namen.
Laten we daarom wat voorbereidend werk doen in dit artikel om niet hals over kop in de pool van tekstvellen te rennen. Daarom gaan we vandaag niet in op de logs zelf, maar gaan we van ver: we zullen een woordenlijst samenstellen en de Veeam-structuur een beetje bespreken in termen van het genereren van logs.
Woordenlijst en jargon
Hier is het allereerst de moeite waard om je excuses aan te bieden aan de voorvechters van de zuiverheid van de Russische taal en de getuigen van het woordenboek van Ozhegov. We houden allemaal heel veel van onze moedertaal, maar de verdomde IT-industrie werkt in het Engels. Nou, we hebben het niet bedacht, maar het is historisch gebeurd. Het is niet mijn schuld, hij kwam zelf (c)
In onze branche heeft het probleem van anglicismen (en jargon) zijn eigen specifieke kenmerken. Wanneer onder onschuldige woorden als "gastheer" of "gast" de hele wereld al lang zeer specifieke dingen heeft begrepen, dan gaat op ⅙ van het land de heroïsche verwarring en het wankelen met het snuffelen in woordenboeken door. En het strikt verplichte argument "Maar op ons werk ...".
Bovendien is er puur onze terminologie, die inherent is aan Veeam-producten, hoewel sommige woorden en zinnen naar de mensen zijn gegaan. Daarom zullen we het nu eens worden over welke term wat betekent, en in de toekomst zal ik onder het woord "gast" precies bedoelen wat er in dit hoofdstuk staat, en niet wat u op het werk gewend bent. En ja, dit is niet mijn persoonlijke gril, dit zijn gevestigde termen in de branche. Ze bestrijden is enigszins zinloos. Hoewel ik altijd voorstander ben van chillen in reacties.
Helaas komen er veel termen voor in ons werk en onze producten, dus ik zal niet proberen ze allemaal op te sommen. Alleen de meest elementaire en noodzakelijke informatie over back-ups en logboeken om te overleven in de zee. Voor geïnteresseerden kan ik dat ook collega's over tapes, waar hij ook een lijst met termen gaf die betrekking hebben op dat deel van de functionaliteit.
Gastheer (Gastheer): In de wereld van virtualisatie is dit een machine met een hypervisor. Fysiek, virtueel, cloud - het maakt niet uit. Als iets een hypervisor draait (ESXi, Hyper-V, KVM enz.), Dan wordt dit "iets" een host genoemd. Of het nu gaat om een cluster met tien racks of je laptop met een lab voor anderhalve virtuele machine - als je een hypervisor lanceerde, werd je een host. Omdat de hypervisor virtuele machines host. Er is zelfs een verhaal dat VMware ooit een sterke associatie van het woord host met ESXi wilde bereiken. Maar dat deed ze niet.
In de moderne wereld is het concept van "host" praktisch versmolten met het concept van "server", wat voor enige verwarring zorgt in de communicatie, vooral als het gaat om de Windows-infrastructuur. Dus elke machine die een voor ons interessante dienst host, kan gerust een host worden genoemd. In de WinSock-logboeken is bijvoorbeeld alles gemarkeerd met het woord host. De klassieker "Host niet gevonden" is hier een voorbeeld van. Dus we gaan uit van de context, maar onthoud - in de wereld van virtualisatie is een gastheer degene die gasten ontvangt (meer hierover in twee regels hieronder).
Uit lokaal jargon (in dit geval zelfs acroniemen) wordt hier in herinnering gebracht dat VMware VI is, vSphere VC en Hyper-V HV.
Gast (Gast): De virtuele machine die op de host draait. Er valt hier niets uit te leggen, alles is zo logisch en eenvoudig. Velen slepen hier echter ijverig een andere betekenis naar toe.
Waarvoor? Ik weet het niet.
Gastbesturingssysteem, respectievelijk, het besturingssysteem van de gastmachine. Enzovoort.
Back-up/replicatietaak (jobA): Puur Wim-jargon, ter aanduiding van enkele taken. Back-uptaak == Back-uptaak. Niemand heeft bedacht hoe het mooi in het Russisch te vertalen, dus iedereen zegt "JobA". Met nadruk op de laatste lettergreep.
Ja, ze nemen het gewoon en zeggen "joba". En zelfs in brieven schrijven ze zo, en alles is in orde.
Alle soorten back-uptaken, back-uptaken, enz., bedankt, maar niet nodig. Gewoon een baan, en je wordt begrepen. Het belangrijkste is om de nadruk te leggen op de laatste lettergreep.
Back-up (Back-up, back-up. Voor echte oldfags is back-up toegestaan): Naast het voor de hand liggende (een back-up van gegevens die ergens liggen), betekent het ook de taak zelf (drie regels hierboven, als je het al bent vergeten), waardoor het back-upbestand verschijnt. Waarschijnlijk zijn heren met Engels als moedertaal te lui om te zeggen dat ik mijn back-uptaak elke keer heb uitgevoerd, dus zeggen ze gewoon dat ik mijn back-up heb uitgevoerd, en iedereen begrijpt elkaar perfect. Ik stel voor om dit prachtige initiatief te steunen.
Consolideren (consolideren): Een term die voorkwam in ESXi 5.0. Een optie in het snapshot-menu waarmee het proces van het verwijderen van zogenaamde verweesde snapshots wordt gestart. Dat wil zeggen snapshots die fysiek beschikbaar zijn, maar buiten de getoonde logische structuur vielen. Theoretisch zou dit proces geen invloed moeten hebben op de bestanden die worden weergegeven in de Snapshot Manager, maar er kan van alles gebeuren. De essentie van het consolidatieproces is dat de gegevens van de momentopname (kindschijf) naar de hoofdschijf (ouderschijf) worden geschreven. Het proces van het combineren van schijven wordt samenvoegen genoemd. Als er een consolidatieopdracht is gegeven, kan het momentopnamerecord uit de database worden verwijderd voordat de momentopname wordt samengevoegd en verwijderd. En als de momentopname om welke reden dan ook niet kon worden verwijderd, verschijnen dezelfde verweesde momentopnamen. Over het werken met snapshots heeft VMware . En we hebben ook op de een of andere manier over hen .
Datastore (Stora of opslag): Een zeer breed concept, maar in de wereld van virtualisatie wordt het opgevat als een plaats waar bestanden van virtuele machines worden opgeslagen. Maar in ieder geval moet u hier de context heel duidelijk begrijpen en bij de minste twijfel verduidelijken wat uw gesprekspartner precies in gedachten had.
Proxy (Proxy): Het is belangrijk om meteen te begrijpen dat Veeam Proxy niet helemaal hetzelfde is als wat we op internet gewend zijn. Binnen Veeam-producten is dit een soort entiteit die zich bezighoudt met het overbrengen van gegevens van de ene plaats naar de andere. Als u niet in details treedt, dan is VBR een commando- en controleserver en zijn proxy's de werkpaarden. Dat wil zeggen, een proxy is een machine waar verkeer doorheen stroomt en waarop VBR-componenten zijn geïnstalleerd die helpen dit verkeer te beheren. Bijvoorbeeld om gegevens van het ene kanaal naar het andere over te dragen, of gewoon om schijven aan zichzelf vast te klampen (HotAdd-modus).
Opslagplaats (opslagplaats): Technisch gezien is dit slechts een invoer in de VBR-database, die aangeeft waar de back-ups zijn opgeslagen en hoe u verbinding kunt maken met deze plek. Het kan in feite gewoon een CIFS-bal zijn of een afzonderlijke schijf, server of bucket in de cloud. Nogmaals, we zijn in context, maar we begrijpen dat een repository slechts een plaats is waar uw back-ups zijn.
Momentopname (SnapshOt): Oxford-grammaticaliefhebbers zeggen liever wie een momentopname is en wie een momentopname, maar de ongeletterde meerderheid profiteert van de grotere massa. Als iemand het niet weet, dit is een technologie waarmee je de toestand van een schijf op een bepaald moment kunt herstellen. Dit wordt gedaan door I / O-bewerkingen tijdelijk weg te leiden van de hoofdschijf - dan wordt het RoW (Redirect on Write) snapshot genoemd - of door herschrijfbare blokken van uw schijf naar een andere te verplaatsen - dit wordt CoW (Copy on Write ) momentopname. Het is dankzij de brede mogelijkheden om deze functies te gebruiken dat Veeam zijn back-upmagie kan gebruiken. Strikt genomen, niet alleen zij, maar dit is de kwestie van de volgende releases.
Er is chaos rond deze term in de ESXi-documentatie en logboeken, en in de context van het vermelden van momentopnamen, kunt u zelf momentopnamen vinden en logboek opnieuw uitvoeren, en zelfs deltadisk. De Veeam-documentatie bevat zo'n traan niet, en een snapshot is een snapshot, en een redo-logboek is precies een REDO-bestand dat is gemaakt door een onafhankelijke niet-persistente schijf. REDO-bestanden worden verwijderd wanneer de virtuele machine is uitgeschakeld, dus verwarren met momentopnamen is een pad naar mislukking.
Synthetisch (kunststof): Synthetische back-ups zijn omgekeerde incrementele en voor altijd voorwaartse back-ups. Voor het geval je deze term nog niet bent tegengekomen, het is slechts een van de mechanismen die worden gebruikt om een back-upketentransformatie te bouwen. In de logboeken kunt u echter ook het concept Transform vinden, dat wordt gebruikt in het kader van het maken van volledige kopieën van incrementen (synthetisch vol).
Taak (Taak): Dit is het proces van het verwerken van elke individuele machine binnen de taak. Dat wil zeggen: u hebt een back-uptaak, waaronder drie machines. Dit betekent dat elke auto wordt verwerkt als onderdeel van een afzonderlijke taak. In totaal zullen er vier logboeken zijn: de belangrijkste voor taken en drie voor taken. Er is hier echter een belangrijke nuance: in de loop van de tijd is het woord "taak" onnodig dubbelzinnig geworden. Als we het hebben over algemene logboeken, bedoelen we dat een taak precies een VM is. Maar er zijn "taken" zowel op de proxy als op de repository. Daar kan het een virtuele schijf, een virtuele machine en de hele taak betekenen. Dat wil zeggen, het is belangrijk om de context niet te verliezen.
Veeam %name%-service: Ten behoeve van succesvolle back-ups werken meerdere services tegelijk, waarvan een lijst in de standaarduitrusting te vinden is. Hun namen weerspiegelen vrij transparant hun essentie, maar onder gelijken is er de belangrijkste: Veeam Backup Service, zonder welke de rest niet zal werken.
VSS: Technisch gezien zou VSS altijd moeten staan voor Microsoft Volume Shadow Copy Service. In feite wordt het door velen gebruikt als synoniem voor Application-Aware Image Processing. Wat natuurlijk absoluut verkeerd is, maar dit is een verhaal uit de categorie "Elke SUV kan een jeep worden genoemd, en je zult worden begrepen."
Fantastische boomstammen en waar ze wonen
Ik wil dit hoofdstuk beginnen met het onthullen van het grote geheim: hoe laat wordt weergegeven in de logboeken?
Herinneren:
- ESXi schrijft logs altijd in UTC+0.
- vCenter houdt logboeken bij volgens de tijd van zijn tijdzone.
- Veeam houdt logboeken bij op tijd en tijdzone van de server waarop het zich bevindt.
- En alleen Windows-gebeurtenissen in EVTX-indeling hebben nergens last van. Bij het openen wordt de tijd opnieuw berekend voor de auto waarop ze zijn geopend. De handigste optie, hoewel er problemen mee zijn. De enige tastbare moeilijkheid is het verschil in locaties. Dit is een praktisch gegarandeerd pad naar onleesbare logboeken. Ja, er zijn opties om dit aan te pakken, maar laten we gewoon niet in discussie gaan met het feit dat alles in IT in het Engels werkt, en afspreken om altijd de Engelse locale op de servers in te stellen. Kom op.
Laten we het nu hebben over de plaatsen waar de logs leven en hoe ze te krijgen. In het geval van VBR zijn er twee benaderingen.
De eerste optie is geschikt als u niet graag wilt zoeken naar bestanden in de algemene stapel die specifiek verband houden met uw probleem. Hiervoor hebben we een aparte wizard, waarin u een specifieke taak kunt opgeven en een specifieke periode waarvoor u logboeken nodig heeft. Dan neemt hij zelf de mappen door en stopt alles wat je nodig hebt in één archief. Waar je ernaar moet zoeken en hoe je ermee kunt werken, wordt in detail beschreven in .
De wizard verzamelt echter niet de logs van alle taken en als u bijvoorbeeld de logs van de restore, failover of failback moet bestuderen, ligt uw pad in de map %ProgramData%/Veeam/Back-up. Dit is de belangrijkste VBR-logostore en %ProgramData% is een verborgen map en dat is prima. Overigens kan de standaardlocatie opnieuw worden toegewezen met behulp van de registersleutel REG_SZ: LogDirectory in de HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication-tak.
Op Linux-machines moet naar logboeken van werkagenten worden gezocht in /var/log/VeeamBackup/als u een root- of sudo-account gebruikt. Als u dergelijke rechten niet heeft, zoek dan naar logins /tmp/VeeamBackup.
Voor Veeam-agent voor %OS_name% moeten logboeken worden doorzocht %ProgramData%/Veeam/Endpoint (Of %ProgramData%/Veeam/Backup/Endpoint) En /var/log/veeam respectievelijk.
Als u Application-Aware Image Processing gebruikt (en hoogstwaarschijnlijk ook), wordt de situatie wat ingewikkelder. U hebt de logboeken van onze helper nodig, die zijn opgeslagen in de virtuele machine zelf, en de VSS-logboeken. Over hoe en waar je dit geluk kunt krijgen, is in detail geschreven . En die is er natuurlijk om de nodige systeemlogboeken te verzamelen.
Windows-gebeurtenissen worden handig verzameld volgens . Als u Hyper-V gebruikt, wordt het ingewikkelder, omdat u ook alle logboeken van de toepassings- en servicelogboeken> Microsoft> Windows-tak nodig hebt. Hoewel je altijd de meer domme weg kunt gaan en gewoon alle objecten van %SystemRoot%System32winevtLogs kunt ophalen.
Als er tijdens de installatie/upgrade iets kapot gaat, vindt u alles wat u nodig hebt in de map %ProgramData%/Veeam/Setup/Temp. Hoewel ik niet zal verbergen dat je in OS-gebeurtenissen meer nuttige informatie kunt vinden dan in deze logboeken. De rest van het interessante ligt in %Temp%, maar er zijn voornamelijk installatielogboeken voor gerelateerde software, zoals de basis, .Net-bibliotheken en andere dingen. Houd er rekening mee dat Veeam wordt geïnstalleerd vanuit msi en dat alle componenten ervan ook als afzonderlijke msi-pakketten worden geïnstalleerd, zelfs als dit niet in de GUI wordt weergegeven. Als de installatie van een van de componenten mislukt, wordt de volledige VBR-installatie daarom stopgezet. Daarom moet u in de logboeken gaan om te zien wat er precies kapot is gegaan en op welk punt.
En tot slot een lifehack: krijg je een foutmelding tijdens de installatie, klik dan niet te snel op OK. Eerst nemen we de logboeken en klikken vervolgens op OK. Op deze manier krijgt u een logboek dat eindigt op het moment van de fout, zonder rommel aan het einde.
En het komt voor dat u in de vSphere-logboeken moet komen. De bezetting is erg ondankbaar, maar na de handen uit de mouwen te hebben gestoken, moet men iets anders doen. In de eenvoudigste versie hebben we logboeken nodig met vmware.log-gebeurtenissen van virtuele machines, die naast het .vmx-bestand liggen. In een moeilijker geval opent u Google en vraagt u waar de logboeken voor uw hostversie zich bevinden, aangezien VMware deze plaats graag van release naar release verandert. Bijvoorbeeld, , maar voor . Herhaal de procedure voor vCenter-logboeken . Maar over het algemeen zullen we geïnteresseerd zijn in hostgebeurtenislogboeken hostd.log, hostgebeurtenissen beheerd door vCenter vpxa.log, kernellogboeken vmkernel.log en authenticatielogboeken auth.log. Welnu, in de meest verwaarloosde gevallen kan het SSO-logboek, dat zich in de SSO-map bevindt, van pas komen.
Moeizaam? Verward? Eng? Maar dit is nog niet eens de helft van de informatie waar onze ondersteuning dagelijks mee werkt. Dus ze zijn echt heel cool.
Veeam-componenten
En als afsluiting van dit inleidende artikel, laten we het even hebben over de componenten van Veeam Backup & Replication. Want als je op zoek gaat naar de oorzaak van pijn, zou het fijn zijn om te begrijpen hoe de patiënt werkt.
Dus, zoals iedereen waarschijnlijk weet, is Veeam Backup een zogenaamde SQL-gebaseerde applicatie. Dat wil zeggen, alle instellingen, alle informatie en in het algemeen alles wat alleen nodig is voor normaal functioneren - dit alles staat in de database. Of beter gezegd, in twee databases, als we het hebben over een heleboel VBR en EM: respectievelijk VeeamBackup en VeeamBackupReporting. En zo gebeurde het: we hebben een andere applicatie geplaatst - er verschijnt een andere database. Om niet alle eieren in één mandje te bewaren.
Maar om al deze economie soepel te laten werken, hebben we een reeks diensten en applicaties nodig die alle componenten met elkaar verbinden. Als voorbeeld, zo ziet het eruit in een van mijn labs:
Treedt op als chef-dirigent Veeam-back-upservice. Hij is degene die verantwoordelijk is voor de uitwisseling van informatie met de bases. Hij is ook verantwoordelijk voor het lanceren van alle taken, het orkestreren van toegewezen bronnen en het werken als een soort communicatiecentrum voor een verscheidenheid aan consoles, agenten en al het andere. Kortom, er is absoluut geen manier zonder hem, maar dit betekent helemaal niet dat hij alles zelf doet.
Helpt hem bij de vervulling van zijn plan Veeam-back-upmanager. Dit is geen service, maar een entiteit die jobs lanceert en het uitvoeringsproces ervan bewaakt. De werkende handen van de back-upservice, waarmee het verbinding maakt met hosts, maakt snapshots, bewaakt retentie, enzovoort.
Maar terug naar de lijst met services. Veeam Broker-service. Verschenen in v9.5 (en dit is geen cryptominer, zoals sommigen toen dachten). Verzamelt informatie over VMware-hosts en onderhoudt de relevantie ervan. Maar ren niet meteen om boze opmerkingen te schrijven dat we je bespioneren en alle logins / wachtwoorden naar de taschmajor lekken. Alles is wat eenvoudiger. Wanneer u een back-up uitvoert, moet u eerst verbinding maken met de host en alle gegevens over de structuur ervan bijwerken. Dit is een nogal traag en omslachtig verhaal. Onthoud gewoon hoe lang het duurt voordat u inlogt via de webinterface en onthoud dat alleen de bovenste laag daar wordt geteld. En dan moet je trouwens nog de hele hiërarchie op de juiste plek openen. In één woord, horror. Als u een dozijn back-ups uitvoert, moet elke taak deze procedure uitvoeren. Als we het hebben over grote infrastructuren, kan dit proces tien minuten of langer duren. Daarom is ervoor gekozen om hiervoor een aparte dienst toe te wijzen, waardoor het mogelijk wordt altijd up-to-date informatie te ontvangen. Bij het opstarten controleert en scant het alle toegevoegde infrastructuur en probeert vervolgens alleen te werken op het niveau van incrementele wijzigingen. Dus zelfs als u honderd back-ups tegelijkertijd uitvoert, zullen ze allemaal om informatie van onze makelaar vragen en de hosts niet lastigvallen met hun verzoeken. Als u zich zorgen maakt over resources, dan hebben 5000 virtuele machines volgens onze berekeningen slechts ongeveer 100 Mb geheugen nodig.
Volgende hebben we Veeam-console. Hij is Veeam Remote Console, hij is Veeam.Backup.Shell. Dit is dezelfde GUI die we zien in de screenshots. Alles is eenvoudig en duidelijk - de console kan overal worden gestart, zolang het maar Windows is en er een verbinding is met de VBR-server. Het enige dat kan worden gezegd, is dat het FLR-proces punten lokaal zal koppelen (d.w.z. op de machine waarop de console draait). Welnu, diverse Veeam Explorers zullen ook lokaal worden uitgevoerd, omdat ze deel uitmaken van de console. Maar het heeft me al de wildernis in gedragen ...
Een andere interessante dienst is Veeam Backup Catalog Data-service. Bekend als Veeam Guest Catalog Service in de lijst met services. Hij houdt zich bezig met het indexeren van bestandssystemen op gastmachines en vult de map VBRCatalog met deze kennis. Het wordt alleen gebruikt als het selectievakje Indexeren is ingeschakeld. En het heeft alleen zin om het in te schakelen als u Enterprise Manager hebt. Daarom een advies uit de grond van mijn hart: zet indexeren niet zomaar aan als je geen EAT hebt. Bespaar je zenuwen en ondersteun tijd.
Ook van andere belangrijke diensten is het vermeldenswaard Veeam-installatieservice, waarmee de benodigde componenten worden geleverd en geïnstalleerd op proxies, repositories en andere gateways. Het brengt in feite de benodigde .msi-pakketten naar de servers en installeert ze.
Veeam-dataverhuizer - met behulp van hulpagenten gelanceerd op proxy's (en niet alleen) is het bezig met het verschuiven van gegevens. Bij het maken van een back-up leest de ene agent bijvoorbeeld bestanden uit de datastore van de host en schrijft de tweede ze zorgvuldig naar de back-up.
Afzonderlijk zou ik iets belangrijks willen opmerken waar klanten vaak op reageren - dit is het verschil in versies van services en informatie in de module Programma's en Functies. Ja, de lijst zal hetzelfde zijn, maar de versies kunnen volledig tegenstrijdig zijn. Visueel gezien is het niet erg cool, maar het is volkomen normaal als alles stabiel werkt. Voor de Installer-service ligt het versienummer bijvoorbeeld ver achter op de naburige. Horror en nachtmerrie? Nee, want het wordt niet volledig opnieuw geïnstalleerd, maar de DLL wordt gewoon bijgewerkt. In patch v9.5 U4 deed zich een technische ondersteuningsnachtmerrie voor: tijdens de update kregen alle services nieuwe versies, behalve de belangrijkste. In de U4b-patch haalde de transportservice alle andere in met maar liefst twee versies (te oordelen naar de cijfers). En dit is ook normaal - er is een ernstige bug in gevonden, dus het heeft een bonusupdate gekregen ten opzichte van de rest. Dus om het samen te vatten: versieverschillen KUNNEN een probleem zijn, maar als er een verschil is en alles werkt naar behoren, dan zou dat waarschijnlijk zo moeten zijn. Maar niemand verbiedt u om dit te verduidelijken in de technische ondersteuning.
Dit waren de zogenaamde verplichte of verplichte diensten. En er zijn een heleboel hulpdiensten, zoals Tape Service, Mount Service, vPowerNFS Service enzovoort.
Voor Hyper-V is in het algemeen alles hetzelfde, alleen is er een specifiek Veeam Backup Hyper-V-integratieservice en je eigen drijfveer voor het werken met CBT.
En laten we het uiteindelijk hebben over wie er op virtuele machines werkt tijdens de back-up. Voor het uitvoeren van pre- en post-freeze-scripts, het maken van een schaduwkopie, het verzamelen van metadata, het werken met SQL-transactielogboeken, enz. Veeam gasthelper. En als bestandssystemen zijn geïndexeerd, Veeam Gastindexer . Dit zijn tijdelijke services die worden ingezet voor de duur van de back-up en daarna worden verwijderd.
In het geval van Linux-machines is alles veel eenvoudiger vanwege de aanwezigheid van een groot aantal ingebouwde bibliotheken en de mogelijkheden van het systeem zelf. Indexering gebeurt bijvoorbeeld via mlocate.
Dat is het voor nu
Ik durf je geen pijn meer te doen kort Ik beschouw de kennismaking met de Veeam-motorruimte als voorbij. Ja, we zijn nog niet eens in de buurt van de holen zelf gekomen, maar geloof me, zodat de informatie die erin wordt gepresenteerd geen onsamenhangende stroom van bewustzijn lijkt, is zo'n introductie absoluut noodzakelijk. Ik ben van plan om pas in het derde artikel naar de logs zelf te gaan, en het plan voor het volgende is om uit te leggen wie de logs genereert, wat er precies in wordt weergegeven en waarom precies, en niet anders.
Bron: www.habr.com