{"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\/pl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Sk\u0105d pochodz\u0105 logi? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Sk\u0105d<\/p>\n

Kontynuujemy nasze zanurzenie w fascynuj\u0105cy \u015bwiat troubleshootingu opartego na logach. W poprzedniej artykule<\/a><\/noindex> uzgodnili\u015bmy znaczenie podstawowych termin\u00f3w i rzucili\u015bmy okiem na og\u00f3ln\u0105 struktur\u0119 Veeam jako jednego aplikacji. Zadanie na dzi\u015b polega na zrozumieniu, jak tworzone s\u0105 pliki dziennik\u00f3w, jakie informacje w nich si\u0119 znajduj\u0105 i dlaczego wygl\u0105daj\u0105 tak, jak wygl\u0105daj\u0105.<\/p>\n

Jak my\u015blicie, czym w og\u00f3le s\u0105 te \u201elogi\u201d? Wed\u0142ug wi\u0119kszo\u015bci logi jakiejkolwiek aplikacji powinny pe\u0142ni\u0107 rol\u0119 wszechmog\u0105cej istoty, kt\u00f3ra przez wi\u0119kszo\u015b\u0107 czasu przebywa gdzie\u015b na marginesach, ale w odpowiednim momencie pojawia si\u0119 z nienacka w l\u015bni\u0105cej zbroi i wszystkich ratuje. To znaczy, powinny zawiera\u0107 wszystko, pocz\u0105wszy od najmniejszych b\u0142\u0119d\u00f3w w ka\u017cdym komponencie, a\u017c po pojedyncze transakcje bazy danych. I tak po wyst\u0105pieniu b\u0142\u0119du powinna si\u0119 od razu pojawi\u0107 informacja, jak naprawi\u0107 sytuacj\u0119. I wszystko to powinno zmie\u015bci\u0107 si\u0119 w paru megabajtach, nie wi\u0119cej. To przecie\u017c tylko tekst! Nie mog\u0105 pliki tekstowe zajmowa\u0107 dziesi\u0105tek gigabajt\u00f3w, gdzie\u015b to s\u0142ysza\u0142em!<\/p>\n

Tak wi\u0119c, logi<\/h2>\n

W rzeczywistym \u015bwiecie logi to zaledwie archiwum informacji diagnostycznych. A co tam przechowywa\u0107, sk\u0105d bra\u0107 informacje do przechowywania i jak szczeg\u00f3\u0142owe powinny by\u0107, decyduj\u0105 sami programi\u015bci. Niekt\u00f3rzy wybieraj\u0105 minimalizm, przechowuj\u0105c tylko zapisy poziomu W\u0141\u0104CZ\/WY\u0141\u0104CZ, a inni starannie zbieraj\u0105 wszystko, co tylko mog\u0105. Jest te\u017c po\u015brednia opcja z mo\u017cliwo\u015bci\u0105 wyboru tzw. poziomu logowania, kiedy sam okre\u015blasz, jak szczeg\u00f3\u0142owe informacje chcesz przechowa\u0107 i jak wiele miejsca masz na dyskach =) VBR ma takich poziom\u00f3w a\u017c sze\u015b\u0107, swoj\u0105 drog\u0105. I uwierzcie mi, nie chcecie widzie\u0107, co si\u0119 dzieje przy maksymalnym szczeg\u00f3\u0142owym logowaniu przy wolnym miejscu na waszym dysku.<\/p>\n

