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

\"Odakle<\/p>\n

Nastavljamo s na\u0161im uronjenjem u fascinantan svijet diagnostike kroz logove. U pro\u0161lom \u010dlanku<\/a><\/noindex> dogovorili smo se o zna\u010denju osnovnih termina i jednim okom zavirili u op\u0107u strukturu Veeam-a kao jedinstvene aplikacije. Zadatak za ovu temu je shvatiti kako se formiraju log datoteke, koja se informacija u njima prikazuje i za\u0161to izgledaju onako kako izgledaju.<\/p>\n

Kako mislite, \u0161to uop\u0107e jesu ti \"logovi\"? Prema ve\u0107ini, logovima svake aplikacije trebala bi biti dodijeljena uloga sveprisutnog entiteta koji ve\u0107i dio vremena provodi negdje u pozadini, ali u pravom trenutku se pojavljuje od nigdje u sjajnom oklopu i spa\u0161ava sve. To jest, u njima bi trebali biti svi podaci, po\u010dev\u0161i od najmanjih gre\u0161aka u svakom komponentu, do pojedina\u010dnih transakcija baze. I da se odmah nakon gre\u0161ke napi\u0161e kako to ispraviti. A sve to bi se trebalo stati u nekoliko megabajta, ne vi\u0161e. To je samo tekst! Ne mogu tekstualne datoteke zauzimati desetke gigabajta, negdje sam to \u010duo!<\/p>\n

Dakle, logovi<\/h2>\n

U stvarnom svijetu logovi su samo arhiv dijagnosti\u010dkih informacija. I \u0161to tu \u010duvati, odakle uzimati informacije za pohranu i koliko detaljne one trebaju biti, odlu\u010duju sami programeri. Neki idu putem minimalizma, \u010duvaju\u0107i zapise razine UKLJU\u010cENO\/ISKLJU\u010cENO, dok se neki trudom skupljaju sve do \u010dega su mogli doprijeti. Ipak, postoji i me\u0111uprostor s mogu\u0107no\u0161\u0107u odabira takozvane razine logiranja, kada sami odre\u0111ujete koliko detaljnu informaciju \u017eelite \u010duvati i koliko imate suvi\u0161nog prostora na diskovima =) U VBR-u postoji \u010dak \u0161est takvih razina, uzgred re\u010deno. I, vjerujte, ne \u017eelite vidjeti \u0161to se doga\u0111a pri maksimalno detaljnom logiranju s dostupnim slobodnim prostorom na va\u0161em disku.<\/p>\n

U redu. Otprilike smo shvatili \u0161to \u017eelimo zadr\u017eati, ali postavlja se legitimno pitanje: odakle uzeti te informacije? Dio doga\u0111aja za logiranje, naravno, formiramo sami na\u0161im unutarnjim procesima. No \u0161to u\u010diniti kada do\u0111e do interakcije s vanjskim okru\u017eenjem? Kako bismo izbjegli kretanje u pakao pun improvizacija i krivina, Veeam te\u017ei da ne izmi\u0161lja ponovo ve\u0107 izmi\u0161ljene izume. Uvijek kada postoji ve\u0107 spreman API, ugra\u0111ena funkcija u sustav, knji\u017enica itd., dat \u0107emo prioritet gotovim rje\u0161enjima prije nego \u0161to zapo\u010dnemo s vlastitim slo\u017eenim rje\u0161enjima. Iako i toga ima dosta. Stoga je va\u017eno razumjeti prilikom analize logova da veliki dio gre\u0161aka dolazi iz poruka od vanjskih API-ja, sistemskih poziva i drugih knji\u017enica. U tom slu\u010daju, uloga VBR-a svodi se na proslije\u0111ivanje tih gre\u0161aka u log datoteke kakve jesu. A osnovni zadatak korisnika je nau\u010diti razumjeti koja je linija od koga, i za \u0161to taj \"netko\" odgovara. Stoga, ako vas kod gre\u0161ke iz VBR loga odvede na stranicu MSDN, to je normalno i ispravno.<\/p>\n

