{"id":97729,"date":"2020-10-21T08:42:22","date_gmt":"2020-10-21T06:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving"},"modified":"2020-10-21T08:42:22","modified_gmt":"2020-10-21T06:42:22","slug":"otkuda-berutsya-logi-veeam-log-diving","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Odkia\u013e poch\u00e1dzaj\u00fa logy? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Odkia\u013e<\/p>\n

Pokra\u010dujeme v na\u0161ich prieskumoch vzru\u0161uj\u00faceho sveta ladenia por\u00fach pod\u013ea logov. V predch\u00e1dzaj\u00facej \u010dl\u00e1nku<\/a><\/noindex> sme sa dohodli na v\u00fdzname z\u00e1kladn\u00fdch term\u00ednov a letmo sme presk\u00famali celkov\u00fa \u0161trukt\u00faru Veeam ako jedin\u00e9ho aplika\u010dn\u00e9ho syst\u00e9mu. \u00dalohou na t\u00fato t\u00e9mu je zisti\u0165, ako s\u00fa vytv\u00e1ran\u00e9 logy, ak\u00e9 inform\u00e1cie obsahuj\u00fa a pre\u010do vyzeraj\u00fa tak, ako vyzeraj\u00fa.<\/p>\n

\u010co si mysl\u00edte, \u010do vlastne s\u00fa tieto \"logy\"? Pod\u013ea n\u00e1zoru v\u00e4\u010d\u0161iny by logy akejko\u013evek aplik\u00e1cie mali hra\u0165 rolu ak\u00e9hosi v\u0161emoh\u00faceho entity, ktor\u00e1 v\u00e4\u010d\u0161inu \u010dasu pre\u017e\u00edva kdesi na okraji, ale v potrebnej chv\u00edli sa objav\u00ed z nikadia\u013e v osl\u0148uj\u00facich zbroj\u00edch a v\u0161etk\u00fdch zachr\u00e1ni. Teda v nich by malo by\u0165 v\u0161etko, za\u010d\u00ednaj\u00fac od najmen\u0161\u00edch ch\u00fdb v ka\u017edej komponente a\u017e po jednotliv\u00e9 transakcie datab\u00e1zy. A po chybe by malo hne\u010f nasledova\u0165, ako to napravi\u0165. A toto v\u0161etko by sa malo zmesti\u0165 do p\u00e1r megabajtov, nie viac. Ve\u010f je to len text! Textov\u00e9 s\u00fabory nem\u00f4\u017eu zabera\u0165 desiatky gigabajtov, niekde som to po\u010dul!<\/p>\n

Tak\u017ee logy<\/h2>\n

V re\u00e1lnom svete s\u00fa logy len arch\u00edvom diagnostick\u00fdch inform\u00e1ci\u00ed. A \u010do tam uchov\u00e1va\u0165, odkia\u013e z\u00edska\u0165 inform\u00e1cie na uchovanie a ak\u00e9 podrobn\u00e9 by mali by\u0165, rozhoduj\u00fa samotn\u00ed v\u00fdvoj\u00e1ri. Niekto ide cestou minimalizmu a uchov\u00e1va z\u00e1znamy \u00farovne ZAPNUT\u00c9\/VYPNUT\u00c9, zatia\u013e \u010do niekto sa sna\u017e\u00ed nazbiera\u0165 v\u0161etko, \u010do len m\u00f4\u017ee dosiahnu\u0165. Hoci existuje aj medziverzia s mo\u017enos\u0165ou v\u00fdberu takzvan\u00e9ho Logging Level, kde si s\u00e1m ur\u010dujete, ak\u00e9 podrobn\u00e9 inform\u00e1cie chcete uchov\u00e1va\u0165 a ko\u013eko m\u00e1te vo\u013en\u00e9ho miesta na diskoch =) V VBR je t\u00fdchto \u00farovn\u00ed dokonca \u0161est, mimochodom. A ver\u00edte, nechcete vidie\u0165, \u010do sa deje pri maxim\u00e1lne podrobn\u00fdch logoch s vo\u013en\u00fdm miestom na va\u0161om disku.<\/p>\n