Dobrze. Mniej wi\u0119cej zrozumieli\u015bmy, co chcemy zachowa\u0107, ale pojawia si\u0119 s\u0142uszne pytanie: sk\u0105d bra\u0107 t\u0119 informacj\u0119? Cz\u0119\u015b\u0107 zdarze\u0144 do logowania oczywi\u015bcie tworzymy sami w naszych wewn\u0119trznych procesach. Ale co zrobi\u0107, gdy dochodzi do interakcji z zewn\u0119trznym \u015brodowiskiem? Aby nie wpa\u015b\u0107 w absolutny chaos pe\u0142en obej\u015b\u0107 i w\u0142asnych rozwi\u0105za\u0144, Veeam ma tendencj\u0119 do niewynajdywania ju\u017c wynalezionych rozwi\u0105za\u0144. Zawsze, gdy istnieje ju\u017c gotowe API, wbudowana funkcja systemu, biblioteka itp., oddamy priorytet gotowym rozwi\u0105zaniom, zanim zaczniemy tworzy\u0107 nasze wymy\u015blne rozwi\u0105zania. Chocia\u017c i takich r\u00f3wnie\u017c nie brakuje. Dlatego przy analizie log\u00f3w wa\u017cne jest, aby zrozumie\u0107, \u017ce zdecydowana wi\u0119kszo\u015b\u0107 b\u0142\u0119d\u00f3w pochodzi z wiadomo\u015bci od zewn\u0119trznych API, wywo\u0142a\u0144 systemowych i innych bibliotek. W tej sytuacji rola VBR sprowadza si\u0119 do przesy\u0142ania tych b\u0142\u0119d\u00f3w do plik\u00f3w log\u00f3w w stanie, w jakim si\u0119 znajduj\u0105. A g\u0142\u00f3wnym zadaniem u\u017cytkownika jest nauczenie si\u0119 rozumienia, kt\u00f3ra linia od kogo pochodzi i za co ten \u201ekto\u201d odpowiada. Dlatego, je\u015bli kod b\u0142\u0119du z dziennika VBR prowadzi ci\u0119 na stron\u0119 MSDN, jest to normalne i w\u0142a\u015bciwe.<\/p>\n

Jak wcze\u015bniej ustalili\u015bmy: Veeam to aplikacja oparta na SQL. Oznacza to, \u017ce wszystkie ustawienia, wszelkie informacje i wszystko, co niezb\u0119dne do prawid\u0142owego funkcjonowania \u2014 wszystko to jest przechowywane w jego bazie. St\u0105d prosta prawda: to, czego nie ma w logach, prawdopodobnie znajduje si\u0119 w bazie. Ale to nie jest z\u0142oty \u015brodek: niekt\u00f3rych rzeczy nie ma ani w lokalnych logach komponent\u00f3w Veeam, ani w jego bazie. Dlatego trzeba nauczy\u0107 si\u0119 analizowa\u0107 logi hosta, logi lokalnej maszyny i logi wszystkiego, co bierze udzia\u0142 w procesie tworzenia kopii zapasowej i restauracji. Czasami zdarza si\u0119, \u017ce potrzebne informacje s\u0105 zupe\u0142nie nieobecne. Taki jest los. <\/p>\n

Kilka przyk\u0142ad\u00f3w takich API<\/h4>\n

Ten wykaz nie ma na celu by\u0107 kompletnym, wi\u0119c nie nale\u017cy w nim szuka\u0107 ostatecznej prawdy. Jego zadaniem jest jedynie pokazanie najcz\u0119\u015bciej u\u017cywanych zewn\u0119trznych API i technologii stosowanych w naszych produktach.<\/p>\n

Zacznijmy od VMware<\/strong>. <\/p>\n

Pierwszym na li\u015bcie b\u0119dzie vSphere API<\/strong>. U\u017cywany do uwierzytelniania, odczytu hierarchii, tworzenia i usuwania zrzut\u00f3w, zapytania o informacje o maszynach oraz wielu (bardzo wielu) innych rzeczy. Funkcjonalno\u015b\u0107 rozwi\u0105zania jest bardzo szeroka, dlatego wszystkim ch\u0119tnym mog\u0119 poleci\u0107 VMware vSphere API Reference dla wersji 5.5<\/u><\/a><\/noindex> i 6.0<\/u><\/a><\/noindex>. Dla bardziej aktualnych wersji wystarczy wyszuka\u0107 w internecie.<\/p>\n

VIX API<\/strong>. Czarna magia hypervisora, dla kt\u00f3rej istnieje osobna lista b\u0142\u0119d\u00f3w<\/u><\/a><\/noindex>. VMware API do pracy z plikami na ho\u015bcie bez \u0142\u0105czenia si\u0119 z nimi przez sie\u0107. Ostatnia deska ratunku, gdy trzeba umie\u015bci\u0107 plik w maszynie, do kt\u00f3rej nie ma lepszego kana\u0142u komunikacji. To rodzi b\u00f3l i cierpienie, je\u015bli plik jest du\u017cy, a host obci\u0105\u017cony. Tutaj dzia\u0142a zasada, \u017ce nawet 56,6 Kb\/s to lepiej ni\u017c 0 Kb\/s. W Hyper-V podobna rzecz nazywa si\u0119 PowerShell Direct. Ale tak by\u0142o tylko do pojawienia si\u0119<\/p>\n