Kao \u0161to smo ranije dogovorili: Veeam je tako zvana aplikacija zasnovana na SQL-u. To zna\u010di da su svi postavke, sve informacije i zapravo sve \u0161to je potrebno za normalno funkcioniranje - sve se \u010duva u njegovoj bazi. Odavde proizlazi jednostavna istina: ono \u0161to nije u logovima, vjerojatno je u bazi. No, to nije \u010darobna kugla: nekih informacija nema ni u lokalnim logovima Veeam komponenti, ni u njegovoj bazi. Stoga je potrebno nau\u010diti kako prou\u010davati logove hosta, logove lokalnog ra\u010dunala i logove svega \u0161to sudjeluje u procesu sigurnosnog kopiranja i vra\u0107anja. Ponekad se dogodi da potrebne informacije jednostavno nisu dostupne nigdje. To je put. <\/p>\n

Nekoliko primjera takvih API-ja<\/h4>\n

Ova lista nema za cilj biti sveobuhvatna, stoga ne treba u njoj tra\u017eiti posljednju rije\u010d istine. Njena zada\u0107a - samo pokazati naj\u010de\u0161\u0107e vanjske API-je i tehnologije koje se koriste u na\u0161im proizvodima.<\/p>\n

Po\u010dnimo s VMware<\/strong>. <\/p>\n

Prvi na popisu bit \u0107e vSphere API<\/strong>. Koristi se za autentifikaciju, \u010ditanje hijerarhije, stvaranje i brisanje snimaka, zahtjev informacija o strojevima i mnoge (vrlo mnoge) druge stvari. Funkcionalnost rje\u0161enja je vrlo \u0161iroka, pa svima zainteresiranima mogu preporu\u010diti VMware vSphere API Reference za verziju 5.5<\/u><\/a><\/noindex> i 6.0<\/u><\/a><\/noindex>. Za novije verzije lako se mo\u017ee prona\u0107i putem pretra\u017eiva\u010da.<\/p>\n

VIX API<\/strong>. Crna magija hipervizora, za koju postoji poseban popis pogre\u0161aka<\/u><\/a><\/noindex>. VMware API za rad s datotekama na hostu bez povezivanja s njima putem mre\u017ee. Opcija posljednje nade, kada je potrebno staviti datoteku na ma\u0161inu, do koje nema boljeg kanala veze. Predstavlja bol i patnju, ako je datoteka velika, a host optere\u0107en. No tu vrijedi pravilo da je \u010dak 56,6 Kb\/s bolje od 0 Kb\/s. U Hyper-V sli\u010dna stvar zove se PowerShell Direct. Ali to je bilo samo do pojave<\/p>\n

vSphere Web Services API<\/strong> Po\u010dev\u0161i od vSphere 6.0 (pribli\u017eno, jer je ovaj API prvi put predstavljen u verziji 5.5) koristi se za rad s gostuju\u0107im ma\u0161inama i ve\u0107 prakti\u010dki svuda je istisnuo VIX. U su\u0161tini, to je jo\u0161 jedan API za upravljanje vSphere. Zainteresiranima bih preporu\u010dio da prou\u010de odli\u010dan<\/u><\/a><\/noindex> priru\u010dnik. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Knji\u017enica o kojoj se djelomi\u010dno govorilo u ovoj \u010dlanku<\/u><\/a><\/noindex>. Koristi se za \u010ditanje virtualnih diskova. Nekada davno bio je dio VIX-a, no s vremenom je preba\u010den u zaseban proizvod. No, na temelju naslije\u0111a koristi iste kodove gre\u0161aka kao i VIX. Me\u0111utim, iz nekog razloga u samom SDK-u nema nikakvog opisa tih gre\u0161aka. Stoga je iskustveno otkriveno da su VDDK gre\u0161ke s drugim kodovima - samo transkript iz binarnog u decimalni kod. Sastoji se od dva dijela - prva polovica predstavlja nedokumentirane informacije o kontekstu, a druga polovica - tradicionalne VIX\/VDDK gre\u0161ke. Na primjer, ako vidimo:<\/p>\n

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

