Bij Veeam houden we van logs. Omdat de meeste van onze oplossingen modulair zijn, genereren ze behoorlijk veel logs. Aangezien ons werkterrein de bescherming van uw gegevens is (d.w.z. voor een onbezorgde nachtrust), moeten logs niet alleen elke ademhaling vastleggen, maar dat ook gedetailleerd doen. Dit is nodig om in geval van problemen te begrijpen wat er is gebeurd, wie er verantwoordelijk is, en wat de volgende stappen zijn. Het is net als in de criminologie: je weet nooit welke detail je helpt de moordenaar van Laura Palmer te vinden.
Daarom heb ik besloten een serie artikelen te schrijven waarin ik stapsgewijs uitleg wat we in logs schrijven, waar we ze opslaan, hoe we niet gek worden van hun structuur en wat we erin moeten zoeken.
Waarom een serie artikelen en waarom alles niet in één keer beschrijven?
Gewoon opsommen welke logs waar liggen en wat erin staat, is een behoorlijk zinloze onderneming. En om deze informatie actueel te houden, daar wil je liever niet aan denken. Een eenvoudige opsomming van alle mogelijke logtypen in Veeam Backup & Replication is een tabel met meerdere pagina's in kleine lettertjes. Bovendien zal het alleen actueel zijn op het moment van publicatie, aangezien bij het uitkomen van de volgende patch nieuwe logs kunnen verschijnen en de logica van de opgeslagen informatie in oudere logs kan veranderen, enz. Daarom is het veel beter om hun structuur en de essentie van de informatie die erin staat uit te leggen. Dit helpt om beter te navigeren dan zomaar het onthouden van namen.
Laten we daarom, om niet met het hoofd in de tekstuele wolken te duiken, in dit artikel enige voorbereidende werkzaamheden verrichten. Vandaag gaan we niet in de logs zelf duiken, maar we benaderen het onderwerp van een afstand: we stellen een woordenlijst op en bespreken een beetje de structuur van Veeam vanuit het perspectief van loggeneratie.
Woordenlijst en jargon
Hier wil ik me allereerst verontschuldigen tegenover de voorstanders van de zuiverheid van de Nederlandse taal en de getuigen van de woordenlijst van Ozhigov. We houden allemaal van onze moedertaal, maar de vervloekte IT-industrie werkt in het Engels. Dit is niet iets wat wij hebben bedacht, het is zo ontstaan in de geschiedenis. Het is niet mijn schuld, hij kwam zelf (c)
In ons vakgebied heeft het probleem van anglicismen (en jargon) zijn eigen specificiteit. Wanneer de wereld al lang specifieke dingen verstaat onder onschuldige woorden zoals 'host' of 'gast', gaat het op ⅙ van het werelddeel nog steeds om heldhaftige verwarring en aarzeling met het kijken in woordenboeken. En het strikt noodzakelijke argument is 'Maar bij ons op het werk...'.
Daarnaast hebben we onze eigen terminologie die specifiek is voor Veeam-producten, hoewel sommige woorden en uitdrukkingen gemeengoed zijn geworden. Daarom zullen we nu afspreken wat elke term betekent, en in de toekomst zal ik onder het woord 'gast' precies verstaan wat er in dit hoofdstuk staat, en niet wat je gewend bent op je werk. En ja, dit is geen persoonlijke voorkeur, het zijn gevestigde termen in de industrie. Strijden tegen hen is enigszins zinloos. Maar ik ben altijd in voor een discussie in de opmerkingen.
Helaas zijn er ontzettend veel termen in ons werk en producten, dus ik zal niet proberen ze allemaal op te sommen. Alleen de meest basale en noodzakelijke termen om te overleven in de zee van informatie over back-ups en logs. Voor geïnteresseerden kan ik ook van collega's over tapes voorstellen, waar ook een lijst van termen wordt gegeven die betrekking hebben op dat deel van de functionaliteit.
Host: In de wereld van virtualisatie is dit een machine met een hypervisor. Fysiek, virtueel, cloud — het is onbelangrijk. Als er een hypervisor draait (ESXi, Hyper-V, KVM etc.) op iets, dan wordt dat 'iets' een host genoemd. Of het nu een cluster van tien racks is of je laptop met anderhalve virtuele machine — als je een hypervisor hebt draaien, ben je een host. Omdat de hypervisor virtuele machines host. Er gaat zelfs het verhaal dat VMware ooit een sterke associatie wilde bereiken van het woord host met ESXi. Maar dat is hen niet gelukt.
In de moderne wereld is het begrip 'host' praktisch samengesmolten met het begrip 'server', wat enige verwarring met zich meebrengt, vooral als het gaat om Windows-infrastructuur. Dus elke machine waarop een interessante service voor ons draait, kan gerust een host worden genoemd. Bijvoorbeeld, in de logs van WinSock wordt met het woord host alles gemarkeerd. 'Host not found' is daar een klassiek voorbeeld van. Laten we dus uitgaan van de context, maar onthouden — in de wereld van virtualisatie is een host datgene wat gasten host (daarover verderop in dit document).
Van de lokale jargon (eerder zelfs acroniemen, in dit geval) komt naar voren dat VMware VI is, vSphere VC is en Hyper-V HV is.
Gast (Guest): Een virtuele machine die op de host draait. Hier is het zelfs niet nodig om het uit te leggen, aangezien alles zo logisch en eenvoudig is. Veel mensen proberen echter hier andere betekenissen aan toe te voegen.
Waarom? Ik weet het niet.
Gast-OS, dat wil zeggen, het besturingssysteem van de gastmachine. Ga zo maar door.
Backup/Replication Job (job): Een puur VMware jargon dat een van de taken aanduidt. Backup job == Back-up Job. Hoe je dit op een mooie manier naar het Nederlands kunt vertalen - niemand heeft dat bedacht, dus iedereen zegt 'job'. Met de klemtoon op de laatste lettergreep.
Ja, zo eenvoudig zeggen ze gewoon 'job'. Zelfs in e-mails schrijven ze het zo, en alles is in orde.
Diverse back-up taken, back-up opdrachten, enzovoort, dank je, maar dat hoeft niet. Gewoon job, en men begrijpt je. Het belangrijkste is de klemtoon op de laatste lettergreep leggen.
Backup (Back-up, voor de echte old-timers is bak-up toegestaan): Naast het voor de hand liggende (een reservekopie van gegevens ergens), betekent het ook de job zelf (deze drie regels hierboven, als je het al vergeten bent), waarvan de backupfile voortkomt. Waarschijnlijk zijn de Engelse sprekers te lui om elke keer te zeggen 'Ik heb mijn backup job uitgevoerd', daarom zeggen ze gewoon 'Ik heb mijn backup uitgevoerd', en iedereen begrijpt elkaar uitstekend. Ik stel voor om deze mooie gewoonte te steunen.
Consolidatie (Consolidate): Een term die verscheen in ESXi 5.0. Optie in het menu voor snapshotbeheer, die het proces van het verwijderen van zogenaamde orphaned snapshots opstart. Dit zijn snapshots die fysiek aanwezig zijn, maar uit de weergegeven logische structuur zijn gevallen. Theoretisch gezien zou dit proces de in het snapshotbeheer weergegeven bestanden niet mogen beïnvloeden, maar er gebeurt van alles. De essentie van het consolidatieproces is dat gegevens uit de snapshot (child disk) naar de hoofd (parent) schijf worden geschreven. Het proces van het samenvoegen van schijven wordt mergen genoemd. Als het commando voor consolidatie is gegeven, kan de vermelding van de snapshot uit de database worden verwijderd voordat de snapshot is samengevoegd en verwijderd. En als de snapshot om welke reden dan ook niet kan worden verwijderd, verschijnen die orphaned snapshots. Voor het werken met snapshots heeft VMware een . En we hebben ook ergens over hen .
Datastore (Storage of opslag): Een zeer brede term, maar in de wereld van virtualisatie verwijst het naar de plaats waar de bestanden van virtuele machines worden opgeslagen. Maar in ieder geval moet men de context heel duidelijk begrijpen en bij de minste twijfels verduidelijken wat precies je gesprekspartner bedoelde.
Proxy (Proxy): Het is belangrijk om meteen te begrijpen dat Veeam Proxy niet helemaal hetzelfde is als wat we gewend zijn op het internet. Binnen de producten van Veeam is het een entiteit die zich bezighoudt met het verplaatsen van gegevens van de ene plaats naar de andere. Zonder in details te treden: VBR is de command server en de proxy zijn de werkpaarden. Met andere woorden, de proxy is de machine waar het verkeer doorheen stroomt en waarop de VBR-componenten zijn geïnstalleerd, die helpen dat verkeer te beheren. Bijvoorbeeld, het verplaatsen van gegevens van het ene kanaal naar het andere of gewoon schijven koppelen (HotAdd-modus).
Repository (Repository): Technisch gezien is dit gewoon een record in de VBR-database die aangeeft waar de back-ups zijn opgeslagen en hoe verbinding te maken met die locatie. In feite kan dit een eenvoudige CIFS-share zijn, maar ook een aparte schijf, server of cloudbucket. We bevinden ons weer in de context, maar begrijpen dat een repository gewoon de plaats is waar je back-ups zich bevinden.
Snapshot (Snapshot): Liefhebbers van Oxford-grammatica geven de voorkeur aan zowel 'snÉpshot' als 'snÉpshot, maar de meerderheid van de ongeleerden wint door hun grotere aantal. Als je het niet weet: het is een technologie waarmee de toestand van de schijf op een bepaald moment kan worden hersteld. Dit gebeurt either door tijdelijk I/O-bewerkingen af te leiden van de hoofdschijf — dat wordt een RoW (Redirect on Write) snapshot genoemd — of door overschrijfbare blokken van je schijf naar een andere schijf te verplaatsen — dat heet een CoW (Copy on Write) snapshot. Dankzij de brede mogelijkheden van deze functies kan Veeam zijn back-upmagie tot leven brengen. Strikt genomen niet alleen voor hen, maar dit is het terrein van de komende releases.
In de documentatie en logs van ESXi is er rond deze term veel chaos, en in de context van snapshots kun je zowel snapshots, redo logs als zelfs delta disks tegenkomen. In de Veeam-documentatie is er deze verwarring niet; een snapshot is een snapshot, en een redo log is specifiek het REDO-bestand, gemaakt door een onafhankelijke non-persistent schijf. REDO-bestanden worden verwijderd bij het uitschakelen van de virtuele machine, dus ze met snapshots verwarren is een recept voor falen.
Synthetic: Synthetic backups zijn gerelateerd aan reverse incremental en forever forward backups. Als je deze term nog nooit bent tegengekomen, is het simpelweg een van de mechanismen die worden gebruikt voor het opbouwen van de backupketen. In logs zie je echter ook het begrip Transform, dat wordt gebruikt bij het maken van volledige kopieën uit incrementen (synthetic full).
Task: Dit is het proces van het verwerken van elke individuele machine binnen een job. Dat wil zeggen: als je een backupjob hebt die drie machines omvat, dan wordt elke machine binnen haar eigen taak verwerkt. In totaal zullen er vier logs zijn: één voor de job en drie voor de taken. Er is echter een belangrijke nuance: in de loop der tijd is het woord 'taak' te veel betekenissen gaan hebben. Wanneer we het over algemene logs hebben, bedoelen we dat de taak een VM is. Maar er zijn ook 'taken' op de proxy en de repository. Daar kan het zowel een virtuele schijf, een virtuele machine of de hele job betekenen. Het is dus belangrijk om de context niet te verliezen.
Veeam %name% Service:: Ten behoeve van succesvolle backups werken verschillende services, waarvan de lijst te vinden is in de standaardconsole. Hun namen weerspiegelen duidelijk hun functie, maar onder de gelijken is er één die het belangrijkste is: de Veeam Backup Service, zonder welke de anderen niet zullen functioneren.
VSS: Technisch gezien moet VSS altijd staan voor Microsoft Volume Shadow Copy Service. In de praktijk wordt het door velen als synoniem voor Application-Aware Image Processing gebruikt. Wat, uiteraard, absoluut onjuist is, maar dat is een verhaal als 'Elk terreinvoertuig kan een Jeep worden genoemd, en je wordt begrepen.'
Fantastische logs en de plekken waar ze zich bevinden
Ik wil dit hoofdstuk beginnen met het onthullen van het grote geheim - welke tijd wordt weergegeven in de logs?
Onthoud:
- ESXi schrijft altijd logs in UTC+0.
- vCenter houdt logs bij volgens de tijdzone van zijn eigen tijdzone.
- Veeam houdt logs bij volgens de tijd en tijdzone van de server waarop het draait.
- En alleen Windows-evenementen in EVTX-formaat zijn niet aan iets gebonden. Bij het openen wordt de tijd herschikt naar de machine waarop ze zijn geopend. Dit is de meest handige optie, hoewel er soms ook problemen mee zijn. De enige merkbare moeilijkheid is het verschil in locales. Dit is praktisch gegarandeerd een weg naar onleesbare logs. Ja, er zijn manieren om dit op te lossen, maar laten we gewoon niet discussiëren over het feit dat alles in IT in het Engels werkt, en laten we afspreken om altijd de Engelse locale op servers in te stellen. Alsjeblieft.
Laten we nu toch eens praten over de plaatsen waar logs zich bevinden en hoe je ze kunt krijgen. In het geval van VBR zijn er twee benaderingen.
De eerste optie is geschikt als je niet de drang voelt om in de algemene stapel te zoeken naar bestanden die specifiek verband houden met jouw probleem. Hiervoor hebben we een aparte wizard, waarmee je een specifieke taak en een specifieke periode kunt opgeven waarvoor je logs nodig hebt. Vervolgens doorloopt hij zelf de mappen en verzamelt alles wat nodig is in één archief. Waar je het kunt vinden en hoe je ermee moet werken, staat uitgebreid beschreven in .
Echter, de wizard verzamelt niet de logs van alle taken en bijvoorbeeld, als je de logs van de restaurant-, failover- of failback-taken moet bekijken, ga je naar de map %ProgramData%/Veeam/Backup. Dit is de belangrijkste logopslagplaats van VBR, en %ProgramData% is een verborgen map, dat is normaal. Overigens kan de standaardlocatie worden gewijzigd met behulp van een registersleutel van het type REG_SZ: LogDirectory in de tak HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication.
Op Linux-machines moeten de logs van de werkagenten worden gezocht in /var/log/VeeamBackup/, als je een root- of sudo-account gebruikt. Als je dergelijke privileges niet hebt, zoek dan de logs in /tmp/VeeamBackup.
Voor Veeam agent voor %OS_name% moeten de logs worden gezocht in %ProgramData%/Veeam/Endpoint (of %ProgramData%/Veeam/Backup/Endpoint) en /var/log/veeam respectievelijk.
Als je gebruikmaakt van Application-Aware Image Processing (wat waarschijnlijk het geval is), wordt de situatie iets gecompliceerder. Je hebt de logs van onze helper nodig, die binnen de virtuele machine zijn opgeslagen, en de VSS-logs. Hoe en waar je dit kunt verkrijgen, staat uitgebreid beschreven in . En natuurlijk zijn er voor het verzamelen van de benodigde systeemevenementlogs.
Windows-evenementen zijn handig te verzamelen volgens . Als u Hyper-V gebruikt, wordt het complexer omdat u ook al zijn logs uit de sectie Applications and Service Logs > Microsoft > Windows nodig zult hebben. Hoewel het altijd mogelijk is om de meer rudimentaire weg te kiezen en gewoon alle objecten uit %SystemRoot%System32winevtLogs te halen.
Als er iets kapot gaat tijdens de installatie/upgraden, vindt u alles wat u nodig heeft in de map %ProgramData%/Veeam/Setup/Temp. Hoewel ik niet zal ontkennen dat er meer nuttige informatie in de OS-events te vinden is dan in deze logs. Wat overblijft ligt in %Temp%, maar daar zijn voornamelijk installatie logs van de bijbehorende software, zoals database, .Net bibliotheken en dergelijke. Houd er rekening mee dat Veeam wordt geïnstalleerd vanuit msi, en al zijn componenten ook als afzonderlijke msi-pakketten worden geïnstalleerd, zelfs als dit niet in de GUI wordt weergegeven. Daarom, als de installatie van een van de componenten faalt, wordt de gehele VBR-installatie gestopt. Daarom moet u naar de logs gaan en bekijken wat precies misging en op welk moment.
En een laatste tip: als je een foutmelding krijgt tijdens de installatie, druk dan niet meteen op OK. Verzamel eerst de logs, druk dan pas op OK. Zo ontvangt u een log die eindigt op het moment van de fout, zonder rommel aan het eind.
En soms is het nodig om in de vSphere-logs te kijken. Het is een zeer dankbare taak, maar met de mouwen opgestroopt moet je soms ingewikkeldere dingen doen. In de eenvoudigste variant hebben we de logs met de evenementen van de virtuele machine vmware.log nodig, die zich naast haar .vmx-bestand bevinden. In meer gecompliceerde situaties openen we Google en vragen we waar de logs voor uw versie van de host zich bevinden, want VMware houdt ervan deze locatie van release tot release te veranderen. Hier, bijvoorbeeld, , en hier voor . Voor de vCenter-logs herhalen we de procedure van het . Maar in het algemeen zijn we geïnteresseerd in de logs van de host events hostd.log, de events van hosts onder vCenter vpxa.log, de kernel logs vmkernel.log en de authenticatielogs auth.log. En in de meest extreme gevallen kan de SSO-log, die in de SSO-map ligt, nuttig zijn.
Groot? Verwarrend? Eng? En dit is zelfs niet de helft van de informatie waarmee ons supportteam dagelijks werkt. Dus ze zijn echt heel goed.
Veeam Componenten
En als afsluiting van dit inleidende artikel willen we het een beetje hebben over de componenten van Veeam Backup & Replication. Want wanneer je naar de oorzaak van de problemen zoekt, is het goed om te begrijpen hoe de patiënt in elkaar zit.
Zoals iedereen waarschijnlijk wel weet, is Veeam Backup een zogenaamde SQL-gebaseerde applicatie. Dat wil zeggen, alle instellingen, alle informatie en eigenlijk alles wat nodig is voor een goede werking, bevindt zich in zijn database. Of beter gezegd, in twee databases, als we het hebben over de combinatie van VBR en EM: VeeamBackup en VeeamBackupReporting, respectievelijk. Het gaat zo: we installeren nog een applicatie — er verschijnt nog een database. Om niet al onze eieren in één mand te leggen.
Maar om ervoor te zorgen dat dit geheel soepel draait, hebben we een set diensten en applicaties nodig die alle componenten met elkaar verbinden. Enkel ter illustratie, zo ziet het eruit in een van mijn laboratoria:
In de rol van de belangrijkste dirigent staat Veeam Backup Service. Deze is verantwoordelijk voor de uitwisseling van informatie met de databases. Ook start hij alle taken, is hij verantwoordelijk voor de orkestratie van de toegewezen middelen en fungeert hij als een communicatiewerkplaats voor verschillende consoles, agents en alles wat daar verder bij komt kijken. Kortom, zonder hem kan het echt niet, maar dat betekent absoluut niet dat hij alles alleen doet.
Bij de uitvoering van wat is bedacht, wordt hij geholpen door Veeam Backup Manager. Dit is geen dienst, maar een entiteit die zich bezighoudt met het starten van jobs en het volgen van de voortgang van hun uitvoering. Het zijn de handen van de backup service, waarmee hij verbinding maakt met de hosts, snapshots maakt, het retentiebeheer in de gaten houdt, enzovoort.
Maar laten we terugkeren naar de lijst van diensten. Veeam Broker Service. Dit is geïntroduceerd in v9.5 (en dit is geen cryptominer, zoals sommigen toen dachten). Het verzamelt informatie over VMware-hosts en houdt deze actueel. Maar loop niet meteen weg om woedende opmerkingen te plaatsen dat we je bespioneren en alle inloggegevens / wachtwoorden aan derden doorgeven. Het is allemaal iets eenvoudiger. Wanneer je een back-up start, moet je eerst verbinding maken met de host en alle gegevens over zijn structuur bijwerken. Dit is een vrij traag en omslachtig proces. Denk maar even aan hoe lang de inlogoperatie via de webinterface bij jou duurt, en onthoud dat daar alleen de bovenste laag wordt meegerekend. En dan moet je daarnaast de hele hiërarchie openklappen tot de juiste plek, trouwens. Kortom, verschrikkelijk. Als je een tiental back-ups draait, moet elke job deze procedure doorlopen. Als het gaat om grote infrastructuren, kan dit proces wel tien minuten of langer duren. Daarom is besloten een aparte dienst hiervoor op te zetten, waar je altijd actuele informatie kunt krijgen. Bij de start controleert en scant het de hele toegevoegde infrastructuur, en daarna probeert het alleen op het niveau van incrementele veranderingen te werken. Dus zelfs als je tegelijkertijd honderd back-ups hebt draaien, zullen ze allemaal informatie aanvragen bij onze broker, en niet de hosts belasten met hun verzoeken. Als je je zorgen maakt over de middelen, dan komt onze schatting uit op ongeveer 100 Mb geheugen voor 5000 virtuele machines.
Verder hebben we Veeam Console. Ook bekend als Veeam Remote Console, Veeam.Backup.Shell. Dit is de GUI die we op de schermafbeeldingen zien. Het is simpel en duidelijk - de console kan vanaf elke Windows-machine worden gestart met een verbinding naar de VBR-server. Het enige dat ik kan zeggen is: het FLR-proces monteert punten lokaal (d.w.z. op de machine waar de console draait). En de verschillende Veeam Explorers worden ook lokaal uitgevoerd, omdat ze deel uitmaken van de console. Maar dat leidt me al af…
De volgende interessante dienst is Veeam Backup Catalog Data Service. In de lijst van diensten staat bekend als Veeam Guest Catalog Service. Het is verantwoordelijk voor het indexeren van bestandssystemen op gastmachines en vult de VBRCatalog-map met deze kennis. Het wordt alleen gebruikt wanneer de indexeringsoptie is ingeschakeld. Het inschakelen ervan heeft alleen zin als je een Enterprise Manager hebt. Daarom een welgemeend advies: schakel de indexering niet zomaar in als je geen EM hebt. Bespaar je zenuwen en de tijd van de supportafdeling.
Ook andere belangrijke diensten zijn het vermelden waard, Veeam Installer Service, waarmee de benodigde componenten naar proxy's, repositories en andere gateways worden geleverd en geïnstalleerd. In feite brengt het de nodige .msi-pakketten naar de servers en voert de installatie uit.
Veeam Data Mover — maakt gebruik van op proxies (en niet alleen daar) draaiende hulpgroepen om gegevens over te dragen. Bijvoorbeeld, bij een backup leest de ene agent bestanden van de datastore van de host, terwijl een andere deze zorgvuldig in de backup schrijft.
Een belangrijk punt dat ik vaak van klanten hoor, is het verschil in versies van diensten en informatie in het hulpprogramma Programma's en Onderdelen. Ja, de lijst zal hetzelfde zijn, maar wat betreft de versies kan er een grote discrepantie zijn. Dit is visueel gezien niet ideaal, maar het is helemaal normaal als alles stabiel werkt. Bijvoorbeeld, de versie van de Installer-service loopt aanzienlijk achter op de buren. Een schrikbeeld? Nee, omdat deze niet volledig wordt herinstalleren, maar gewoon zijn DLL wordt bijgewerkt. In patch v9.5 U4 vond er een nachtmerrie voor de technische ondersteuning plaats: bij de update kregen alle diensten nieuwe versies, behalve de belangrijkste. In patch U4b haalde de transportsdienst alle andere met maar liefst twee versies in (als je naar de cijfers kijkt). En dat is ook normaal — er was een ernstige bug gevonden, waardoor het een bonusupdate kreeg in vergelijking met de anderen. Dus, samenvattend: een versieverschil KAN een probleem zijn, maar als het verschil aanwezig is en alles goed werkt, dan is het waarschijnlijk zoals het moet zijn. Maar niemand staat je in de weg om dit bij de technische ondersteuning te bevestigen.
Dit waren de zogenaamde verplichte of Mandatory services. Er zijn ook tal van andere ondersteunende diensten, zoals Tape Service, Mount Service, vPowerNFS Service, enzovoort.
Voor Hyper-V is het in grote lijnen hetzelfde, maar er is een specifieke Veeam Backup Hyper-V Integration Service en zijn eigen stuurprogramma voor het werken met CBT.
En aan het einde zullen we bespreken wie er op virtuele machines werkt tijdens een back-up. Voor het uitvoeren van pre- en post-freeze scripts, het maken van een schaduwkopie, het verzamelen van metadata, het werken met SQL-transactie-logboeken en meer, wordt gebruik gemaakt van Veeam Guest Helper. En als er een indexering van bestandssystemen plaatsvindt, Veeam Guest Indexer . Dit zijn tijdelijke services die worden uitgerold tijdens de back-up en na afloop weer worden verwijderd.
Bij Linux-machines is het veel eenvoudiger vanwege het grote aantal ingebouwde bibliotheken en mogelijkheden van het systeem zelf. Indexering gebeurt bijvoorbeeld via mlocate.
Dat is voorlopig alles
Ik wil u niet langer kwellen en de beknopte inleiding in de interne werking van Veeam beschouw ik als afgerond. Ja, we zijn zelfs niet dicht bij de logs gekomen, maar geloof me, om de informatie die erin staat niet als een onsamenhangende stroom van bewustzijn te laten lijken, is zo'n inleiding absoluut noodzakelijk. Ik ben van plan om pas in het derde artikel naar de logs zelf over te stappen, en het plan voor de volgende is om uit te leggen wie de logs genereert, wat er precies in staat en waarom het zo is en niet anders.
Bron: habr.com