vSphere Web Services API<\/strong> Zaczynaj\u0105c od vSphere 6.0 (z grubsza, poniewa\u017c ten API zosta\u0142 po raz pierwszy zaprezentowany w wersji 5.5) jest u\u017cywane do pracy z maszynami wirtualnymi i ju\u017c praktycznie wsz\u0119dzie zast\u0105pi\u0142o VIX. W zasadzie to kolejny API do zarz\u0105dzania vSphere. Osobom zainteresowanym mog\u0119 poleci\u0107 zapoznanie si\u0119 z \u015bwietnym<\/u><\/a><\/noindex> podr\u0119cznikiem. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Biblioteka, o kt\u00f3rej cz\u0119\u015bciowo m\u00f3wiono w tej artyku\u0142<\/u><\/a><\/noindex>. U\u017cywany do odczytu wirtualnych dysk\u00f3w. Dawno temu by\u0142 cz\u0119\u015bci\u0105 VIX, ale z czasem zosta\u0142 przeniesiony do osobnego produktu. Jednak jako spadkobierca u\u017cywa tych samych kod\u00f3w b\u0142\u0119d\u00f3w co VIX. Ale z jakiego\u015b powodu w samym SDK nie ma opisu tych b\u0142\u0119d\u00f3w. Dlatego w praktyce ustalono, \u017ce b\u0142\u0119dy VDDK z innymi kodami to jedynie translacja z kodu binarnego na dziesi\u0119tny. Sk\u0142ada si\u0119 z dw\u00f3ch cz\u0119\u015bci \u2013 pierwsza po\u0142owa stanowi niedokumentowane informacje o kontek\u015bcie, a druga cz\u0119\u015b\u0107 to tradycyjne b\u0142\u0119dy VIX\/VDDK. Na przyk\u0142ad, gdy widzimy:<\/p>\n

B\u0142\u0105d VDDK: 21036749815809. Nieznany b\u0142\u0105d<\/code><\/p>\n

To konwertujemy to na hex i otrzymujemy 132200000001. Nieinformacyjne rozpocz\u0119cie 132200 po prostu odrzucamy, a reszta b\u0119dzie naszym kodem b\u0142\u0119du (VDDK 1: Unknown error). O najcz\u0119stszych b\u0142\u0119dach VDDK niedawno by\u0142a osobna artyku\u0142<\/u><\/a><\/noindex>.<\/p>\n

Teraz sp\u00f3jrzmy na Windows<\/strong>. <\/p>\n

Tutaj wszystko, co potrzebne i wa\u017cne dla nas, mo\u017cna znale\u017a\u0107 w standardowym Podgl\u0105dzie zdarze\u0144<\/strong>. Ale jest jeden haczyk: zgodnie z wielowiekow\u0105 tradycj\u0105 Windows rejestruje jedynie numer b\u0142\u0119du, a nie pe\u0142ny tekst. Na przyk\u0142ad, b\u0142\u0105d 5 to \"Access denied\", a 1722 to \"The RPC server is unavailable\", oraz 10060 to \"Connection timed out\". Oczywi\u015bcie, dobrze jest, je\u015bli pami\u0119tasz te najbardziej znane, ale co zrobi\u0107 z dotychczas niewidzianymi? <\/p>\n

Aby \u017cycie nie wydawa\u0142o si\u0119 zbyt s\u0142odkie, b\u0142\u0119dy s\u0105 r\u00f3wnie\u017c przechowywane w postaci szesnastkowej, z prefiksem 0x8007. Na przyk\u0142ad 0x8007000e \u2014 to w rzeczywisto\u015bci 14, Out of Memory. Dlaczego i dla kogo tak zrobiono \u2014 to tajemnica otoczona mrokiem. Jednak pe\u0142n\u0105 list\u0119 b\u0142\u0119d\u00f3w mo\u017cna pobra\u0107 za darmo i bez SMS z centrum deweloperskiego<\/u><\/a><\/noindex>.<\/p>\n