Slobodno to konvertiramo u hex i dobijemo 132200000001. Neinformativni po\u010detak 132200 jednostavno ignoriramo, a ostatak \u0107e biti na\u0161 kod gre\u0161ke (VDDK 1: Nepoznata gre\u0161ka). O naj\u010de\u0161\u0107im VDDK gre\u0161kama nedavno je bila objavljena posebna \u010dlanak<\/u><\/a><\/noindex>.<\/p>\n

Sada pogledajmo Windows<\/strong>. <\/p>\n

Ovdje se sve \u0161to nam je potrebno i va\u017eno mo\u017ee prona\u0107i u standardnom Event Viewer<\/strong>. No, postoji jedan problem: prema davnoj tradiciji, Windows ne zapisuje pun tekst gre\u0161ke, ve\u0107 samo njen broj. Na primjer, gre\u0161ka 5 - to je \"Pristup odbijen\", a 1722 - to je \"RPC server je nedostupan\", a 10060 - to je \"Vrijeme povezivanja je isteklo\". Naravno, dobro je ako se sje\u0107a\u0161 najpoznatijih, ali kako biti s do sada nevi\u0111enim? <\/p>\n

A kako \u017eivot ne bi bio ba\u0161 med i mlijeko, gre\u0161ke se tako\u0111er \u010duvaju u heksadecimalnom obliku, s prefiksom 0x8007. Na primjer, 0x8007000e \u2014 zapravo ozna\u010dava 14, Out of Memory. Za\u0161to i koga je to trebalo slu\u017eiti \u2014 misterija je. Me\u0111utim, potpuni popis gre\u0161aka mo\u017ee se besplatno preuzeti bez SMS-a iz devcentra<\/u><\/a><\/noindex>.<\/p>\n

Usput, ponekad se pojavljuju i drugi prefiksi, a ne samo 0x8007. U toj tu\u017enoj situaciji, za razumijevanje HRESULT (\u201chandle rezultata\u201d) potrebno je dublje zaroniti u dokumentaciju<\/u><\/a><\/noindex> za programere. U svakodnevnom \u017eivotu ne bih vam to savjetovao, ali ako vas slu\u010dajno pritisne situacija ili vas jednostavno zanima, sada znate \u0161to u\u010diniti.<\/p>\n