Dobre. Rozumeli sme, \u010do chceme uchov\u00e1va\u0165, ale vyvst\u00e1va z\u00e1konn\u00e1 ot\u00e1zka: odkia\u013e z\u00edska\u0165 tieto inform\u00e1cie? \u010cas\u0165 udalost\u00ed pre logovanie, samozrejme, generujeme sami na\u0161imi intern\u00fdmi procesmi. Ale \u010do robi\u0165, ke\u010f nast\u00e1va interakcia s vonkaj\u0161\u00edm prostred\u00edm? Aby sme sa nestali objaven\u00edm nepredv\u00eddate\u013en\u00e9ho chaosu s n\u00faten\u00fdm rie\u0161en\u00edm probl\u00e9mov, Veeam m\u00e1 tendenciu nevynaliezat u\u017e vyn\u00e1jden\u00e9. Kedyko\u013evek existuje u\u017e hotov\u00e9 API, integrovan\u00e1 funkcia v syst\u00e9me, kni\u017enica a podobne, uprednostn\u00edme hotov\u00e9 varianty pred t\u00fdm, ako za\u010dneme budova\u0165 svoje komplikovan\u00e9 rie\u0161enia. Aj ke\u010f je t\u00fdch posledn\u00fdch dos\u0165. Preto pri anal\u00fdze logov je d\u00f4le\u017eit\u00e9 pochopi\u0165, \u017ee ve\u013ek\u00e1 \u010das\u0165 ch\u00fdb pramen\u00ed zo spr\u00e1v od extern\u00fdch API, syst\u00e9mov\u00fdch volan\u00ed a in\u00fdch kni\u017en\u00edc. V tomto pr\u00edpade je \u00falohou VBR posun\u00fa\u0165 tieto chyby do logov tak, ako s\u00fa. A hlavnou \u00falohou pou\u017e\u00edvate\u013ea je nau\u010di\u0165 sa rozumie\u0165, ktor\u00e1 riadkov\u00e1 sa od koho poch\u00e1dza a za \u010do tento \"niekto\" zodpoved\u00e1. Preto, ak k\u00f3d chyby z logu VBR vedie na str\u00e1nku MSDN, je to norm\u00e1lne a spr\u00e1vne.<\/p>\n

Ako sme sa predt\u00fdm dohodli: Veeam je takzvan\u00e1 aplik\u00e1cia zalo\u017een\u00e1 na SQL. To znamen\u00e1, \u017ee v\u0161etky nastavenia, v\u0161etky inform\u00e1cie a vlastne v\u0161etko, \u010do je potrebn\u00e9 na norm\u00e1lne fungovanie, je ulo\u017een\u00e9 v jeho datab\u00e1ze. Odtia\u013e vypl\u00fdva jednoduch\u00e1 pravda: to, \u010do nie je v logoch, pravdepodobne je v datab\u00e1ze. Ale ani to nie je strieborn\u00e1 gu\u013eka: niektor\u00e9 veci nie s\u00fa ani v lok\u00e1lnych logoch komponentov Veeam, ani v jeho datab\u00e1ze. Preto sa treba nau\u010di\u0165 sk\u00fama\u0165 logy hostite\u013ea, logy lok\u00e1lneho stroja a logy v\u0161etk\u00e9ho, \u010do sa podie\u013ea na procese z\u00e1lohovania a obnovenia. Niekedy m\u00f4\u017ee by\u0165 situ\u00e1cia tak\u00e1, \u017ee potrebn\u00e9 inform\u00e1cie nie s\u00fa nikde. Tak\u00e1 je cesta. <\/p>\n

Nieko\u013eko pr\u00edkladov tak\u00fdchto API<\/h4>\n

Tento zoznam si ned\u00e1va za cie\u013e by\u0165 v\u00fdnimo\u010dne \u00fapln\u00fd, tak\u017ee v \u0148om netreba h\u013eada\u0165 pravdu v poslednej in\u0161tancii. Jeho \u00falohou je len uk\u00e1za\u0165 naj\u010dastej\u0161ie extern\u00e9 API a technol\u00f3gie pou\u017e\u00edvan\u00e9 v na\u0161ich produktoch.<\/p>\n

Za\u010dneme s VMware<\/strong>. <\/p>\n