Przy okazji, czasami wyst\u0119puj\u0105 r\u00f3wnie\u017c inne prefiksy, a nie tylko 0x8007. W tak smutnej sytuacji dla zrozumienia HRESULT (\u201euchwyt wyniku\u201d) trzeba jeszcze g\u0142\u0119biej wnika\u0107 w dokumentacj\u0119<\/u><\/a><\/noindex> dla deweloper\u00f3w. W normalnym \u017cyciu nie radzi\u0142bym Wam tego robi\u0107, ale je\u015bli nagle czujecie si\u0119 przyparci do muru lub po prostu jeste\u015bcie ciekawi, teraz wiecie, co robi\u0107.<\/p>\n

Ale koledzy z Microsoftu nieco si\u0119 nad nami zlitowali i przedstawili \u015bwiatu narz\u0119dzie ERR<\/u><\/a><\/noindex>. To ma\u0142y kawa\u0142ek konsolowego szcz\u0119\u015bcia, kt\u00f3ry potrafi t\u0142umaczy\u0107 kody b\u0142\u0119d\u00f3w na ludzki j\u0119zyk bez u\u017cycia Google. Dzia\u0142a to mniej wi\u0119cej tak.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# dla hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Wyst\u0105pi\u0142 b\u0142\u0105d wewn\u0119trzny.\n# jako HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f\n# dla hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Wyst\u0105pi\u0142 b\u0142\u0105d wewn\u0119trzny.\n# 2 pasuj\u0105ce wpisy znalezione dla \"0x54f\"<\/code><\/pre>\n
Pojawia si\u0119 uzasadnione pytanie: dlaczego nie zapisujemy od razu w logach wyja\u015bnie\u0144, a zostawiamy te tajemnicze kody? Odpowied\u017a le\u017cy w aplikacjach zewn\u0119trznych. Kiedy sam wywo\u0142ujesz jak\u0105\u015b funkcj\u0119 WinAPI, \u0142atwo jest zrozumie\u0107 jej odpowied\u017a, poniewa\u017c jest do tego nawet specjalne wywo\u0142anie WinAPI. Ale jak ju\u017c wspomniano, do naszych log\u00f3w trafia wszystko, co tylko przychodzi w odpowiedziach. A tu dla zrozumienia trzeba by by\u0142o ci\u0105gle monitorowa\u0107 ten strumie\u0144 \u015bwiadomo\u015bci, wy\u0142apywa\u0107 z niego fragmenty z b\u0142\u0119dami systemu Windows, rozkodowywa\u0107 je i wstawia\u0107 z powrotem. Powiedzmy szczerze, to nie jest najbardziej fascynuj\u0105ce zaj\u0119cie.<\/p>\n
Interfejs API zarz\u0105dzania plikami systemu Windows <\/strong>jest w r\u00f3\u017cnoraki spos\u00f3b u\u017cywany podczas pracy z plikami. Tworzenie plik\u00f3w, usuwanie, otwieranie do zapisu, praca z atrybutami i tak dalej.<\/p>\n
Wspomniany wcze\u015bniej PowerShell Direct<\/strong> jest odpowiednikiem VIX API w \u015bwiecie Hyper-V. Niestety, nie jest tak elastyczny: ma mn\u00f3stwo ogranicze\u0144 funkcjonalnych, nie dzia\u0142a z ka\u017cd\u0105 wersj\u0105 hosta i daleko nie z wszystkimi go\u015b\u0107mi.<\/p>\n
RPC<\/strong> (Remote Procedure Call) My\u015bl\u0119, \u017ce nie ma osoby, kt\u00f3ra pracowa\u0142a z systemem Windows i nie napotka\u0142a b\u0142\u0119d\u00f3w zwi\u0105zanych z RPC. Wbrew powszechnemu przekonaniu, to nie jest jeden protok\u00f3\u0142, ale ka\u017cdy protok\u00f3\u0142 klient-serwer, kt\u00f3ry spe\u0142nia okre\u015blone wymagania. Je\u015bli jednak w naszych logach wyst\u0119puje b\u0142\u0105d RPC, w 90% przypadk\u00f3w b\u0119dzie to b\u0142\u0105d Microsoft RPC, kt\u00f3ry jest cz\u0119\u015bci\u0105 DCOM (Distributed Component Object Model). W sieci mo\u017cna znale\u017a\u0107 ogromn\u0105 ilo\u015b\u0107 dokumentacji na ten temat, jednak wi\u0119kszo\u015b\u0107 z niej jest przestarza\u0142a. Je\u015bli jednak jeste\u015b zdecydowany, by zg\u0142\u0119bi\u0107 temat, mog\u0119 poleci\u0107 artyku\u0142y Czym jest RPC?<\/u><\/a><\/noindex>, Jak dzia\u0142a RPC<\/u> <\/a><\/noindex>i d\u0142ug\u0105 list\u0119 b\u0142\u0119d\u00f3w RPC<\/u><\/a><\/noindex>.<\/p>\n
G\u0142\u00f3wne powody wyst\u0105pienia b\u0142\u0119d\u00f3w RPC w naszych logach to nieudane pr\u00f3by interakcji mi\u0119dzy komponentami VBR (serwer > proxy, na przyk\u0142ad) i najcz\u0119\u015bciej z powodu problem\u00f3w z \u0142\u0105czno\u015bci\u0105.<\/p>\n
Najwi\u0119ksza z najwi\u0119kszych \u2014 to b\u0142\u0105d The RPC server is unavailable (1722). Prosto m\u00f3wi\u0105c, klient nie m\u00f3g\u0142 nawi\u0105za\u0107 po\u0142\u0105czenia z serwerem. Jak i dlaczego \u2014 nie ma jednego odpowiedzi, ale zazwyczaj jest to problem z uwierzytelnianiem lub z dost\u0119pem do portu 135. To ostatnie jest charakterystyczne dla infrastruktury z dynamicznie przydzielanymi portami. Na ten temat jest nawet osobny Kb<\/u><\/a><\/noindex>. A Microsoft \u2014 obszerny poradnik<\/u><\/a><\/noindex> na temat poszukiwania przyczyn awarii.<\/p>\n
Drugim najpopularniejszym b\u0142\u0119dem jest: There are no more endpoints available from the endpoint mapper (1753). Klient RPC lub serwer nie mogli przypisa\u0107 sobie portu. Zwykle wyst\u0119puje, gdy serwer (w naszym przypadku maszyna wirtualna) zosta\u0142 skonfigurowany na dynamiczne przydzielanie port\u00f3w z w\u0105skiego zakresu, kt\u00f3ry si\u0119 wyczerpa\u0142. A je\u015bli spojrze\u0107 od strony klienta (w naszym przypadku serwer VBR), oznacza to, \u017ce nasz VeeamVssAgent albo si\u0119 nie uruchomi\u0142, albo nie zosta\u0142 zarejestrowany jako interfejs RPC. Na ten temat r\u00f3wnie\u017c istnieje osobny Kb<\/u><\/a><\/noindex>.<\/p>\n
A \u017ceby zako\u0144czy\u0107 nasz\u0105 top-3 b\u0142\u0119d\u00f3w RPC, przypomnijmy b\u0142\u0105d RPC function call failed (1726). Pojawia si\u0119, je\u015bli po\u0142\u0105czenie zosta\u0142o nawi\u0105zane, ale \u017c\u0105dania RPC nie s\u0105 realizowane. Na przyk\u0142ad, prosimy o informacje o statusie VSS (mo\u017ce akurat w tej chwili wykonywana jest kopia zapasowa, a my pr\u00f3bujemy si\u0119 do niej dosta\u0107), a w odpowiedzi otrzymujemy cisz\u0119 i ignorowanie.<\/p>\n
Windows Tape Backup API <\/strong>jest potrzebny do pracy z bibliotekami ta\u015bmowymi lub nap\u0119dami. Jak wspomnia\u0142em na pocz\u0105tku: pisanie w\u0142asnych sterownik\u00f3w i p\u00f3\u017aniejsze trudno\u015bci z obs\u0142ug\u0105 ka\u017cdego urz\u0105dzenia nie sprawia nam przyjemno\u015bci. Dlatego Veeam nie ma \u017cadnych w\u0142asnych sterownik\u00f3w. Wszystko przez standardowe API, kt\u00f3rego wsparcie realizuj\u0105 sami dostawcy sprz\u0119tu. Tak jest znacznie bardziej logiczne, prawda?<\/p>\n
SMB\/CIFS<\/strong> Wszyscy z przyzwyczajenia pisz\u0105 je obok siebie, chocia\u017c nie wszyscy pami\u0119taj\u0105, \u017ce CIFS (Common Internet File System) to po prostu prywatna wersja SMB (Server Message Block). Tak wi\u0119c uog\u00f3lnienie tych poj\u0119\u0107 nie jest niczym z\u0142ym. Samba to ju\u017c realizacja Linux\/Unix, kt\u00f3ra ma swoje szczeg\u00f3lne cechy, ale odbieg\u0142em od tematu. Co jest tu wa\u017cne: kiedy Veeam prosi o zapisanie czego\u015b przez \u015bcie\u017ck\u0119 UNC (serverdirectory), serwer wykorzystuje hierarchi\u0119 sterownik\u00f3w systemu plik\u00f3w, w tym mup i mrxsmb, do zapisu na udost\u0119pnionym zasobie. Odpowiednio, b\u0142\u0119dy b\u0119d\u0105 r\u00f3wnie\u017c generowane przez te sterowniki.<\/p>\n
Nie da si\u0119 ob\u0119dzie bez Winsock API<\/strong>. Je\u015bli trzeba co\u015b zrobi\u0107 w sieci, VBR dzia\u0142a przez Windows Socket API, powszechnie znane jako Winsock. Je\u015bli wi\u0119c widzimy w logach par\u0119 IP:Port, to w\u0142a\u015bnie to. W oficjalnej dokumentacji znajduje si\u0119 ca\u0142kiem niez\u0142a lista mo\u017cliwych b\u0142\u0119d\u00f3w<\/u><\/a><\/noindex>.<\/p>\n
Wspomniany wcze\u015bniej WMI<\/strong> (Windows Management Instrumentation) \u2014 to wszechstronne API do zarz\u0105dzania wszystkim w ekosystemie Windows. Na przyk\u0142ad, podczas pracy z Hyper-V, praktycznie wszystkie zapytania do hosta odbywaj\u0105 si\u0119 w\u0142a\u015bnie przez nie. Innymi s\u0142owy, jest to narz\u0119dzie ca\u0142kowicie niezast\u0105pione i niezwykle pot\u0119\u017cne w swoich mo\u017cliwo\u015bciach. W pr\u00f3bach zrozumienia, gdzie i co si\u0119 zepsu\u0142o, bardzo pomocne okazuje si\u0119 wbudowane narz\u0119dzie WBEMtest.exe.<\/p>\n
Ostatni w kolejno\u015bci, ale z pewno\u015bci\u0105 nie mniej wa\u017cny \u2014 VSS<\/strong> (Volume Shadow Storage). Temat jest tak niewyczerpany i tajemniczy, jak wiele napisano na jego temat dokumentacji. Shadow Copy naj\u0142atwiej zrozumie\u0107 jako szczeg\u00f3lny typ migawki, kt\u00f3rym w zasadzie jest. Dzi\u0119ki niemu w VMware mo\u017cna robi\u0107 kopie zapasowe sp\u00f3jne aplikacyjnie, a w Hyper-V prawie wszystko. Planuj\u0119 napisanie osobnego artyku\u0142u o VSS, ale na razie mo\u017cesz spr\u00f3bowa\u0107 przeczyta\u0107 ten opis<\/u><\/a><\/noindex>. Tylko ostro\u017cnie, poniewa\u017c pr\u00f3ba zrozumienia VSS bez przygotowania mo\u017ce prowadzi\u0107 do uraz\u00f3w g\u0142owy.<\/p>\n
Na tym mo\u017cna by zako\u0144czy\u0107. Uwa\u017cam, \u017ce zrealizowa\u0142em zadanie wyja\u015bnienia najprostszych rzeczy, wi\u0119c w nast\u0119pnym rozdziale ju\u017c przyjrzymy si\u0119 logom. Ale je\u015bli masz jakie\u015b pytania, nie wahaj si\u0119 ich zadawa\u0107 w komentarzach.<\/p>\n<\/p>\n
\u0179r\u00f3d\u0142o: 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\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\udd47Sk\u0105d pochodz\u0105 logi? Veeam Log Diving | ProHoster","description":"Kontynuujemy nasze zanurzenie w fascynuj\u0105cy \u015bwiat wr\u00f3\u017cb...","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","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\/pl\/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\/pl\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}