Ali prijatelji u Microsoftu su se malo smilovali nad nama i predstavili svijetu alat ERR<\/u><\/a><\/noindex>. To je mali dio konzolne sre\u0107e, koji zna prevesti kodove gre\u0161aka na ljudski jezik bez kori\u0161tenja Googlea. Radi otprilike ovako.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# za heks 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Do\u0161lo je do unutarnje gre\u0161ke.\n# kao HRESULT: Te\u017eina: USPJEH (0), OBJEKT_NULL (0x0), Kod 0x54f\n# za heks 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Do\u0161lo je do unutarnje gre\u0161ke.\n# 2 podudaranja prona\u0111ena za \"0x54f\"<\/code><\/pre>\n
Postavlja se legitimno pitanje: za\u0161to odmah ne pi\u0161emo obja\u0161njenje u logove, ve\u0107 ostavljamo te tajanstvene kodove? Odgovor le\u017ei u vanjskim aplikacijama. Kada sami pozivate neki WinAPI poziv, nije te\u0161ko de\u0161ifrirati njegov odgovor jer za to postoji poseban WinAPI poziv. No, kao \u0161to je ve\u0107 re\u010deno, u na\u0161e logove dolazi sve \u0161to dolazi u odgovorima. I tada bi za de\u0161ifriranje trebalo stalno nadgledati ovaj tok svijesti, izvu\u0107i dijelove s gre\u0161kama sustava Windows, de\u0161ifrirati ih i ponovno ih umetnuti. Ispri\u010davam se, ali to nije najuzbudljiviji zadatak.<\/p>\n
Windows File Management API <\/strong>se u raznim situacijama koristi pri radu s datotekama. Kreiranje datoteka, brisanje, otvaranje za pisanje, rad s atributima i jo\u0161 mnogo toga.<\/p>\n
Navedeni PowerShell Direct<\/strong> je analogan VIX API-u u svijetu Hyper-V. Na\u017ealost, nije tako fleksibilan: ima mnogo ograni\u010denja u funkcionalnosti, ne radi sa svakom verzijom hosta i daleko ne sa svim gostima.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Mislim da nema osobe koja je radila s Windowsom, a da nije vidjela gre\u0161ke povezane s RPC-om. Unato\u010d popularnom zabludi, to nije jedinstveni protokol, ve\u0107 bilo koji klijent-poslu\u017eiteljski protokol koji zadovoljava odre\u0111ene kriterije. Ipak, ako u na\u0161im logovima postoji RPC gre\u0161ka, u 90% slu\u010dajeva \u0107e to biti gre\u0161ka od Microsoft RPC-a, koji je dio DCOM-a (Distributed Component Object Model).  Na mre\u017ei postoji ogromna koli\u010dina dokumentacije na ovu temu, no veliki dio nje je prili\u010dno zastario. Me\u0111utim, ako postoji sna\u017ena \u017eelja za prou\u010davanjem teme, mogu preporu\u010diti \u010dlanke \u0160to je RPC?<\/u><\/a><\/noindex>, Kako RPC funkcionira<\/u> <\/a><\/noindex>i dug popis RPC pogre\u0161aka<\/u><\/a><\/noindex>.<\/p>\n
Glavni uzroci pojave RPC gre\u0161aka u na\u0161im logovima \u2014 to su neuspje\u0161ni poku\u0161aji interakcije izme\u0111u VBR komponenti (poslu\u017eitelj > proxy, na primjer) i naj\u010de\u0161\u0107e zbog problema s povezivanjem.<\/p>\n
Najve\u0107i od svih gre\u0161aka \u2014 to je gre\u0161ka The RPC server is unavailable (1722). U jednostavnim rije\u010dima, klijent nije mogao uspostaviti vezu s poslu\u017eiteljem. Kako i za\u0161to \u2014 nema jedinstvenog odgovora, ali obi\u010dno je to problem s autentifikacijom ili s mre\u017enim pristupom do porta 135. To je tipi\u010dno za infrastrukture s dinami\u010dkim dodjeljivanjem portova. O ovoj temi \u010dak postoji posebna KB<\/u><\/a><\/noindex>. A kod Microsofta \u2014 opse\u017ean vodi\u010d<\/u><\/a><\/noindex> o pronala\u017eenju uzroka kvarova.<\/p>\n
Druga naj\u010de\u0161\u0107a pogre\u0161ka: There are no more endpoints available from the endpoint mapper (1753). RPC klijent ili poslu\u017eitelj nisu mogli dodijeliti port. Obi\u010dno se doga\u0111a kada je poslu\u017eitelj (u na\u0161em slu\u010daju gostuju\u0107a ma\u0161ina) konfiguriran za dinami\u010dko dodjeljivanje portova iz uskog raspona koji je istekao. A ako gledamo sa strane klijenta (u na\u0161em slu\u010daju VBR poslu\u017eitelja), to zna\u010di da na\u0161 VeeamVssAgent ili nije pokrenut, ili nije registriran kao RPC su\u010delje. Na ovu temu tako\u0111er postoji posebna KB<\/u><\/a><\/noindex>.<\/p>\n
I kako bismo zavr\u0161ili Top-3 RPC pogre\u0161ke, spomenimo RPC function call failed (1726). Ova se pogre\u0161ka pojavljuje ako je veza uspostavljena, ali RPC zahtjevi ne prolaze. Na primjer, tra\u017eimo informacije o statusu VSS (mo\u017eda se trenutno radi o shadow copy, a mi poku\u0161avamo pristupiti), a u odgovoru imamo ti\u0161inu i ignoriranje.<\/p>\n
Windows Tape Backup API <\/strong>potrebno za rad s trakastim bibliotekama ili pogonima. Kao \u0161to sam spomenuo na po\u010detku: pisanje vlastitih drajvera i mu\u010denje s podr\u0161kom za svako ure\u0111aj nam ne donosi nikakvo zadovoljstvo. Zato Veeam nema vlastite drajvere. Sve ide preko standardnog API-ja, \u010diju podr\u0161ku implementiraju sami proizvo\u0111a\u010di hardvera. Tako je mnogo logi\u010dnije, zar ne?<\/p>\n
SMB\/CIFS<\/strong> Svi to pi\u0161u jedni pored drugih, iako daleko ne pamte da je CIFS (Common Internet File System) \u2014 to je samo privatna verzija SMB-a (Server Message Block). Tako da uop\u0107e nije lo\u0161e generalizirati ta pojmova. E, Samba \u2014 to je ve\u0107 Linux\/Unix implementacija, a tu su svoje osobitosti, ali to sam skrenuo s teme. Ono \u0161to je ovdje va\u017eno: kada Veeam tra\u017ei da se ne\u0161to zapi\u0161e putem UNC putanje (serverdirectory), poslu\u017eitelj koristi hijerarhiju upravlja\u010dkih programa datote\u010dnog sustava, uklju\u010duju\u0107i mup i mrxsmb, za zapisivanje na shared. Prema tome, gre\u0161ke \u0107e tako\u0111er generirati ovi upravlja\u010dki programi.<\/p>\n
Nema \u0161anse da se obavimo bez Winsock API<\/strong>. Ako treba ne\u0161to napraviti preko mre\u017ee, VBR radi kroz Windows Socket API, poznatiji kao Winsock. Tako da ako vidimo u logu poveznicu IP:Port, to je to. U slu\u017ebenoj dokumentaciji postoji dobar popis mogu\u0107ih gre\u0161aka<\/u><\/a><\/noindex>.<\/p>\n
Navedeni WMI<\/strong> (Windows Management Instrumentation) \u2014 to je svestrani API za upravljanje svime i svima u Windows okru\u017eenju. Na primjer, prilikom rada s Hyper-V, gotovo svi zahtjevi prema hostu prolaze upravo kroz njega. Drugim rije\u010dima, to je potpuno nezamjenjivo i vrlo mo\u0107no u svojim mogu\u0107nostima. U poku\u0161ajima da se utvrdi gdje i \u0161to nije u redu, vrlo poma\u017ee ugra\u0111eni alat WBEMtest.exe.<\/p>\n
I posljednji na popisu, ali nikako ne manje va\u017ean \u2014 VSS<\/strong> (Volume Shadow Storage). Tema je toliko neiscrpna i tajanstvena koliko je mnogo dokumentacije o njoj napisano. Shadow Copy je najlak\u0161e razumjeti kao posebnu vrstu snimke, kojom u stvari i jest. Zahvaljuju\u0107i njemu, u VMware-u mo\u017eete raditi application-consistent backup-e, a u Hyper-V-u gotovo sve. Planiram napisati poseban \u010dlanak s nekim sa\u017eetkom o VSS-u, ali za sada mo\u017eete poku\u0161ati pro\u010ditati ovaj opis<\/u><\/a><\/noindex>. Samo budite oprezni, jer poku\u0161aj razumijevanja VSS-a s povr\u0161nog pregleda mo\u017ee dovesti do povreda mozga.<\/p>\n
Na tome, valjda, mo\u017eemo stati. Smatram da je zadatak obja\u0161njenja osnovnih stvari ispunjen, pa \u0107emo u sljede\u0107em poglavlju ve\u0107 gledati logove. Ako imate pitanja, slobodno ih postavite u komentarima.<\/p>\n<\/p>\n
Izvor: 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\udd47Odakle dolaze logovi? Veeam Log Diving | ProHoster","description":"Nastavljamo na\u0161e uranjanje u uzbudljivi svijet...","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}