Prv\u00fdm v zozname bude vSphere API<\/strong>. Pou\u017e\u00edva sa na autentifik\u00e1ciu, \u010d\u00edtanie hierarchie, vytv\u00e1ranie a odstra\u0148ovanie sn\u00edmok, dotazovanie inform\u00e1ci\u00ed o strojoch a mnoho (naozaj mnoho) \u010fal\u0161\u00edch vec\u00ed. Funkcionalita rie\u0161enia je ve\u013emi \u0161irok\u00e1, tak\u017ee ka\u017ed\u00e9mu, kto m\u00e1 z\u00e1ujem, m\u00f4\u017eem odporu\u010di\u0165 VMware vSphere API Reference pre verziu 5.5<\/u><\/a><\/noindex> a 6.0<\/u><\/a><\/noindex>. Pre aktu\u00e1lnej\u0161ie verzie sa to jednoducho vyh\u013ead\u00e1.<\/p>\n

VIX API<\/strong>. \u010cierna m\u00e1gia hyperv\u00edzora, pre ktor\u00fa existuje samostatn\u00fd zoznam ch\u00fdb<\/u><\/a><\/noindex>. VMware API na pr\u00e1cu s s\u00fabormi na hostite\u013eovi bez sie\u0165ov\u00e9ho pripojenia. Posledn\u00e1 mo\u017enos\u0165, ke\u010f treba vlo\u017ei\u0165 s\u00fabor do stroja, ku ktor\u00e9mu nie je lep\u0161\u00ed sp\u00f4sob pripojenia. Predstavuje boles\u0165 a utrpenie, ak je s\u00fabor ve\u013ek\u00fd a hostite\u013e je pre\u0165a\u017een\u00fd. Ale tu plat\u00ed pravidlo, \u017ee aj 56,6 kB\/s je lep\u0161ie ako 0 kB\/s. V Hyper-V sa podobn\u00e1 funkcia naz\u00fdva PowerShell Direct. Ale to bolo len do pr\u00edchodu<\/p>\n

vSphere Web Services API<\/strong> Od vSphere 6.0 (pribli\u017ene, ke\u010f\u017ee tento API bol prv\u00fdkr\u00e1t predstaven\u00fd vo verzii 5.5) sa pou\u017e\u00edva na pr\u00e1cu s hos\u0165ovan\u00fdmi strojmi a u\u017e takmer v\u0161ade nahradil VIX. V podstate ide o \u010fal\u0161\u00ed API na spr\u00e1vu vSphere. Zauj\u00edmav\u00fdm by som odpor\u00fa\u010dal presk\u00fama\u0165 skvel\u00fd<\/u><\/a><\/noindex> n\u00e1vod. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Kni\u017enica, o ktorej bolo \u010diasto\u010dne zmienen\u00e9 v tejto \u010dl\u00e1nku<\/u><\/a><\/noindex>. Pou\u017e\u00edva sa na \u010d\u00edtanie virtu\u00e1lnych diskov. Kedysi bol s\u00fa\u010das\u0165ou VIX, ale \u010dasom bol presunut\u00fd do samostatn\u00e9ho produktu. Naopak, ako jeho n\u00e1stupca, pou\u017e\u00edva tie ist\u00e9 chybov\u00e9 k\u00f3dy ako VIX. Ale z nejak\u00e9ho d\u00f4vodu neexistuje v samotnom SDK \u017eiadny popis t\u00fdchto ch\u00fdb. Preto bolo zisten\u00e9 sk\u00fasen\u00fdm sp\u00f4sobom, \u017ee chyby VDDK s in\u00fdmi k\u00f3dmi s\u00fa len transform\u00e1ciou z bin\u00e1rneho na desiatkov\u00fd k\u00f3d. Sklad\u00e1 sa z dvoch \u010dast\u00ed \u2013 prv\u00e1 polovica predstavuje nedokumentovan\u00e9 inform\u00e1cie o kontexte, zatia\u013e \u010do druh\u00e1 \u010das\u0165 sa zaober\u00e1 tradi\u010dn\u00fdmi VIX\/VDDK chybami. Napr\u00edklad, ak vid\u00edme:<\/p>\n

VDDK error: 21036749815809.Unknown error<\/code><\/p>\n

Tak to bez ob\u00e1v konvertujeme na hex a dostaneme 132200000001. Neinformativn\u00fd za\u010diatok 132200 jednoducho ignorujeme, a zvy\u0161ok bude na\u0161\u00edm chybov\u00fdm k\u00f3dom (VDDK 1: Nezn\u00e1ma chyba). O naj\u010dastej\u0161\u00edch VDDK chyb\u00e1ch bola ned\u00e1vno vydan\u00e1 samostatn\u00e1 \u010dl\u00e1nok<\/u><\/a><\/noindex>.<\/p>\n

