{"id":97726,"date":"2020-10-21T08:42:15","date_gmt":"2020-10-21T06:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/veeam-log-diving-komponenty-i-glossarij"},"modified":"2020-10-21T08:42:15","modified_gmt":"2020-10-21T06:42:15","slug":"veeam-log-diving-komponenty-i-glossarij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/veeam-log-diving-komponenty-i-glossarij","title":{"rendered":"Veeam Log Diving: komponenter og glosar","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Veeam
\n
\nVi elsker logs hos Veeam. Og da de fleste af vores l\u00f8sninger er modul\u00e6re, skriver de en hel del logs. Da vores omr\u00e5de er at sikre dine data (dvs. give dig ro i sindet), skal logs ikke kun registrere hver lille bev\u00e6gelse, men ogs\u00e5 g\u00f8re det ret detaljeret. Dette er n\u00f8dvendigt, s\u00e5 vi i tilf\u00e6lde af problemer kan forst\u00e5, hvad der skete, hvem der var ansvarlig, og hvad der skal g\u00f8res n\u00e6ste gang. Her g\u00e6lder det samme som i kriminologi: man ved aldrig, hvilken lille detalje der kan hj\u00e6lpe dig med at finde morderen af Laura Palmer.<\/p>\n

Derfor har jeg besluttet at kaste mig over en serie artikler, hvor jeg kronologisk vil fort\u00e6lle om, hvad vi skriver i logs, hvor vi gemmer dem, hvordan man ikke mister besindelsen over deres struktur, og hvad man skal lede efter i dem.
\n<\/a><\/noindex><\/p>\n

Hvorfor en serie artikler, og hvorfor ikke beskrive alt p\u00e5 \u00e9n gang? <\/h3>\n

\nBare at liste, hvilken log der ligger hvor, og hvad der er gemt i den, er en ret h\u00e5bl\u00f8s opgave. Og tanken om at holde denne information opdateret er skr\u00e6mmende. En simpel opstilling af alle mulige logtyper i Veeam Backup & Replication ville v\u00e6re et par sider med lille skrifttype. Og den ville kun v\u00e6re relevant p\u00e5 tidspunktet for offentligg\u00f8relsen, da der ved udgivelsen af den n\u00e6ste patch kan komme nye logs, logikken for de gemte informationer i de gamle kan \u00e6ndre sig osv. Derfor vil det v\u00e6re meget mere fordelagtigt at forklare deres struktur og essensen af den information, de indeholder. Dette vil g\u00f8re det lettere at navigere i stedet for blot at huske navne.<\/p>\n

For ikke at kaste os hovedkulds ind i tekststr\u00e6k, lad os i denne artikel lave noget forberedende arbejde. Derfor vil vi ikke dykke ned i selve logs, men n\u00e6rme os dem fra afstand: vi vil lave et glossar og diskutere strukturen af Veeam set fra loggenerering.<\/p>\n

Glossar og jargon<\/h3>\n

\nHer skal jeg f\u00f8rst undskylde til fortalerne for renheden i det danske sprog og til tilh\u00e6ngerne af O\u017eegov's ordliste. Vi elsker alle vores modersm\u00e5l, men den forbandede IT-industri opererer p\u00e5 engelsk. Det var ikke os, der opfandt det, det er bare s\u00e5dan, det historisk er blevet. Jeg kan ikke lastes for det, han kom selv.<\/p>\n

I vores branche har problemet med anglicismer (og jargon) sin egen specifik karakter. N\u00e5r ord som \"host\" eller \"g\u00e6st\" i hele verden allerede d\u00e6kker over meget konkrete betydninger, forts\u00e6tter der p\u00e5 \u2159 af kloden et heroisk kaos og usikkerhed, hvor folk stikker i ordb\u00f8gerne. Og det strengt n\u00f8dvendige argument er \"Men hos os p\u00e5 arbejdet...\".<\/p>\n

Derudover er der vores egen terminologi, som er specifik for Veeam produkter, selvom nogle ord og vendinger er blevet mere almindelige. Derfor vil vi nu blive enige om, hvad hvert term betyder, og fremover vil jeg under ordet \"g\u00e6st\" referere til det, der er skrevet i dette kapitel, ikke det, du er vant til p\u00e5 dit arbejde. Og ja, det er ikke blot mine personlige pr\u00e6ferencer, det er etablerede begreber i branchen. At k\u00e6mpe imod dem er noget n\u00e6r meningsl\u00f8st. Men jeg er altid for en god diskussion i kommentarerne.<\/p>\n

Desv\u00e6rre er der ekstremt mange termer i vores arbejde og produkter, s\u00e5 jeg vil ikke fors\u00f8ge at opremse dem alle. Kun de mest grundl\u00e6ggende og n\u00f8dvendige for at overleve i havet af information om backup og logs. For dem, der er interesserede, kan jeg ogs\u00e5 tilbyde en artikel <\/a><\/noindex>fra mine kolleger om b\u00e5nd, hvor han ogs\u00e5 f\u00f8rte en liste over termer, der relaterer til den del af funktionaliteten.<\/p>\n

Host:<\/strong> I virtualiseringsverdenen er det en maskine med en hypervisor. Uanset om den er fysisk, virtuel eller i skyen \u2014 det er ligegyldigt. Hvis der k\u00f8rer en hypervisor (ESXi, Hyper-V, KVM etc.) p\u00e5 noget, kaldes det en host. Uanset om det er et cluster med ti rack eller din b\u00e6rbare med en lab, der k\u00f8rer halvanden virtuel maskine \u2014 s\u00e5 l\u00e6nge der k\u00f8rer en hypervisor, er det blevet en host. Fordi hypervisoren hoster virtuelle maskiner. Der er endda en historie om, at VMware engang \u00f8nskede at etablere en st\u00e6rk sammenh\u00e6ng mellem ordet host og netop ESXi. Men det lykkedes dem ikke.<\/p>\n

I dagens verden er begrebet \"host\" praktisk talt blevet synonymt med \"server\", hvilket skaber en vis forvirring i kommunikationen, is\u00e6r n\u00e5r det handler om Windows infrastruktur. Enhver maskine, som har nogen interessant service, kan trygt kaldes en host. For eksempel i WinSock logs er ordet host markeret for alt muligt. Det klassiske \"Host not found\" er et eksempel p\u00e5 dette. S\u00e5 lad os udg\u00e5 fra konteksten, men huske \u2014 i virtualiseringens verden er en host det, der hoster g\u00e6ster (om dette to linjer nedenfor).<\/p>\n

Fra lokale jargon (mere akronymer i dette tilf\u00e6lde) huskes det, at VMware er VI, vSphere er VC, og Hyper-V er HV.<\/p>\n

G\u00e6st (Guest):<\/strong> En virtuel maskine, der k\u00f8rer p\u00e5 en v\u00e6rt. Det er s\u00e5 logisk og simpelt, at der knap er noget at forklare. Men mange insisterer p\u00e5 at bringe andre betydninger ind her. <\/p>\n

Hvorfor? Jeg ved det ikke.
\nGuest OS er derfor operativsystemet p\u00e5 den g\u00e6stemaskine. Og s\u00e5 videre.<\/p>\n

Backup\/Replication Job (job):<\/strong> Ren VMware-jargon, der indikerer en af opgaverne. Backup job == Backup Job. Ingen har fundet en p\u00e6n overs\u00e6ttelse til dansk, s\u00e5 alle siger \"job\". Med tryk p\u00e5 den sidste stavelse.<\/p>\n

Ja, s\u00e5dan tager de bare og siger \"job\". Og selv i e-mails skrives det s\u00e5dan, og alt er fint.
\nDiverse Backup-arbejder, Backup-opgaver osv., tak, men nej tak. Bare job, s\u00e5 forst\u00e5r man det. Det vigtigste er at l\u00e6gge trykket p\u00e5 den sidste stavelse.<\/p>\n

Backup (Backup, bakket op. For de \u00e6gte oldschoolere tillades derivatet \"bakup\"):<\/strong> Udover den \u00e5benlyse (en eller anden backup-kopi af data), betyder det ogs\u00e5 selve jobben (de tre s\u00e6tninger tidligere, hvis man allerede har glemt det), som skaber den \u00f8nskede backup-fil. Sandsynligvis er de engelsktalende for dovne til at sige I ran my backup job hver gang, s\u00e5 de siger bare I ran my backup, og alle forst\u00e5r hinanden glimrende. Jeg foresl\u00e5r, at vi st\u00f8tter dette vidunderlige initiativ.<\/p>\n

Konsolidering (Consolidate): <\/strong>En betegnelse, der opstod i ESXi 5.0 En mulighed i menuen til arbejde med snapshots, der starter processen med at slette de s\u00e5kaldte orphaned snapshots. Det vil sige snapshots, der fysisk eksisterer, men er faldet ud af den synlige logiske struktur. Teoretisk set burde denne proces ikke ber\u00f8re de filer, der vises i snapshots manager, men der sker ofte uventede ting. Essensen af konsolideringsprocessen er, at data fra snapshotet (child disk) skrives tilbage til den prim\u00e6re (parent) disk. Processen med at sl\u00e5 plader sammen kaldes merging. Hvis der er givet en ordre til konsolidering, kan optegnelsen for snapshotet slettes fra databasen tidligere, end det faktiske snapshot er blevet smeltet sammen og slettet. Og hvis snapshotet ikke kunne slettes af en eller anden grund, opst\u00e5r der de s\u00e5kaldte orphaned snapshots. Der er et godt KB hos VMware.<\/a><\/noindex>Og vi har ogs\u00e5 p\u00e5 et tidspunkt skrevet om dem p\u00e5 Habr\u00e9.<\/a><\/noindex>.<\/p>\n

Datastore (Store eller storage): <\/strong>\u00a0Et meget bredt begreb, men inden for virtualisering refererer det til et sted, hvor filer til virtuelle maskiner opbevares. Men uanset hvad, er det vigtigt at forst\u00e5 konteksten meget klart og, ved mindste tvivl, pr\u00e6cisere, hvad din samtalepartner faktisk mente.\u00a0<\/p>\n

Proxy (Proxy): <\/strong>Det er vigtigt straks at forst\u00e5, at Veeam Proxy ikke helt er det samme, som vi er vant til i internettets verden. Inden for Veeam-produkter er det en slags enhed, der h\u00e5ndterer overf\u00f8rslen af data fra et sted til et andet. Uden at g\u00e5 i detaljer er VBR en kommandoserver, mens proxy er dens arbejdsheste. Proxyen er med andre ord en maskine, som trafikken str\u00f8mmer gennem, og hvor de n\u00f8dvendige VBR-komponenter er installeret for at hj\u00e6lpe med at styre denne trafik. For eksempel kan den flytte data fra en kanal til en anden eller blot tilslutte diske (HotAdd mode).<\/p>\n

Repository (Repository): <\/strong>\u00a0Teknisk set er det blot en post i VBR-databasen, der angiver, hvor sikkerhedskopierne opbevares, og hvordan man tilslutter sig dette sted. Faktisk kan det v\u00e6re b\u00e5de en simpel CIFS-share og en separat disk, server eller en bucket i skyen. Igen er det i konteksten, men vi forst\u00e5r, at repository simpelthen er et sted, hvor dine sikkerhedskopier ligger.<\/p>\n

\u00a0Snapshot (Snapshot): <\/strong>Fork\u00e6mperne for Oxford-grammatik foretr\u00e6kker at sige enten sn\u00c9pshot eller sn\u00c4pshot, men den uvidende majoritet vinder ved at v\u00e6re flest. Hvis nogen ikke ved det \u2014 er det en teknologi, der muligg\u00f8r at genskabe diskens tilstand p\u00e5 et bestemt tidspunkt. Dette g\u00f8res enten ved midlertidigt at omdirigere I\/O-operationer v\u00e6k fra den prim\u00e6re disk \u2014 s\u00e5 kaldes det et RoW (Redirect on Write) snapshot \u2014 eller ved at flytte de overskrevne blokke fra din disk til en anden \u2014 s\u00e5 kaldes det et CoW (Copy on Write) snapshot. Netop p\u00e5 grund af de brede anvendelsesmuligheder af disse funktioner kan Veeam udf\u00f8re sin backup-magi. Strengt taget, ikke kun dem, men ogs\u00e5 i de kommende versioner.<\/p>\n

I dokumentationen og loggene for ESXi hersker der kaos omkring dette udtryk, og i konteksten af snapshots kan man st\u00f8de p\u00e5 b\u00e5de snapshots, redo logs og endda delta diske. I Veeam's dokumentation er der ikke s\u00e5danne uoverensstemmelser, og et snapshot er et snapshot, mens redo log er netop REDO-filen, der er oprettet af en uafh\u00e6ngig non-persistent disk. REDO-filer slettes, n\u00e5r den virtuelle maskine slukkes, s\u00e5 at forveksle dem med snapshots er en sikre vej til fiasko.<\/p>\n

Syntetisk (Synthetics):<\/strong> Syntetiske backuper refererer til reverse incremental og forever forward backups. Hvis du ikke har st\u00f8dt p\u00e5 dette udtryk f\u00f8r, s\u00e5 er det blot en af mekanismerne, der anvendes til at bygge omformningen af backupk\u00e6den. Dog kan man i loggene ogs\u00e5 se begrebet Transform, som bruges til at skabe komplette kopier ud fra inkrementer (synthetic full).<\/p>\n

Opgave (Task):<\/strong> Dette er processen med at behandle hver enkelt maskine inden for en job. Det vil sige: hvis du har et backup-job, der inkluderer tre maskiner, vil hver maskine blive behandlet inden for en separat opgave. I alt vil der v\u00e6re fire logfiler: \u00e9n hovedlog for jobbet og tre for opgaverne. Dog er der en vigtig nuance her: over tid er ordet \"opgave\" blevet alt for flertydigt. N\u00e5r vi taler om generelle logfiler, forst\u00e5r vi, at opgaven refererer til den virtuelle maskine. Men der er ogs\u00e5 \"opgaver\" p\u00e5 proxyen og p\u00e5 repositoryet. Der kan det henvise til b\u00e5de en virtuel disk, en virtuel maskine og hele jobbet. S\u00e5 det er vigtigt at bevare konteksten.<\/p>\n

Veeam %name% Service (Service)<\/strong>: \u00a0<\/strong>Til gavn for succesfulde backuper arbejder flere tjenester, hvis liste kan findes i den standard administrative konsol. Deres navne afspejler klart deres essens, men blandt ligestillede er den vigtigste \u2014 Veeam Backup Service, uden hvilken de andre ikke vil fungere.<\/p>\n

VSS: <\/strong>Teknisk set b\u00f8r VSS altid betyde Microsoft Volume Shadow Copy Service. Faktisk bruges det ofte som synonym for Application-Aware Image Processing. Hvilket selvf\u00f8lgelig er helt forkert, men det er en historie af den slags: \"Enhver SUV kan kaldes en jeep, og s\u00e5 forst\u00e5r folk dig.\"<\/p>\n

Fantastiske logfiler og steder, hvor de lever<\/h3>\n

\nJeg vil begynde dette kapitel med at afsl\u00f8re den store hemmelighed \u2014 hvorn\u00e5r vises tiderne i loggene?<\/p>\n

Husk:<\/p>\n