Veeam má lásku k logom. A pretože väčšina našich riešení je modulárna, produkujú dosť veľa logov. A keďže našou oblastou činnosti je zabezpečenie uchovania vašich údajov (t.j. kľudného spánku), logy musia nielen zaznamenávať každý dych, ale robiť to aj podrobne. Je to potrebné, aby v prípade problému bolo jasné, ako k tomu došlo, kto za to môže a čo treba robiť ďalej. V tom je to ako v kriminalistike: nikdy nevieš, aký detail ti môže pomôcť nájsť vraha Laury Palmerovej.
Preto som sa rozhodol zamyslieť nad sériou článkov, v ktorých postupne opíšem, čo записujeme do logov, kde ich uchovávame, ako sa nenechať zblázniť z ich štruktúry a čo vlastne hľadať vo vnútri.
Prečo séria článkov a prečo nie opísať všetko naraz?
Jednoducho vymenovať, aký log sa kde nachádza a čo v ňom je, je dosť zložitý projekt. A o udržovaní týchto informácií v aktuálnom stave ani nemám odvahu premýšľať. Jednoduché vymenovanie všetkých možných typov logov vo Veeam Backup & Replication je tabuľka na niekoľko strán drobným písmom. A bude aktuálna len v okamihu publikovania, pretože pri vydaní nasledujúcej opravy môžu pribudnúť nové logy, logika uchovávanej informácie v starých sa môže zmeniť atď. Preto bude oveľa výhodnejšie vysvetliť ich štruktúru a podstatu obsahu. To umožní lepšie sa orientovať na miestach, než len mechanicky sa učiť názvy.
Preto, aby sme sa nevrhli hlboko do textových súžení, poďme v tomto článku vykonať určitú prípravnú prácu. Preto dnes nebudeme preniknúť do samotných logov, ale pristúpime k tomu z diaľky: zostavíme lexikón a trochu prediskutujeme štruktúru Veeam z pohľadu generácie logov.
Lexikón a žargón
Tu by som sa najprv mal ospravedlniť obhajcom čistoty slovenčiny a svedkom Ožegovho slovníka. Všetci milujeme svoj materinský jazyk, ale prekliata IT odvetvie funguje v angličtine. Nuž, my sme to nevymysleli, takto sa to historicky vyvinulo. Nie som na vine, sám prišiel (c)
V našej oblasti má problém anglicizmov (a žargónu) svoju špecifiku. Keď pod nevinnými slovami ako „hostiteľ“ alebo „návštevník“ celý svet už dávno chápe konkrétne veci, na ⅙ časti pevniny pokračuje hrdinský chaos a váhanie s hľadaním slov v slovníkoch. A striktne povinný argument „A u nás v práci…“.
Navyše máme čisto našu terminológiu, ktorá patrí práve produktom Veeam, aj keď niektoré slová a obraty sa dostali do bežného používania. Preto sa teraz dohodneme, aký termín čo znamená, a neskôr pod slovom „návštevník“ budem mať na mysli to, čo je napísané v tejto kapitole, a nie to, čo ste zvyknutí používať vo svojej práci. A áno, nie je to len moja osobná rozmar, sú to ustálené termíny v priemysle. Bojovať s nimi je celkom bezvýznamné. Hoci diskutovať v komentároch som vždy za.
Bohužiaľ, termínov v našej práci a produktoch je veľmi veľa, takže sa nepokúsim vymenovať ich všetky. Iba tie najzákladnejšie a nevyhnutné na prežitie v mori informácií o zálohách a logoch. Zaujímajúcim sa môžem tiež kolegov o pásoch, kde uvádzal aj zoznam termínov, ktoré sa týkajú tej časti funkčnosti.
Hostiteľ (Host): Vo svete virtualizácie je to stroj s hypervízorom. Fyzický, virtuálny, cloudový — nie je podstatné. Ak je na niečom spustený hypervízor (ESXi, Hyper-V, KVM atď.), tak to „niečo“ sa nazýva hostiteľom. Nech je to klastra na desať rackov alebo váš laptop s domácou laboratóriou na poltucet virtuálnych strojov — ak ste spustili hypervízor, stali ste sa hostiteľom. Pretože hypervízor hostí virtuálne stroje. Existuje dokonca legende, že VMware sa kedysi snažila dosiahnuť pevnú asociáciu slova hostiteľ práve s ESXi. Ale nezvládli to.
V modernom svete sa pojem „hostiteľ“ prakticky zliaty s pojmom „server“, čo vnáša určitú zmätok do komunikácie, najmä ak hovoríme o infraštruktúre Windows. Takže akýkoľvek stroj, na ktorom sa nachádza nejaká pre nás zaujímavá služba, môže byť smelo nazvaný hostiteľom. Napríklad, v logoch WinSock je slovo host označené na všetko. Klasické „Host not found“ je toho príkladom. Takže vychádzame z kontextu, ale pamätáme — vo svete virtualizácie hostiteľ je to, čo hostí návštevníkov (o tom o dve riadky nižšie).
Z lokálnych žargónov (skôr akronymov, v tomto prípade) si spomíname, že VMware je VI, vSphere je VC a Hyper-V je HV.
Host (Heslo): Virtuálny stroj bežiaci na hostiteľovi. Tu ani nie je potrebné vysvetľovať, je to všetko tak logické a jednoduché. Napriek tomu mnohí sem ťahajú nejaké iné významy.
Prečo? Neviem.
Hostiteľský OS, teda operačný systém hostiteľského stroja. A tak ďalej.
Zálohovanie/Replikácia úloha (job): Čisto v VMware žargón, označujúci jednu z úloh. Backup job == Zálohovací job. Ako to pekne preložiť do slovenčiny — nikto nevymyslel, preto všetci hovoria „job“. S dôrazom na poslednú slabiku.
Áno, tak jednoducho vezmú a povedia „job“. A dokonca aj v listoch to píšu, a všetko je v poriadku.
Rôzne zálohovacie práce, Zálohovacie úlohy atď., ďakujem, ale nie. Jednoducho job, a pochopia vás. Hlavné je dať dôraz na poslednú slabiku.
Záloha (Backup, bkp. Pre trúbkových oldfagov je povolené aj bakUp): Okrem očividného (niekde ležiaca záložná kópia dát) znamená aj samotnú úlohu (tri riadky vyššie, ak ste už zabudli), v dôsledku ktorej vznikne tá zálohovaná súbor. Pravdepodobne anglickí rodení hovoriaci sú príliš leniví, aby každý raz hovorili I ran my backup job, preto jednoducho hovoria I ran my backup a všetci sa navzájom skvele rozumejú. Navrhujem podporiť tento skvelý projekt.
Konsolidácia (Consolidate): Termín, ktorý sa objavil vo verzii ESXi 5.0 Možnosť v menu práce so snapshotmi, spúšťajúca proces odstránenia takzvaných orphaned snapshotov. Teda snapshotov, ktoré fyzicky existujú, ale vypadli z zobrazovanej logickej štruktúry. Teoreticky by tento proces nemal zasiahnuť súbory zobrazené v manažéri snapshotov, ale stáva sa všeličo. Podstata procesu konsolidácie spočíva v tom, že dáta zo snapshotu (child disk) sú zapísané do hlavného (parent) disku. Proces zlučovania diskov sa nazýva merge. Ak bola odovzdaná príkaz na konsolidáciu, môže byť záznam o snapshotu odstránený z databázy skôr, než bude snapshot zlúčený a odstránený. A ak sa snapshot z akéhokoľvek dôvodu nepodarilo odstrániť, objavia sa tieto orphaned snapshoty. O práci so snapshotmi má VMware . A my sme tiež raz o nich .
Úložisko (Datastore): Veľmi široký pojem, avšak vo svete virtualizácie sa ním rozumie miesto, kde sú uložené súbory virtuálnych strojov. V každom prípade je potrebné veľmi presne porozumieť kontextu a pri najmenších pochybnostiach si vyjasniť, čo presne mal váš interlocutor na mysli.
Proxy (Proxy): Je dôležité hneď na začiatku pochopiť, že Veeam Proxy nie je úplne to isté, čo poznáme z internetu. V rámci produktov od Veeam je to akási entita, ktorá sa zaoberá presúvaním dát z jedného miesta na iné. Ak sa nebudeme zaoberať podrobnosťami, potom VBR je riadiaci server a proxy sú jeho pracovné kone. Proxy je stroj, cez ktorý prechádza prenos dát a na ktorom sú nainštalované komponenty VBR, ktoré pomáhajú s riadením tohto prenosu. Napríklad presúvať dáta z jedného kanála do druhého alebo jednoducho pripojiť disky (režim HotAdd).
Repository (Repozitár): Technicky je to len záznam v databáze VBR, ktorý ukazuje na miesto, kde sú uložené zálohy, a ako sa k tomuto miestu pripojiť. V skutočnosti to môže byť buď jednoduchá CIFS zdieľanie, alebo samostatný disk, server alebo kôš v cloude. Opäť sme v kontexte, ale chápeme, že repositár je len miesto, kde ležia vaše zálohy.
Snapshot (Snapshot): Milovníci oxfordskej gramatiky preferujú rozprávať kto "snapšot", kto "snepšot", avšak bezgramotné väčšiny vyhrávajú vďaka väčšej mase. Ak niekto nevie — ide o technológiu, ktorá umožňuje obnoviť stav disku v určitom časovom okamihu. Robí sa to buď prostredníctvom dočasného presmerovania I/O operácií od hlavného disku — vtedy to bude nazývať RoW (Redirect on Write) snapshot — alebo presunutím prepísaných blokov z vášho disku na iný — to bude nazývať CoW (Copy on Write) snapshot. Práve vďaka širokým možnostiam aplikácie týchto funkcií môže Veeam vykonávať svoju zálohovaciu magiu. Striktné povedané, nie len on, ale to je vec blízkych vydaní.
V dokumentácii a logoch ESXi je okolo tohto pojmu chaos a v kontexte spomínania snapshotov môžeme nájsť aj samotné snapshoty, aj redo log a dokonca delta disk. V dokumentácii Veeam takéto roztrhnutie neexistuje, a snapshot je jednoducho snapshot, zatiaľ čo redo log je presne ten REDO súbor, vytvorený nezávislým non-persistent diskom. REDO súbory sa mažu pri vypnutí virtuálneho stroja, takže mýliť ich so snapshotmi je cesta k zlyhaniu.
Synthetic (Syntetický): Syntetické zálohy sa týkajú reverse incremental a forever forward záloh. Ak ste sa s týmto pojmom zatiaľ nestretli, ide o jeden z mechanizmov používaných na vytváranie transformácie záložnej reťaze. V logoch sa však dá nájsť aj pojem Transform, ktorý sa používa v rámci vytvárania úplných kópií z inkrementov (syntetická úplná).
Task (Úloha): Je to proces spracovania každého jednotlivého stroja v rámci úlohy. To znamená: máte záložnú úlohu, do ktorej sú zahrnuté tri stroje. Takže každý stroj bude spracovaný v rámci samostatnej úlohy. Výsledkom budú štyri logy: jeden hlavný pre úlohu a tri pre úlohy. Je tu však dôležitý nuans: časom sa slovo „úloha“ stalo nadmerne mnohoznačným. Keď hovoríme o všeobecných logoch, znamenáme, že úloha je presne VM. Ale svoje „úlohy“ majú aj na proxy a na repozitári. Tam to môže znamenať aj virtuálny disk, aj virtuálny stroj, aj celú úlohu. Je teda dôležité nezabudnúť na kontext.
Veeam %name% Service (Služba): Na prospech úspešných záloh pracuje hneď niekoľko služieb, zoznam ktorých nájdete v štandardnej konzole. Ich názvy dosť jasne odrážajú ich podstatu, avšak medzi nimi je najdôležitejší — Veeam Backup Service, bez ktorého ostatné fungovať nebudú.
VSS: Technicky by mal VSS vždy znamenať Microsoft Volume Shadow Copy Service. Fakticky ho mnohí používajú ako synonymum Application-Aware Image Processing. Čo je samozrejme kategoricky nesprávne, avšak je to príbeh zo série „Každé terénne vozidlo môžeme nazvať jeepom a ty to pochopíš“.
Fantastické logy a miesta, kde žijú
Chcem začať túto kapitolu odhalením veľkého tajomstva — aký čas sa zobrazuje v logoch?
Pamätajte si:
- ESXi vždy zapisuje logy v UTC+0.
- vCenter vedie logy podľa času svojej časovej zóny.
- Veeam vedie logy podľa času a časovej zóny servera, na ktorom beží.
- A iba víkendové udalosti vo formáte EVTX netrpia väzbou na nič. Pri otvorení sa čas prepočítava na stroj, na ktorom boli otvorené. Najpohodlnejšia možnosť, hoci s ňou môžu byť aj ťažkosti. Jedinou podstatnou ťažkosťou je rozdiel lokalít. To je prakticky garantovaná cesta k nečitelným logom. Áno, existujú možnosti, ako to liečiť, ale poďme sa jednoducho nesporiť o tom, že všetko v IT funguje v angličtine, a dohodneme sa vždy nastaviť na serveroch anglickú lokalitu. Prosím.
Teraz sa predsa len porozprávajme o miestach, kde žijú logy a ako ich získať. V prípade VBR sú dva prístupy.
Prvá možnosť je vhodná, ak nemáte túžbu vyhľadávať v celkovom množstve súborov týkajúcich sa práve vašej situácie. Na to máme samostatného sprievodcu, ktorému môžete určiť konkrétnu prácu a konkrétne obdobie, za ktoré potrebujete logy. Potom si sám prebehne po priečinkoch a zhromaždí všetko potrebné do jedného archívu. O tom, kde ho hľadať a ako s ním pracovať, je podrobne popísané v .
Avšak sprievodca zhromažďuje logy nie všetkých úloh a v prípade potreby preskúmať logy reštaurácie, failoveru alebo failbacku, vaša cesta vedie do priečinka %ProgramData%/Veeam/Backup. Toto je hlavný úložný priestor logov VBR a %ProgramData% je skrytý priečinok a to je v poriadku. Mimochodom, predvolené miesto môžete premenovať pomocou registračného kľúča typu REG_SZ: LogDirectory v kľúči HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication.
Na linuxových strojoch sa logy pracovných agentov majú hľadať v /var/log/VeeamBackup/, ak sa používa root alebo sudo účet. Ak takéto privilégia nemáte, hľadajte logy v /tmp/VeeamBackup.
Pre Veeam agent for %OS_name% sa logy musia hľadať v %ProgramData%/Veeam/Endpoint (alebo %ProgramData%/Veeam/Backup/Endpoint) a /var/log/veeam prípadne.
Ak používate Application-Aware Image Processing (a pravdepodobne áno), situácia sa mierne komplikuje. Potrebujete logy našich helperov, ktoré sa nachádzajú vo vnútri samotnej virtuálky, a logy VSS. O tom, ako a kde získať toto šťastie, je podrobne popísané v . A samozrejme, existujú na zhromažďovanie potrebných systémových logov.
Windows udalosti je pohodlné zbierať podľa . Ak používate Hyper-V, situácia sa komplikuje, pretože potrebujete aj všetky jeho logy z vetvy Applications and Service Logs > Microsoft > Windows. Aj keď vždy môžete ísť jednoduchšou cestou a jednoducho získať všetky objekty z %SystemRoot%System32winevtLogs.
Ak máte niečo rozbité počas inštalácie/upgradu, všetko potrebné nájdete v priečinku %ProgramData%/Veeam/Setup/Temp. Nebudem skrývať, že v udalostiach operačného systému môžete nájsť užitočnejšie informácie ako v týchto logoch. Zaujímavé veci sú v %Temp%, ale tam sú väčšinou logy inštalácie sprievodného softvéru, ako sú databázy, knižnice .Net a podobne. Majte na pamäti, že Veeam sa inštaluje z msi, a všetky jeho komponenty sa tiež inštalujú ako samostatné msi balíky, aj keď to nebolo zobrazené v GUI. Preto, ak inštalácia jedného z komponentov zlyhá, celá inštalácia VBR sa zastaví. Musíte teda ísť do logov a pozrieť sa, čo konkrétne zlyhalo a kedy.
A nakoniec jeden tip: ak dostanete chybu pri inštalácii, neponáhľajte sa kliknúť na OK. Najprv si vezmite logy, potom kliknite na OK. Tak dostanete log, ktorý končí v okamihu chyby, bez zbytočných informácií na konci.
A stáva sa, že musíte preniknúť do logov vSphere. Je to veľmi vďačná činnosť, ale keď si vyhrniete rukávy, musíte robiť aj takéto veci. V najjednoduchšom prípade potrebujeme logy s udalosťami virtuálneho stroja vmware.log, ktoré ležia vedľa jeho .vmx súboru. V zložitejšom prípade otvoríme Google a spýtame sa, kde sú logy pre vašu verziu hostiteľa, pretože VMware to rád mení od vydania k vydaniu. Napríklad, , a toto je pre . Pre logy vCenter opakujeme postup . Vo všeobecnosti nás budú zaujímať logy udalostí hostiteľa hostd.log, udalosti hostiteľov pod správou vCenter vpxa.log, logy jadra vmkernel.log a logy autentifikácie auth.log. A v tých najnáročnejších prípadoch môže byť užitočný log SSO, ktorý sa nachádza v priečinku SSO.
Zložitý? Mätúci? Strašidelný? A to je ešte ani nie polovica informácií, s ktorými náš podporný tím každý deň pracuje. Naozaj sú veľmi šikovní.
Komponenty Veeam
A na záver tohto úvodného článku trochu porozprávame o komponentoch Veeam Backup & Replication. Pretože keď sa hľadá príčina problémov, bolo by dobré rozumieť, ako je pacient usporiadaný.
Tak, ako je určite známe všetkým, Veeam Backup je takzvaná aplikácia založená na SQL. To znamená, že všetky nastavenia, všetky informácie a vlastne všetko, čo je potrebné na normálne fungovanie — to všetko sa nachádza v jeho databáze. Presnejšie, v dvoch databázach, ak hovoríme o spojení VBR a EM: VeeamBackup a VeeamBackupReporting, príslušne. Tak to už býva: nainštalujeme ďalšiu aplikáciu — vznikne ďalšia databáza. Aby sme všetky vajíčka nemali v jednom košíku.
Aby to všetko fungovalo harmonicky, potrebujeme súbor služieb a aplikácií, ktoré prepoja všetky komponenty do jedného celku. Iba ako príklad, takto to vyzerá v jednej z mojich laboratórií:
Hlavného dirigenta zohráva Veeam Backup Service. Práve on zodpovedá za výmenu informácií s databázami. Zodpovedá taktiež za spúšťanie všetkých úloh, stará sa o orchestráciu pridelených zdrojov a funguje ako komunikačné centrum pre rôzne konzoly, agentov a ďalšie. Jednoducho povedané, bez neho to určite nejde, ale to vôbec neznamená, že robí všetko sám.
Pri plnení svojich úloh mu pomáha Veeam Backup Manager. To nie je služba, ale entita zaoberajúca sa spúšťaním úloh a sledujúca proces ich vykonávania. Rukami backup služby, ktorými sa pripája k hostiteľom, vytvára snímky, sleduje retenciu a podobne.
Ale vráťme sa k zoznamu služieb. Veeam Broker Service. Objavil sa vo verzii v9.5 (a to nie je krypto-miner, ako si vtedy niektorí mysleli). Zbiera informácie o VMware hostiteľoch a udržiava ich aktuálne. Ale nenechajte sa unáhliť s písaním hnevu, že vás špehujeme a odovzdávame všetky prihlasovacie údaje administrátorom. Všetko je o niečo jednoduchšie. Keď spustíte zálohu, prvé, čo musíte urobiť, je pripojiť sa k hostiteľovi a aktualizovať všetky údaje o jeho štruktúre. Je to pomerne pomalý a zdĺhavý proces. Stačí si spomenúť, ako dlho trvá operácia prihlásenia cez webové rozhranie, a pamätajte, že tam sa berie do úvahy len vrchná vrstva. A potom ešte musíte rozbaliť celú hierarchiu do požadovaného miesta, mimochodom. Slovo, hrôza. Ak spúšťate desiatky záloh, znamená to, že každá práca musí vykonať tento proces. Ak hovoríme o veľkých infraštruktúrach, tento proces môže trvať desať a viac minút. Preto sa rozhodlo vyčleniť na to samostatnú službu, prostredníctvom ktorej bude možné získať vždy aktuálne informácie. Pri štarte kontroluje a skenuje celú pridanú infraštruktúru, a potom sa snaží pracovať len na úrovni inkrementálnych zmien. Takže aj keď sa vám spustí naraz sto záloh, všetky požiadajú o informácie od nášho makléra, a nie budú trápiť hostiteľov svojimi požiadavkami. Ak sa obávate o zdroje, podľa našich výpočtov na 5000 virtuálnych strojov potrebujete len asi 100 Mb pamäte.
Ďalej máme Veeam Console. Tiež Veeam Remote Console, tiež Veeam.Backup.Shell. Toto je presne to GUI, ktoré vidíme na snímkach obrazovky. Všetko je jednoduché a jasné — konzolu môžete spustiť odkiaľkoľvek, pokiaľ je to Windows a máte prístup k VBR serveru. Jediná vec, ktorú možno povedať: proces FLR bude montovať body lokálne (t.j. na stroj, kde je konzola spustená). A rôznorodé Veeam Explorers budú tiež spustené lokálne, pretože sú súčasťou konzoly. Ale to už ma odviedlo od témy...
Ďalšia zaujímavá služba — Veeam Backup Catalog Data Service. V zozname služieb je známy ako Veeam Guest Catalog Service. Zaoberá sa indexovaním súborových systémov na hosťovacích strojoch a napĺňa tieto vedomosti priečinok VBRCatalog. Používa sa iba tam, kde je zapnuté indexovanie. A zapínať ho má zmysel len vtedy, ak máte Enterprise Manager. Preto rada od srdca: nezapínajte indexovanie len tak, ak nemáte EM. Ušetrite si nervy a čas podpory.
Tiež z iných dôležitých služieb stojí za zmienku Veeam Installer Service, pomocou ktorého prebieha dodávka a inštalácia potrebných komponentov na proxy, úložiská a iné brány. V skutočnosti preváža potrebné .msi balíky na servery a vykonáva ich inštaláciu.
Veeam Data Mover — pomocou spúšťaných na proxy (a nielen) pomocných agentov sa zaoberá presúvaním údajov. Napríklad pri zálohovaní jeden agent číta súbory z dátových úložísk hostiteľa, zatiaľ čo druhý ich starostlivo zapisuje do zálohy.
Zvlášť chcem zdôrazniť dôležitú vec, na ktorú často reagujú klienti — to je rozdiel verzí služieb a informácií v nástroji Programs and Features. Áno, zoznam bude rovnaký, ale v verziách môže byť úplný chaos. To nie je veľmi zdravé z vizuálneho hľadiska, avšak úplne normálne, ak všetko funguje stabilne. Napríklad číslo verzie Installer služby značne zaostáva za susednými. Hrôza a nočná mora? Nie, pretože sa nepreinštalováva celý, ale jednoducho sa aktualizuje jeho DLL. V patchi v9.5 U4 došlo k strašnému sne technickej podpory: pri aktualizácii všetky služby dostali nové verzie, okrem tej najdôležitejšej. V patchi U4b prepravná služba predbehla všetky ostatné až o dve verzie (ak sa posudzuje podľa čísel). A to je tiež normálne — v ňom bola nájdená vážna chyba, preto dostal bonusovú aktualizáciu v porovnaní s ostatnými. Preto, súhrnne: rozdiel vo verziách MÔŽE byť problémom, ale ak rozdiel existuje a všetko funguje správne, pravdepodobne je to v poriadku. Ale nikto vám nezakazuje overiť to v technickej podpore.
To boli takzvané povinné alebo Mandatory services. A existuje ešte celá skupina pomocných, ako Tape Service, Mount Service, vPowerNFS Service a tak ďalej.
Pre Hyper-V je to všetko rovnaké, len existuje špecifický Veeam Backup Hyper-V Integration Service a jeho ovládač na prácu s CBT.
A na záver sa porozprávame o tom, kto pracuje na virtuálnych strojoch počas zálohovania. Na spustenie pre- a post-freeze skriptov, na vytvorenie shadow copy, zber metadát, prácu s logmi SQL transakcií a ďalšie sa používa Veeam Guest Helper. A ak sa vykonáva indexácia súborových systémov, Veeam Guest Indexer . Ide o dočasné služby, ktoré sú nasadené počas zálohovania a po ňom odstránené.
V prípade Linux strojov je to oveľa jednoduchšie vďaka veľkému množstvu zabudovaných knižníc a možností samotného systému. Napríklad, indexácia sa vykonáva cez mlocate.
Na tomto mieste končíme.
Nechcem vás už viac trápiť a krátke úvod do zákulisného priestoru Veeam považujem za ukončený. Áno, ani zďaleka sme sa nedostali k samotným logom, ale verte mi, aby informácie, ktoré sú v nich prezentované, nevyzerali ako nesúvislý tok vedomia, je takéto úvodné pojednanie nevyhnutné. Prejsť k samotným logom plánujem až v treťom článku, a plán na nasledujúci — vysvetliť, kto generuje logy, čo presne je v nich zobrazené a prečo je to tak, a nie inak.
Zdroj: habr.com