Teraz sa pozrime na Windows<\/strong>. <\/p>\n

Tu n\u00e1jdeme v\u0161etko, \u010do potrebujeme, v \u0161tandardnom Event Viewer<\/strong>. Ale je tu jedna z\u00e1drhel: pod\u013ea starej trad\u00edcie Windows nezhroma\u017e\u010fuje kompletn\u00fd text chyby, ale iba jej \u010d\u00edslo. Napr\u00edklad, chyba 5 je \u201cAccess denied\u201d, a 1722 je \u201cRPC server is unavailable\u201d, a 10060 je \u201cConnection timed out\u201d. Ur\u010dite je fajn, ak si pam\u00e4t\u00e1te najzn\u00e1mej\u0161ie, ale \u010do robi\u0165 s doteraz neviden\u00fdmi? <\/p>\n

Aby \u017eivot nebol \u00faplne medov\u00fd, chyby s\u00fa ulo\u017een\u00e9 aj v hexadecim\u00e1lnom form\u00e1te s prefixom 0x8007. Napr\u00edklad 0x8007000e \u2014 to v skuto\u010dnosti je 14, Out of Memory. Pre\u010do a pre koho to tak bolo uroben\u00e9 \u2014 je tajomstvom zahalen\u00fdm tmou. Av\u0161ak kompletn\u00fd zoznam ch\u00fdb si m\u00f4\u017eete zdarma stiahnu\u0165 bez SMS z devcentra<\/u><\/a><\/noindex>.<\/p>\n

Mimochodem, n\u011bkdy se vyskytuj\u00ed i jin\u00e9 prefixy, nejen 0x8007. V tak smutn\u00e9 situaci je pro pochopen\u00ed HRESULT (\u201ev\u00fdsledek\u201c nebo \u201ehandle v\u00fdsledku\u201c) pot\u0159eba se pono\u0159it je\u0161t\u011b hloub\u011bji do dokument\u00e1cii<\/u><\/a><\/noindex> pro v\u00fdvoj\u00e1\u0159e. V b\u011b\u017en\u00e9m \u017eivot\u011b bych v\u00e1m to rad\u011bji nedoporu\u010dil, ale pokud v\u00e1s to p\u0159esto zaj\u00edm\u00e1 nebo v\u00e1s tla\u010d\u00ed do kouta, te\u010f u\u017e v\u00edte, co d\u011blat.<\/p>\n

