{"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\/cs\/blog\/administrirovanie\/veeam-log-diving-komponenty-i-glossarij","title":{"rendered":"Veeam Log Diving: komponenty a glos\u00e1\u0159","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Veeam
\n
\nVeeam m\u00e1 r\u00e1d logy. A proto\u017ee v\u011bt\u0161ina na\u0161ich \u0159e\u0161en\u00ed je modul\u00e1rn\u00ed, generuj\u00ed pom\u011brn\u011b hodn\u011b log\u016f. A jeliko\u017e na\u0161\u00edm oborem je zaji\u0161t\u011bn\u00ed bezpe\u010dnosti va\u0161ich dat (tedy klidn\u00fd sp\u00e1nek), logy mus\u00ed nejen zachycovat ka\u017ed\u00fd n\u00e1znak, ale tak\u00e9 to d\u011blat dost podrobn\u011b. Je to nezbytn\u00e9, aby v p\u0159\u00edpad\u011b pot\u0159eby bylo jasn\u00e9, jak k tomu \"n\u011b\u010demu\" do\u0161lo, kdo je za to odpov\u011bdn\u00fd a co d\u00e1l d\u011blat. Jak v kriminalistice: nikdy nev\u00ed\u0161, jak\u00fd detail ti pom\u016f\u017ee naj\u00edt vraha Lory Palmerov\u00e9.<\/p>\n

Proto jsem se rozhodl pustit do s\u00e9rie \u010dl\u00e1nk\u016f, kde postupn\u011b vypr\u00e1v\u00edm o tom, co zapisujeme do log\u016f, kde je uchov\u00e1v\u00e1me, jak se nezbl\u00e1znit z jejich struktury a co vlastn\u011b v nich hledat.
\n<\/a><\/noindex><\/p>\n

Pro\u010d s\u00e9rie \u010dl\u00e1nk\u016f a pro\u010d nepopisovat v\u0161echno najednou? <\/h3>\n

\nJednodu\u0161e vyjmenovat, kter\u00fd log se kde nach\u00e1z\u00ed a co v n\u011bm je, je dost ne\u0161\u0165astn\u00e1 my\u0161lenka. A udr\u017eovat tyto informace aktu\u00e1ln\u00ed je je\u0161t\u011b hor\u0161\u00ed. Prost\u00e9 seps\u00e1n\u00ed v\u0161ech mo\u017en\u00fdch typ\u016f log\u016f ve Veeam Backup & Replication by bylo tabulkou na n\u011bkolik list\u016f mal\u00fdm p\u00edsmem. A nav\u00edc by byla aktu\u00e1ln\u00ed jen v okam\u017eiku publikace, proto\u017ee s vyd\u00e1n\u00edm dal\u0161\u00edho patche by se mohly objevit nov\u00e9 logy, zm\u011bnit logika uchov\u00e1van\u00fdch informac\u00ed ve star\u00fdch atd. Proto bude mnohem v\u00fdhodn\u011bj\u0161\u00ed vysv\u011btlit jejich strukturu a podstatu obsa\u017een\u00fdch informac\u00ed. To umo\u017en\u00ed l\u00e9pe se orientovat na m\u00edstech ne\u017e prost\u00e9 memorov\u00e1n\u00ed n\u00e1zv\u016f.<\/p>\n

Abychom se tedy nesko\u010dili do hloubky textov\u00fdch p\u0159\u00edb\u011bh\u016f, poj\u010fme v tomto \u010dl\u00e1nku prov\u00e9st ur\u010ditou p\u0159\u00edpravu. Dnes se tedy nebudeme zab\u00fdvat samotn\u00fdmi logy, ale p\u0159istoup\u00edme k tomu z d\u00e1lky: vytvo\u0159\u00edme glos\u00e1\u0159 a trochu se pobav\u00edme o struktu\u0159e Veeam z pohledu generace log\u016f.<\/p>\n

Glos\u00e1\u0159 a \u017eargon<\/h3>\n

\nZde se p\u0159edev\u0161\u00edm omlouv\u00e1m p\u0159\u00edznivc\u016fm \u010distoty \u010de\u0161tiny a sv\u011bdk\u016fm O\u017eegova slovn\u00edku. V\u0161ichni velmi milujeme sv\u016fj rodn\u00fd jazyk, ale proklet\u00fd IT pr\u016fmysl funguje v angli\u010dtin\u011b. No, my jsme to nevymysleli, ale historicky to tak dopadlo. Nejsem v tom nevinn\u011b, p\u0159i\u0161el s\u00e1m (c)<\/p>\n

V na\u0161em oboru m\u00e1 probl\u00e9m anglicism\u016f (a \u017eargonu) svou specifiku. Kdy\u017e pod nevinn\u00fdmi slovy jako \"host\" nebo \"n\u00e1v\u0161t\u011bvn\u00edk\" cel\u00fd sv\u011bt rozum\u00ed zcela konkr\u00e9tn\u00edm v\u011bcem, na \u2159 \u010d\u00e1sti pevniny pokra\u010duje hrdinsk\u00e9 rozpr\u00e1\u0161en\u00ed a v\u00e1h\u00e1n\u00ed s hled\u00e1n\u00edm ve slovn\u00edc\u00edch. A striktn\u011b povinn\u00fd argument \u201eA te\u010f u n\u00e1s v pr\u00e1ci\u2026\u201d.<\/p>\n

Krom\u011b toho m\u00e1me terminologii, kter\u00e1 pat\u0159\u00ed konkr\u00e9tn\u011b produkt\u016fm Veeam, i kdy\u017e n\u011bkter\u00e1 slova a obraty se dostaly i mezi lid. Proto se te\u010f dohodneme, co kter\u00fd term\u00edn znamen\u00e1, a v budoucnu pod slovem \"host\" budu m\u00edt na mysli pr\u00e1v\u011b to, co je naps\u00e1no v t\u00e9to kapitole, a ne to, co jste zvykl\u00ed m\u00edt ve sv\u00e9 pr\u00e1ci. A ano, to nen\u00ed moje osobn\u00ed p\u0159\u00e1n\u00ed, ale ust\u00e1len\u00e9 term\u00edny v pr\u016fmyslu. Bojovat s nimi je pon\u011bkud bezv\u00fdznamn\u00e9. I kdy\u017e koment\u00e1\u0159e mi nevad\u00ed.<\/p>\n

Bohu\u017eel, term\u00edn\u016f v na\u0161\u00ed pr\u00e1ci a produktech je extr\u00e9mn\u011b mnoho, tak\u017ee se je v\u0161echny sna\u017eit vyjmenovat nebudu. Jen ty nejz\u00e1kladn\u011bj\u0161\u00ed a nezbytn\u00e9 pro p\u0159e\u017eit\u00ed v mo\u0159i informac\u00ed o z\u00e1loh\u00e1ch a log\u00e1ch. Pro z\u00e1jemce mohu tak\u00e9 nab\u00eddnout \u010dl\u00e1nek <\/a><\/noindex>kolegy o p\u00e1sech, kde tak\u00e9 zmi\u0148oval seznam term\u00edn\u016f vztahuj\u00edc\u00edch se k t\u00e9 \u010d\u00e1sti funkcionality.<\/p>\n

Host (Hostitel):<\/strong> Ve sv\u011bt\u011b virtualizace je to stroj s hypervizorem. Fyzick\u00fd, virtu\u00e1ln\u00ed, cloudov\u00fd \u2014 nez\u00e1le\u017e\u00ed na tom. Jestli\u017ee na n\u011b\u010dem b\u011b\u017e\u00ed hypervizor (ESXi, Hyper-V, KVM atd.), tak to \"n\u011bco\" se naz\u00fdv\u00e1 hostitelem. A\u0165 u\u017e je to cluster se deseti racky nebo v\u00e1\u0161 laptop s laborkou na p\u016fl virtu\u00e1ln\u00edho stroje \u2014 pokud jste spustili hypervizor, pak jste se stali hostitelem. Proto\u017ee hypervizor host\u00ed virtu\u00e1ln\u00ed stroje. Dokonce existuje pov\u011bst, \u017ee VMware kdysi cht\u011bla dos\u00e1hnout pevn\u00e9 asociace slova hostitel pr\u00e1v\u011b s ESXi. Ale nezvl\u00e1dli to.<\/p>\n

V modern\u00edm sv\u011bt\u011b se pojem \"hostitel\" prakticky slil s pojmem \"server\", co\u017e p\u016fsob\u00ed ur\u010dit\u00e9 zmatek v komunikaci, zejm\u00e9na pokud jde o Windows infrastrukturu. Tak\u017ee jak\u00fdkoli stroj, na kter\u00e9m je n\u011bjak\u00e1 zaj\u00edmav\u00e1 slu\u017eba, m\u016f\u017ee b\u00fdt sm\u011ble nazv\u00e1n hostitelem. Nap\u0159\u00edklad v log\u00e1ch WinSock je slovo host ozna\u010dov\u00e1no \u00fapln\u011b v\u0161\u00edm. Klasick\u00e9 \"Host not found\" je tomu p\u0159\u00edkladem. Tak\u017ee vych\u00e1z\u00edme z kontextu, ale pamatujeme \u2014 ve sv\u011bt\u011b virtualizace hostitel je ten, kdo host\u00ed hosty (o tom dv\u011b \u0159\u00e1dky n\u00ed\u017ee).<\/p>\n

Z lok\u00e1ln\u00edho \u017eargonu (sp\u00ed\u0161e akronym\u016f, v tomto p\u0159\u00edpad\u011b) si vzpomeneme, \u017ee VMware je VI, vSphere je VC a Hyper-V je HV.<\/p>\n

Guest (Host):<\/strong> Virtu\u00e1ln\u00ed stroj b\u011b\u017e\u00edc\u00ed na hostiteli. Tady ani nen\u00ed co vysv\u011btlovat, je to tak logick\u00e9 a jednoduch\u00e9. Nicm\u00e9n\u011b mnoz\u00ed se sna\u017e\u00ed zatahovat n\u011bjak\u00e9 jin\u00e9 v\u00fdznamy. <\/p>\n

Pro\u010d? To nev\u00edm.
\nGuest OS, tedy opera\u010dn\u00ed syst\u00e9m hostitelsk\u00e9ho stroje. A tak d\u00e1le.<\/p>\n

Backup\/Replication Job (\u00fakol):<\/strong> \u010cist\u00fd VMware \u017eargon, ozna\u010duj\u00edc\u00ed n\u011bjak\u00fd \u00fakol. Backup job == Z\u00e1lohovac\u00ed \u00fakol. Jak to hezky p\u0159elo\u017eit do \u010de\u0161tiny \u2014 nikdo nevymyslel, proto v\u0161ichni \u0159\u00edkaj\u00ed \"\u00fakol\" s d\u016frazem na posledn\u00ed slabiku.<\/p>\n

Ano, tak jednodu\u0161e prost\u011b \u0159\u00edkaj\u00ed \"\u00fakol\". A dokonce to p\u00ed\u0161\u00ed v emailech, a v\u0161e je v po\u0159\u00e1dku.
\nR\u016fzn\u00e9 z\u00e1lohovac\u00ed pr\u00e1ce, \u00fakoly z\u00e1lohy atd., d\u00edky, ale to nen\u00ed pot\u0159eba. Prost\u011b \u00fakol, a budete pochopeni. Hlavn\u00ed je kl\u00e1st d\u016fraz na posledn\u00ed slabiku.<\/p>\n

Backup (Z\u00e1loha, backup. Pro prav\u00e9 old-school\u00e1ky je p\u0159\u00edpustn\u00e9 \u0159\u00edkat bakUp):<\/strong> Krom\u011b z\u0159ejm\u00e9ho (n\u011bkde ulo\u017een\u00e1 z\u00e1loha dat) ozna\u010duje tak\u00e9 samotn\u00fd \u00fakol (t\u0159i \u0159\u00e1dky v\u00fd\u0161e, pokud u\u017e jste zapomn\u011bli), na jeho\u017e z\u00e1klad\u011b vznik\u00e1 ten sam\u00fd z\u00e1lohovac\u00ed soubor. Pravd\u011bpodobn\u011b jsou anglicky mluv\u00edc\u00ed lid\u00e9 p\u0159\u00edli\u0161 l\u00edn\u00ed, aby poka\u017ed\u00e9 \u0159\u00edkali I ran my backup job, tak\u017ee prost\u011b \u0159eknou I ran my backup, a v\u0161ichni se skv\u011ble ch\u00e1pou. Navrhuji podpo\u0159it tento v\u00fdborn\u00fd z\u00e1m\u011br.<\/p>\n

Consolidate (Konsolidace): <\/strong>Term\u00edn, kter\u00fd se objevil v ESXi 5.0. Mo\u017enost v nab\u00eddce pr\u00e1ce se snapshoty, spou\u0161t\u011bj\u00edc\u00ed proces odstra\u0148ov\u00e1n\u00ed takzvan\u00fdch orphaned snapshot\u016f. To jsou snapshoty, kter\u00e9 fyzicky existuj\u00ed, ale vypadly z zobrazen\u00e9 logick\u00e9 struktury. Teoreticky by tento proces nem\u011bl zas\u00e1hnout soubory zobrazen\u00e9 v mana\u017eeru snapshot\u016f, ale m\u016f\u017ee se st\u00e1t cokoliv. Podstata procesu konsolidace je v tom, \u017ee data ze snapshotu (child disk) jsou zapisov\u00e1na do hlavn\u00edho (parent) disku. Proces slou\u010den\u00ed disk\u016f se naz\u00fdv\u00e1 mergen (merge). Pokud byla vyd\u00e1na objedn\u00e1vka na konsolidaci, z\u00e1znam o snapshotu m\u016f\u017ee b\u00fdt smaz\u00e1n z datab\u00e1ze d\u0159\u00edve, ne\u017e bude snapshot slou\u010den a odstran\u011bn. A pokud se snapshot z n\u011bjak\u00e9ho d\u016fvodu nepoda\u0159ilo odstranit, objev\u00ed se pr\u00e1v\u011b tyto orphaned snapshoty. O pr\u00e1ci se snapshoty m\u00e1 VMware dobr\u00e9 KB<\/a><\/noindex>. A tak\u00e9 jsme o nich n\u011bkdy psali na Habru<\/a><\/noindex>.<\/p>\n

Datastore (Sklad nebo storage): <\/strong>\u00a0Velmi \u0161irok\u00fd pojem, av\u0161ak ve sv\u011bt\u011b virtualizace se t\u00edm rozum\u00ed m\u00edsto, kde jsou ulo\u017eeny soubory virtu\u00e1ln\u00edch stroj\u016f. V ka\u017ed\u00e9m p\u0159\u00edpad\u011b je nutn\u00e9 velmi jasn\u011b pochopit kontext a v p\u0159\u00edpad\u011b nejmen\u0161\u00edho pochybnosti si ujasnit, co p\u0159esn\u011b v\u00e1\u0161 prot\u011bj\u0161ek m\u011bl na mysli.\u00a0<\/p>\n

Proxy (Proxy): <\/strong>Je d\u016fle\u017eit\u00e9 ihned pochopit, \u017ee Veeam Proxy nen\u00ed \u00fapln\u011b to sam\u00e9, na co jsme zvykl\u00ed na poli internetu. V r\u00e1mci produkt\u016f od Veeam je to jak\u00e1si entita, kter\u00e1 se zab\u00fdv\u00e1 p\u0159esunem dat z jednoho m\u00edsta na druh\u00e9. Pokud se nepodrob\u00edme podrobnostem, VBR je t\u00fdmov\u00fd server, a proxy jsou jeho pracovn\u00ed kon\u011b. To znamen\u00e1, \u017ee proxy je stroj, skrze kter\u00fd prot\u00e9k\u00e1 provoz a na kter\u00e9m jsou nainstalov\u00e1ny komponenty VBR, kter\u00e9 pom\u00e1haj\u00ed \u0159\u00eddit tento provoz. Nap\u0159\u00edklad p\u0159esouvat data z jednoho kan\u00e1lu do druh\u00e9ho nebo prost\u011b p\u0159ipojit dal\u0161\u00ed disky (re\u017eim HotAdd).<\/p>\n

Repository (Repozit\u00e1\u0159): <\/strong>\u00a0Technicky se jedn\u00e1 pouze o z\u00e1znam v datab\u00e1zi VBR, kter\u00fd ukazuje na m\u00edsto, kde jsou uchov\u00e1v\u00e1ny z\u00e1lohy, a jak se k tomuto m\u00edstu p\u0159ipojit. V praxi to m\u016f\u017ee b\u00fdt jak prost\u00e1 CIFS sd\u00edlen\u00e1 slo\u017eka, tak i samostatn\u00fd disk, server nebo cloudov\u00fd bucket. Op\u011bt se nach\u00e1z\u00edme v kontextu, ale ch\u00e1peme, \u017ee repozit\u00e1\u0159 je prost\u011b m\u00edsto, kde le\u017e\u00ed va\u0161e z\u00e1lohy.<\/p>\n

\u00a0Snapshot (Snapshot): <\/strong>Milovn\u00edci oxfordsk\u00e9 gramatiky preferuj\u00ed mluvit o tom, kdo je sn\u00c9p\u0161ot, kdo snE\u067e\u0161ot, nicm\u00e9n\u011b negramotn\u00e1 v\u011bt\u0161ina v\u00edt\u011bz\u00ed d\u00edky v\u011bt\u0161\u00ed masu. Pokud n\u011bkdo nev\u00ed \u2014 je to technologie, kter\u00e1 umo\u017e\u0148uje obnovit stav disku k ur\u010dit\u00e9mu okam\u017eiku. D\u011bl\u00e1 se to bu\u010f do\u010dasn\u00fdm p\u0159esm\u011brov\u00e1n\u00edm I\/O operac\u00ed sm\u011brem od hlavn\u00edho disku \u2014 pak se to naz\u00fdv\u00e1 RoW (Redirect on Write) sn\u00edmek \u2014 nebo p\u0159esunut\u00edm p\u0159episovan\u00fdch blok\u016f z va\u0161eho disku na jin\u00fd \u2014 to se naz\u00fdv\u00e1 CoW (Copy on Write) sn\u00edmek. Pr\u00e1v\u011b d\u00edky \u0161irok\u00fdm mo\u017enostem vyu\u017eit\u00ed t\u011bchto funkc\u00ed m\u016f\u017ee Veeam vykon\u00e1vat svou z\u00e1lohovac\u00ed magii. P\u0159esn\u011bji, nejen jemu, ale to je z\u00e1le\u017eitost bl\u00edzk\u00fdch verz\u00ed.<\/p>\n

V dokumentaci a logech ESXi panuje okolo tohoto term\u00ednu chaos, a v kontextu zm\u00ednky o snapshotu m\u016f\u017eete narazit na samotn\u00e9 snapshoty, redo logy a dokonce delta disky. V dokumentaci Veeam takov\u00fd zmatek nen\u00ed, a snapshot je snapshot, zat\u00edmco redo log je p\u0159esn\u011b REDO soubor, vytvo\u0159en\u00fd nez\u00e1visl\u00fdm non-persistent diskem. REDO soubory jsou smaz\u00e1ny p\u0159i vypnut\u00ed virtu\u00e1ln\u00edho stroje, tak\u017ee jejich zam\u011b\u0148ov\u00e1n\u00ed se snapshoty je cesta k ne\u00fasp\u011bchu.<\/p>\n

Synthetic (Syntetika):<\/strong> Syntetick\u00e9 z\u00e1lohy se vztahuj\u00ed k reverse incremental a forever forward z\u00e1loh\u00e1m. Pokud jste se s t\u00edmto term\u00ednem dosud nesetkali, jedn\u00e1 se o jeden z mechanism\u016f pou\u017e\u00edvan\u00fdch k vytv\u00e1\u0159en\u00ed transformace z\u00e1lohov\u00e9ho \u0159et\u011bzce. V logech se v\u0161ak tak\u00e9 m\u016f\u017eete setkat s pojmem Transform, kter\u00fd se pou\u017e\u00edv\u00e1 v r\u00e1mci vytv\u00e1\u0159en\u00ed pln\u00fdch kopi\u00ed z inkrement\u016f (syntetick\u00e1 pln\u00e1).<\/p>\n

Task (\u00dakol):<\/strong> To je proces zpracov\u00e1n\u00ed ka\u017ed\u00e9ho jednotliv\u00e9ho stroje v r\u00e1mci \u00falohy. Tak\u017ee: m\u00e1te z\u00e1lohovou \u00falohu, do kter\u00e9 jsou zahrnuty t\u0159i stroje. To znamen\u00e1, \u017ee ka\u017ed\u00fd stroj bude zpracov\u00e1n v r\u00e1mci samostatn\u00e9ho \u00fakolu. Celkem tedy budou \u010dty\u0159i logy: jeden hlavn\u00ed pro \u00falohu a t\u0159i pro \u00fakoly. Nicm\u00e9n\u011b zde je z\u00e1sadn\u00ed nuance: postupem \u010dasu se slovo \u201e\u00fakol\u201c stalo p\u0159\u00edli\u0161 mnohozna\u010dn\u00fdm. Kdy\u017e mluv\u00edme o obecn\u00fdch logech, m\u00e1me na mysli, \u017ee \u00fakol je pr\u00e1v\u011b VM. Ale sv\u00e9 \u201e\u00fakoly\u201c maj\u00ed i proxy a \u00falo\u017ei\u0161t\u011b. Pro n\u011b to m\u016f\u017ee znamenat jak virtu\u00e1ln\u00ed disk, tak virtu\u00e1ln\u00ed stroj nebo celou \u00falohu. Je d\u016fle\u017eit\u00e9 neztratit kontext.<\/p>\n

Veeam %name% Service (Slu\u017eba)<\/strong>: \u00a0<\/strong>Pro \u00fasp\u011b\u0161n\u00e9 z\u00e1lohy pracuje hned n\u011bkolik slu\u017eeb, jejich\u017e seznam naleznete ve standardn\u00ed konzole. Jejich n\u00e1zvy dostate\u010dn\u011b jasn\u011b odr\u00e1\u017eej\u00ed jejich podstatu, nicm\u00e9n\u011b mezi nimi je nejd\u016fle\u017eit\u011bj\u0161\u00ed - Veeam Backup Service, bez kter\u00e9 ostatn\u00ed nebudou fungovat.<\/p>\n

VSS: <\/strong>Technicky by VSS v\u017edy m\u011bl ozna\u010dovat Microsoft Volume Shadow Copy Service. Ve skute\u010dnosti je mnoh\u00fdmi pou\u017e\u00edv\u00e1n jako synonymum pro Application-Aware Image Processing. Co\u017e, samoz\u0159ejm\u011b, je naprosto chybn\u00fd \u00fadaj, nicm\u00e9n\u011b to je p\u0159\u00edb\u011bh ze sf\u00e9ry \u201eKa\u017ed\u00e9 SUV m\u016f\u017eete nazvat jeepem, a vy budete pochopeni.\u201c<\/p>\n

Fantastick\u00e9 logy a m\u00edsta, kde \u017eij\u00ed<\/h3>\n

\nChci tuto kapitolu za\u010d\u00edt odhalen\u00edm velk\u00e9ho tajemstv\u00ed - jak\u00fd \u010das se zobrazuje v logech?<\/p>\n

Pamatujte:<\/p>\n