Ale p\u00e1nov\u00e9 z Microsoftu na n\u00e1s p\u0159ece jen trochu mysleli a p\u0159edstavili sv\u011btu n\u00e1stroj ERR<\/u><\/a><\/noindex>. Je to kousek konzolov\u00e9ho \u0161t\u011bst\u00ed, kter\u00fd dok\u00e1\u017ee p\u0159ekl\u00e1dat chybov\u00e9 k\u00f3dy do lidsk\u00e9 \u0159e\u010di bez pou\u017eit\u00ed Googlu. Funguje to p\u0159ibli\u017en\u011b takto.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# pro hex 0x54f \/ des. 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Do\u0161lo k intern\u00ed chyb\u011b.\n# jako HRESULT: Z\u00e1va\u017enost: \u00daSP\u011aCH (0), ZA\u0158\u00cdZEN\u00cd_NULL (0x0), K\u00f3d 0x54f\n# pro hex 0x54f \/ des. 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Do\u0161lo k intern\u00ed chyb\u011b.\n# 2 shody nalezeny pro \"0x54f\"<\/code><\/pre>\n
Vznik\u00e1 legitimn\u00ed ot\u00e1zka: pro\u010d rovnou nezapisujeme do log\u016f roz\u0161ifrov\u00e1n\u00ed, ale nech\u00e1v\u00e1me tyto tajemn\u00e9 k\u00f3dy? Odpov\u011b\u010f le\u017e\u00ed ve t\u0159et\u00edch aplikac\u00edch. Kdy\u017e s\u00e1m vol\u00e1\u0161 n\u011bjak\u00e9 vol\u00e1n\u00ed WinAPI, tak nen\u00ed probl\u00e9m jeho odpov\u011b\u010f roz\u0161ifrovat, proto\u017ee k tomu existuje speci\u00e1ln\u00ed vol\u00e1n\u00ed WinAPI. Ale jak u\u017e bylo \u0159e\u010deno, do na\u0161ich log\u016f se dostane v\u0161echno, co k n\u00e1m p\u0159ijde v odpov\u011bd\u00edch. A tady by se pro roz\u0161ifrov\u00e1n\u00ed musely neust\u00e1le monitorovat tyto proudy my\u0161lenek, vyb\u00edrat z nich kousky s chybami syst\u00e9mu Windows, roz\u0161ifrovat je a vkl\u00e1dat zp\u011bt. \u0158ekn\u011bme si up\u0159\u00edmn\u011b, nen\u00ed to moc vzru\u0161uj\u00edc\u00ed \u010dinnost.<\/p>\n
Windows File Management API <\/strong>se pou\u017e\u00edv\u00e1 na v\u0161echny zp\u016fsoby p\u0159i pr\u00e1ci se soubory. Vytv\u00e1\u0159en\u00ed soubor\u016f, maz\u00e1n\u00ed, otev\u00edr\u00e1n\u00ed pro z\u00e1pis, pr\u00e1ce s atributy a dal\u0161\u00ed a dal\u0161\u00ed.<\/p>\n
V\u00fd\u0161e zm\u00edn\u011bn\u00e9 PowerShell Direct<\/strong> je analogem VIX API ve sv\u011bt\u011b Hyper-V. Bohu\u017eel, nen\u00ed tak flexibiln\u00ed: m\u00e1 spoustu omezen\u00ed ohledn\u011b funk\u010dnosti, nefunguje s ka\u017edou verz\u00ed hostitele a daleko ne se v\u0161emi hosty.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Mysl\u00edm, \u017ee niet \u010dloveka, ktor\u00fd by pracoval s Windowsom a nikdy nevidel chyby spojen\u00e9 s RPC. Napriek popul\u00e1rnemu omylu to nie je nejak\u00fd jednotn\u00fd protokol, ale ak\u00fdko\u013evek klient-server protokol, ktor\u00fd sp\u013a\u0148a nieko\u013eko parametrov. Ak v\u0161ak v na\u0161ich logoch vid\u00edme chybu RPC, v 90% pr\u00edpadov to bude chyba z Microsoft RPC, ktor\u00fd je s\u00fa\u010das\u0165ou DCOM (Distributed Component Object Model). Na internete n\u00e1jdete obrovsk\u00e9 mno\u017estvo dokument\u00e1cie na t\u00fato t\u00e9mu, av\u0161ak ve\u013ek\u00e1 \u010das\u0165 z nej je zna\u010dne zastaran\u00e1. Ak v\u0161ak m\u00e1te siln\u00fa t\u00fa\u017ebu \u0161tudova\u0165 t\u00e9mu, m\u00f4\u017eem odporu\u010di\u0165 \u010dl\u00e1nky \u010co je RPC?<\/u><\/a><\/noindex>, Ako RPC funguje<\/u> <\/a><\/noindex>a dlh\u00fd zoznam ch\u00fdb RPC<\/u><\/a><\/noindex>.<\/p>\n
Hlavn\u00e9 pr\u00ed\u010diny v\u00fdskytu ch\u00fdb RPC v na\u0161ich logoch \u2014 to s\u00fa ne\u00faspe\u0161n\u00e9 pokusy o interakciu medzi komponentmi VBR (server > proxy, napr\u00edklad) a naj\u010dastej\u0161ie kv\u00f4li probl\u00e9mom s komunik\u00e1ciou.<\/p>\n
Najvy\u0161\u0161ia top medzi v\u0161etk\u00fdmi topmi \u2014 to je chyba The RPC server is unavailable (1722). Ak to povieme jednoducho, klient sa nedok\u00e1zal pripoji\u0165 k serveru. Ako a pre\u010do \u2014 na to nie je jednotn\u00e1 odpove\u010f, ale zvy\u010dajne ide o probl\u00e9m s autentifik\u00e1ciou alebo so sie\u0165ov\u00fdm pr\u00edstupom na port 135. To je charakteristick\u00e9 pre infra\u0161trukt\u00fary s dynamick\u00fdm pride\u013eovan\u00edm portov. Na t\u00fato t\u00e9mu existuje dokonca samostatn\u00e1 KVP<\/u><\/a><\/noindex>. A u Microsoftu \u2014 obsiahly sprievodca<\/u><\/a><\/noindex> na h\u013eadanie pr\u00ed\u010din por\u00fach.<\/p>\n
Druh\u00e1 najpopul\u00e1rnej\u0161ia chyba: There are no more endpoints available from the endpoint mapper (1753). RPC klient alebo server sa nedok\u00e1zali priradi\u0165 port. Obvykle sa vyskytuje, ke\u010f bol server (v na\u0161om pr\u00edpade hostite\u013esk\u00fd stroj) nastaven\u00fd na dynamick\u00e9 pridelovanie portov z \u00fazkeho rozsahu, ktor\u00fd sa vy\u010derpal. A ak sa na to pozrieme zo strany klienta (v na\u0161om pr\u00edpade VBR servera), znamen\u00e1 to, \u017ee n\u00e1\u0161 VeeamVssAgent sa bu\u010f nespustil, alebo nebol registrovan\u00fd ako RPC rozhran\u00ed. Na t\u00fato t\u00e9mu je tie\u017e samostatn\u00e1 KVP<\/u><\/a><\/noindex>.<\/p>\n
A aby sme uzavreli Top-3 ch\u00fdb RPC, spome\u0148me RPC function call failed (1726). Objavuje sa, ak bolo pripojenie vytvoren\u00e9, ale RPC po\u017eiadavky nefunguj\u00fa. Napr\u00edklad sa p\u00fdtame na inform\u00e1cie o stave VSS (n\u00e1hodou sa pr\u00e1ve teraz rob\u00ed shadow copy, a my sa pok\u00fa\u0161ame pr\u00edstupova\u0165), a v odpovedi je ticho a ignor\u00e1cia.<\/p>\n
Windows Tape Backup API <\/strong>je potrebn\u00e9 na pr\u00e1cu s p\u00e1skov\u00fdmi kni\u017enicami alebo pohonmi. Ako som u\u017e spomenul na za\u010diatku: p\u00edsa\u0165 vlastn\u00e9 ovl\u00e1da\u010de a mu\u010di\u0165 sa potom s podporou ka\u017ed\u00e9ho zariadenia n\u00e1s nete\u0161\u00ed. Preto nem\u00e1 Veeam \u017eiadne vlastn\u00e9 ovl\u00e1da\u010de. V\u0161etko ide cez \u0161tandardn\u00e9 API, ktor\u00e9ho podporu zabezpe\u010duj\u00fa sami v\u00fdrobcovia hardv\u00e9ru. Takto je to ove\u013ea logickej\u0161ie, v\u0161ak?<\/p>\n
SMB\/CIFS<\/strong> V\u0161etci ich zvykn\u00fa p\u00edsa\u0165 ved\u013ea seba, hoci nie v\u0161etci si pam\u00e4taj\u00fa, \u017ee CIFS (Common Internet File System) \u2014 to je len s\u00fakromn\u00e1 verzia SMB (Server Message Block). Tak\u017ee na zov\u0161eobecnen\u00ed t\u00fdchto pojmov nie je ni\u010d zl\u00e9. Samba \u2014 to je u\u017e realiz\u00e1cia pre LinuxUnix a m\u00e1 svoje vlastnosti, ale to som sa odklonil od t\u00e9my. \u010co je tu d\u00f4le\u017eit\u00e9: ke\u010f Veeam \u017eiada, aby sa nie\u010do zap\u00edsalo po UNC ceste (serverdirectory), server pou\u017e\u00edva hierarchiu ovl\u00e1da\u010dov s\u00faborov\u00e9ho syst\u00e9mu, vr\u00e1tane mup a mrxsmb, na z\u00e1pis na zdie\u013ean\u00fa zlo\u017eku. Pod\u013ea toho aj chyby bud\u00fa generova\u0165 tieto ovl\u00e1da\u010de.<\/p>\n
Ned\u00e1 sa ob\u00eds\u0165 bez Winsock API<\/strong>. Ak potrebuje nie\u010do spravi\u0165 cez sie\u0165, VBR pracuje cez Windows Socket API, zn\u00e1me medzi \u013eu\u010fmi ako Winsock. Tak\u017ee ak vid\u00edme v logu kombin\u00e1ciu IP:Port, to je ono. V ofici\u00e1lnej dokument\u00e1cii je slu\u0161n\u00fd zoznam mo\u017en\u00fdch ch\u00fdb<\/u><\/a><\/noindex>.<\/p>\n
V\u00fd\u0161e zm\u00edn\u011bn\u00e9 WMI<\/strong> (Windows Management Instrumentation) \u2014 je mocn\u00e9 API na spr\u00e1vu v\u0161etk\u00e9ho a v\u0161etk\u00fdch vo svete Windows. Napr\u00edklad pri pr\u00e1ci s Hyper-V prebiehaj\u00fa takmer v\u0161etky po\u017eiadavky na hostite\u013ea pr\u00e1ve cez neho. Skr\u00e1tka, je to celkom nenahradite\u013en\u00fd a ve\u013emi siln\u00fd n\u00e1stroj vo svojich mo\u017enostiach. Pri pokusoch pom\u00f4c\u0165 zisti\u0165, kde a \u010do sa pokazilo, ve\u013emi pom\u00e1ha vstavan\u00fd n\u00e1stroj WBEMtest.exe.<\/p>\n
A posledn\u00fd na zozname, no rozhodne nie najmenej v\u00fdznamn\u00fd \u2014 VSS<\/strong> (Volume Shadow Storage). T\u00e9ma je tak\u00e1 nevy\u010derpate\u013en\u00e1 a z\u00e1hadn\u00e1, ako je nap\u00edsan\u00fdch dokument\u00e1ci\u00ed. Shadow Copy je najlep\u0161ie ch\u00e1pa\u0165 ako \u0161peci\u00e1lny typ sn\u00edmky, ktorou v podstate je. V\u010faka nemu je mo\u017en\u00e9 v VMware robi\u0165 aplik\u00e1ciou konzistentn\u00e9 z\u00e1lohy, a v Hyper-V takmer v\u0161etko. M\u00e1m v pl\u00e1ne nap\u00edsa\u0165 samostatn\u00fd \u010dl\u00e1nok s akousi zhr\u0148uj\u00facou inform\u00e1ciou o VSS, ale zatia\u013e m\u00f4\u017eete sk\u00fasi\u0165 pre\u010d\u00edta\u0165 tento popis<\/u><\/a><\/noindex>. Len opatrne, pokus pochopi\u0165 VSS na prv\u00fdkr\u00e1t m\u00f4\u017ee vies\u0165 k poraneniu hlavy.<\/p>\n
Na tomto by sme sa asi mohli zastavi\u0165. \u00dalohu vysvetli\u0165 najz\u00e1kladnej\u0161ie veci pova\u017eujem za splnen\u00fa, tak\u017ee v nasleduj\u00facej kapitole sa u\u017e pozrieme na logy. Ale ak m\u00e1te ot\u00e1zky, nev\u00e1hajte ich vyjadri\u0165 v koment\u00e1roch.<\/p>\n<\/p>\n
Zdroj: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d… \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433\u0430 \u043f\u043e \u043b\u043e\u0433\u0430\u043c. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0434\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438\u0441\u044c \u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0438 \u0431\u0430\u0437\u043e\u0432\u044b\u0445 \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u0432 \u0438 \u043e\u0434\u043d\u0438\u043c \u0433\u043b\u0430\u0437\u043a\u043e\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043e\u0431\u0449\u0443\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 Veeam, \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0417\u0430\u0434\u0430\u0447\u0430 \u043d\u0430 \u044d\u0442\u0443 — \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u043b\u043e\u0433 \u0444\u0430\u0439\u043b\u044b, \u0447\u0442\u043e \u0437\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0432 \u043d\u0438\u0445 \u043e\u0442\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0430 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442 \u043a\u0430\u043a \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442. \u041a\u0430\u043a \u0432\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u0447\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97730,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Odkia\u013e poch\u00e1dzaj\u00fa protokoly? Veeam Log Diving | ProHoster","description":"Pokra\u010dujeme v na\u0161om ponoren\u00ed do fascinuj\u00faceho sveta ve\u0161tenia...","canonical_url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sk_SK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0442\u043a\u0443\u0434\u0430 \u0431\u0435\u0440\u0443\u0442\u0441\u044f \u043b\u043e\u0433\u0438? Veeam Log Diving | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d...","og:url":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-21T06:42:22+00:00","article:modified_time":"2020-10-21T06:42:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97729","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:14:39","updated":"2022-09-30 13:30:55","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sk\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}