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

\"De<\/p>\n

Continu\u0103m imersiunea noastr\u0103 \u00een fascinanta lume a troubleshooting-ului prin loguri. \u00cen articolul anterior<\/a><\/noindex> ne-am \u00een\u021beles semnifica\u021bia termenilor de baz\u0103 \u0219i am aruncat o privire asupra structurii generale a Veeam ca aplica\u021bie unic\u0103. Sarcina pentru aceasta este s\u0103 \u00een\u021belegem cum sunt formate fi\u0219ierele log, ce informa\u021bii con\u021bin \u0219i de ce arat\u0103 a\u0219a cum arat\u0103.<\/p>\n

Ce crede\u021bi, ce sunt aceste \u201eloguri\u201d? Potrivit majorit\u0103\u021bii, logurile oric\u0103rei aplica\u021bii ar trebui s\u0103 joace rolul unei entit\u0103\u021bi omnipotente, care petrece cea mai mare parte a timpului \u00eentr-un col\u021b uitat, dar care, \u00een momentul potrivit, apare din neant \u00een armuri str\u0103lucitoare \u0219i salveaz\u0103 pe toat\u0103 lumea. Adic\u0103, acestea ar trebui s\u0103 con\u021bin\u0103 totul, de la cele mai mici erori \u00een fiecare component\u0103 p\u00e2n\u0103 la tranzac\u021bii individuale ale bazei de date. \u0218i, dup\u0103 fiecare eroare, ar trebui s\u0103 fie scris cum s\u0103 o corect\u0103m. \u0218i totul acesta ar trebui s\u0103 \u00eencap\u0103 \u00een c\u00e2\u021biva megabytes, nu mai mult. Este doar text! Nu pot fi fi\u0219ierele text de zeci de gigabytes, am auzit undeva asta!<\/p>\n

A\u0219adar, jurnalele<\/h2>\n

\u00cen lumea real\u0103, jurnalele sunt doar arhive de informa\u021bii diagnostice. \u0218i ce ar trebui s\u0103 con\u021bin\u0103, de unde ar trebui s\u0103 provin\u0103 informa\u021biile pentru stocare \u0219i c\u00e2t de detaliate ar trebui s\u0103 fie, depinde de dezvoltatori. Unii opteaz\u0103 pentru minimalism, p\u0103str\u00e2nd \u00eenregistr\u0103ri de tip ON\/OFF, iar al\u021bii \u00eencearc\u0103 s\u0103 str\u00e2ng\u0103 tot ce pot atinge. De\u0219i exist\u0103 \u0219i o variant\u0103 intermediar\u0103, denumit\u0103 Logging Level, \u00een care \u00ee\u021bi po\u021bi specifica c\u00e2t de detaliat\u0103 vrei s\u0103 fie informa\u021bia p\u0103strat\u0103 \u0219i c\u00e2t de mult spa\u021biu suplimentar ai pe discuri =) La VBR, sunt \u0219ase astfel de niveluri, de altfel. \u0218i, crede\u021bi-m\u0103, nu dori\u021bi s\u0103 vede\u021bi ce se \u00eent\u00e2mpl\u0103 atunci c\u00e2nd ave\u021bi un jurnal detaliat, cu prea mult spa\u021biu liber pe disc.<\/p>\n

Bine. Am \u00een\u021beles aproximativ ce dorim s\u0103 p\u0103str\u0103m, dar apare o \u00eentrebare legitim\u0103: de unde lu\u0103m aceste informa\u021bii? O parte din evenimentele pentru logare, desigur, le gener\u0103m noi prin procesele noastre interne. Dar ce facem c\u00e2nd exist\u0103 interac\u021biuni cu mediul extern? Pentru a nu ajunge \u00eentr-un iad total de solu\u021bii improvizate, Veeam are tendin\u021ba s\u0103 nu reinventeze roata. \u00centotdeauna, c\u00e2nd exist\u0103 deja un API disponibil, o func\u021bie integrat\u0103 \u00een sistem, o bibliotec\u0103 etc., vom da prioritate variantelor deja existente, \u00eenainte de a \u00eencepe s\u0103 construim propriile solu\u021bii ingenioase. Cu toate acestea, sunt suficiente asemenea solu\u021bii. A\u0219adar, \u00een analiza logurilor este important s\u0103 \u00een\u021belegem c\u0103 o mare parte a erorilor provine din mesajele de la API-uri externe, apeluri sistemice \u0219i alte biblioteci. \u00cen acest caz, rolul VBR este de a trimite aceste erori \u00een fi\u0219ierele log a\u0219a cum sunt. Iar sarcina principal\u0103 a utilizatorului este s\u0103 \u00eenve\u021be s\u0103 \u00een\u021beleag\u0103 care linie provine de la cine \u0219i ce \u201ecine\u201d este responsabil pentru aceasta. A\u0219adar, dac\u0103 codul de eroare din logul VBR v\u0103 duce la pagina MSDN, este normal \u0219i corect.<\/p>\n

A\u0219a cum am convenit anterior: Veeam este o aplica\u021bie bazat\u0103 pe SQL. Asta \u00eenseamn\u0103 c\u0103 toate set\u0103rile, informa\u021biile \u0219i, \u00een general, tot ce este necesar pentru func\u021bionarea normal\u0103 sunt stocate \u00een baza sa de date. Din acest motiv, adev\u0103rul simplu este: ceea ce nu este \u00een jurnale, cel mai probabil se afl\u0103 \u00een baza de date. Dar aceasta nu este o solu\u021bie universal\u0103: unele lucruri nu se reg\u0103sesc nici \u00een jurnalele locale ale componentelor Veeam, nici \u00een baza sa de date. Prin urmare, trebuie s\u0103 \u00eenv\u0103\u021b\u0103m s\u0103 studiem jurnalele host-ului, jurnalele ma\u0219inii locale \u0219i jurnalele tuturor elementelor implicate \u00een procesul de backup \u0219i restaurare. \u0218i uneori, informa\u021bia necesar\u0103 nu este disponibil\u0103 nic\u0103ieri. Asta este realitatea. <\/p>\n

C\u00e2teva exemple de astfel de API-uri<\/h4>\n

Aceast\u0103 list\u0103 nu are ca scop s\u0103 fie exhaustiv\u0103, a\u0219a c\u0103 nu trebuie s\u0103 c\u0103uta\u021bi adev\u0103rul absolut \u00een ea. Sarcina sa este doar s\u0103 arate cele mai frecvente API-uri externe \u0219i tehnologii utilizate \u00een produsele noastre.<\/p>\n

S\u0103 \u00eencepem cu VMware<\/strong>. <\/p>\n

Primul \u00een list\u0103 va fi vSphere API<\/strong>. Este folosit pentru autentificare, citirea ierarhiilor, crearea \u0219i \u0219tergerea snapshot-urilor, solicitarea de informa\u021bii despre ma\u0219ini \u0219i multe (foarte multe) alte lucruri. Func\u021bionalitatea solu\u021biei este foarte extins\u0103, a\u0219a c\u0103 tuturor celor interesa\u021bi le recomand  VMware vSphere API Reference pentru versiunea 5.5<\/u><\/a><\/noindex> \u0219i 6.0<\/u><\/a><\/noindex>. Pentru versiuni mai actuale, totul se poate g\u0103si u\u0219or pe Google.<\/p>\n

VIX API<\/strong>. Magia neagr\u0103 a hipervizorului, pentru care exist\u0103 o list\u0103 separat\u0103 de eroare<\/u><\/a><\/noindex>. VMware API pentru lucrul cu fi\u0219iere pe gazd\u0103 f\u0103r\u0103 a se conecta la acestea prin re\u021bea. O op\u021biune de ultim\u0103 instan\u021b\u0103, atunci c\u00e2nd trebuie s\u0103 transferi un fi\u0219ier \u00eentr-o ma\u0219in\u0103 pentru care nu exist\u0103 un canal de comunicare mai bun. Reprezint\u0103 o durere \u0219i suferin\u021b\u0103 dac\u0103 fi\u0219ierul este mare, iar gazda este \u00eenc\u0103rcat\u0103. Dar aici func\u021bioneaz\u0103 regula c\u0103 chiar \u0219i 56,6 Kb\/s este mai bine dec\u00e2t 0 Kb\/s. \u00cen Hyper-V, un lucru similar se nume\u0219te PowerShell Direct. Dar a\u0219a a fost doar p\u00e2n\u0103 la apari\u021bia<\/p>\n

vSphere Web Services API<\/strong> . \u00cencep\u00e2nd cu vSphere 6.0 (aproximativ, deoarece acest API a fost prezentat pentru prima dat\u0103 \u00een versiunea 5.5) este utilizat pentru a lucra cu ma\u0219inile virtuale \u0219i deja aproape peste tot a \u00eenlocuit VIX. Practic, este un alt API pentru gestionarea vSphere. Cei interesa\u021bi pot s\u0103 consulte un<\/u><\/a><\/noindex> ghid excelent. <\/p>\n

VDDK<\/strong> (. Virtual Disk Development Kit). O bibliotec\u0103 despre care s-a vorbit par\u021bial \u00een aceast\u0103 pe care l-a\u021bi citit<\/u><\/a><\/noindex>. Este utilizat pentru citirea discurilor virtuale. Cu mult timp \u00een urm\u0103, a f\u0103cut parte din VIX, dar \u00een timp a fost scos ca produs separat. \u00cens\u0103, din motive necunoscute, folose\u0219te acelea\u0219i coduri de eroare ca \u0219i VIX.  \u00cens\u0103, dintr-un anumit motiv, \u00een SDK-ul s\u0103u nu exist\u0103 nicio descriere a acestor erori. Din experien\u021b\u0103, s-a constatat c\u0103 erorile VDDK cu alte coduri sunt doar o traducere din binar \u00een cod zecimal. Se compune din dou\u0103 p\u0103r\u021bi \u2013 prima parte con\u021bine informa\u021bii nedocumentate despre context, iar a doua parte sunt erorile tradi\u021bionale VIX\/VDDK. De exemplu, dac\u0103 vedem:<\/p>\n

Eroare VDDK: 21036749815809.Eroare necunoscut\u0103<\/code><\/p>\n

Atunci convertim f\u0103r\u0103 ezitare \u00een hex \u0219i ob\u021binem 132200000001. Dac\u0103 132200, \u00eenceputul neinformat, este ignorat, restul va fi codul nostru de eroare (VDDK 1: Eroare necunoscut\u0103). Recent, a fost realizat un articol separat despre cele mai frecvente erori VDDK. articol<\/u><\/a><\/noindex>.<\/p>\n

Acum s\u0103 ne uit\u0103m la WIndows<\/strong>. <\/p>\n

Aici tot ce este necesar \u0219i important pentru noi poate fi g\u0103sit \u00een standardul Event Viewer<\/strong>. Dar exist\u0103 o problem\u0103: conform unei tradi\u021bii vechi, Windows nu \u00eenregistreaz\u0103 textul complet al erorii, ci doar num\u0103rul s\u0103u. De exemplu, eroarea 5 este \u201eAcces refuzat\u201d, iar 1722 este \u201eServerul RPC nu este disponibil\u201d, iar 10060 este \u201eTimp de conexiune dep\u0103\u0219it\u201d. Cu siguran\u021b\u0103, este grozav dac\u0103 \u00ee\u021bi aminte\u0219ti cele mai cunoscute, \u00eens\u0103 ce s\u0103 faci cu cele necunoscute p\u00e2n\u0103 acum? <\/p>\n

\u0218i pentru ca via\u021ba s\u0103 nu par\u0103 prea dulce, erorile sunt stocate \u0219i \u00een format hexazecimal, cu prefixul 0x8007. De exemplu, 0x8007000e \u2014 aceasta este, de fapt, 14, Out of Memory. De ce \u0219i pentru cine a fost f\u0103cut astfel \u2014 este un mister acoperit \u00een \u00eentuneric. Totu\u0219i, lista complet\u0103 a erorilor poate fi desc\u0103rcat\u0103 gratuit \u0219i f\u0103r\u0103 SMS de pe centru de dezvoltare<\/u><\/a><\/noindex>.<\/p>\n

Apropo, uneori \u00eent\u00e2lnim \u0219i alte prefixe, nu doar 0x8007. \u00centr-o asemenea situa\u021bie nefericit\u0103, pentru a \u00een\u021belege HRESULT (\u201ehandle de rezultat\u201d) trebuie s\u0103 ne ad\u00e2ncim \u0219i mai mult \u00een documenta\u021bie<\/u><\/a><\/noindex> pentru dezvoltatori. \u00cen via\u021ba de zi cu zi, nu v\u0103 recomand a\u0219a ceva, dar dac\u0103 sunte\u021bi cople\u0219i\u021bi de circumstan\u021be sau pur \u0219i simplu sunte\u021bi curio\u0219i, acum \u0219ti\u021bi ce s\u0103 face\u021bi.<\/p>\n

Dar cei de la Microsoft au fost pu\u021bin mai \u00eeng\u0103duitori cu noi \u0219i au dat lumii utilitarul ERR<\/u><\/a><\/noindex>. Este un mic fragment de fericire \u00een consol\u0103 care poate traduce codurile de eroare \u00een termeni umani f\u0103r\u0103 a utiliza Google. Func\u021bioneaz\u0103 cam a\u0219a.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# pentru hexazecimal 0x54f \/ zecimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# A ap\u0103rut o eroare intern\u0103.\n# ca un HRESULT: Severitate: SUCCES (0), FACILITATE_NULL (0x0), Cod 0x54f\n# pentru hexazecimal 0x54f \/ zecimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# A ap\u0103rut o eroare intern\u0103.\n# 2 potriviri g\u0103site pentru \"0x54f\"<\/code><\/pre>\n
Se pune o \u00eentrebare legitim\u0103: de ce nu scriem imediat o interpretare \u00een jurnale, l\u0103s\u00e2nd aceste coduri misterioase? R\u0103spunsul se reg\u0103se\u0219te \u00een aplica\u021biile externe. C\u00e2nd faci tu \u00eensu\u021bi un apel WinAPI, interpretarea r\u0103spunsului nu este deloc dificil\u0103, deoarece exist\u0103 chiar un apel special WinAPI pentru asta. Dar, a\u0219a cum s-a spus, \u00een jurnalele noastre ajunge tot ce primim \u00een r\u0103spunsuri. \u0218i aici ar trebui s\u0103 monitoriz\u0103m constant acest flux de con\u0219tiin\u021b\u0103, s\u0103 extragem buc\u0103\u021bi de erori Windows, s\u0103 le interpret\u0103m \u0219i s\u0103 le inser\u0103m \u00eenapoi. S\u0103 fim sinceri, nu este cea mai captivant\u0103 activitate.<\/p>\n
Windows File Management API <\/strong>este folosit \u00een diverse moduri \u00een gestionarea fi\u0219ierelor. Crearea fi\u0219ierelor, \u0219tergerea, deschiderea pentru scriere, lucrul cu atributele \u0219i altele, \u0219i altele.<\/p>\n
Men\u021bionat anterior PowerShell Direct<\/strong> ca un echivalent al VIX API \u00een lumea Hyper-V. Din p\u0103cate, nu este at\u00e2t de flexibil: exist\u0103 multe restric\u021bii func\u021bionale, nu func\u021bioneaz\u0103 cu fiecare versiune de gazd\u0103 \u0219i cu foarte multe dintre gazdele virtuale.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Cred c\u0103 nu exist\u0103 o persoan\u0103 care a lucrat cu Windows \u0219i care s\u0103 nu fi v\u0103zut erori legate de RPC. \u00cen ciuda concep\u021biei populare gre\u0219ite, acesta nu este un protocol unic, ci orice protocol client-server care \u00eendepline\u0219te un set de parametri. Totu\u0219i, dac\u0103 \u00een logurile noastre exist\u0103 o eroare RPC, \u00een 90% din cazuri, aceasta va fi o eroare de la Microsoft RPC, care face parte din DCOM (Distributed Component Object Model).  \u00cen re\u021bea exist\u0103 o cantitate uria\u0219\u0103 de documenta\u021bie pe aceast\u0103 tem\u0103, totu\u0219i cea mai mare parte este destul de \u00eenvechit\u0103. Dar, dac\u0103 exist\u0103 o dorin\u021b\u0103 arz\u0103toare de a studia subiectul, pot recomanda articole Ce este RPC?<\/u><\/a><\/noindex>, Cum Func\u021bioneaz\u0103 RPC<\/u> <\/a><\/noindex>\u0219i o list\u0103 lung\u0103 de erori RPC<\/u><\/a><\/noindex>.<\/p>\n
Principalele cauze ale apari\u021biei erorilor RPC \u00een logurile noastre sunt \u00eencerc\u0103rile e\u0219uate de interac\u021biune \u00eentre componentele VBR (server > proxy, de exemplu) \u0219i, cel mai adesea, din cauza problemelor de conexiune.<\/p>\n
Celebrele erori sunt cele despre care se spune c\u0103 RPC server is unavailable (1722). Pe scurt, clientul nu a reu\u0219it s\u0103 stabileasc\u0103 o conexiune cu serverul. Cum \u0219i de ce \u2014 nu exist\u0103 un r\u0103spuns unic, dar, de obicei, aceasta este o problem\u0103 de autentificare sau de accesul re\u021belei la portul 135. Ultimul este caracteristic infrastructurilor cu atribuire dinamic\u0103 a porturilor. Exist\u0103 chiar \u0219i o KB separat\u0103<\/u><\/a><\/noindex>. \u0218i la Microsoft \u2014 un ghid cuprinz\u0103tor<\/u><\/a><\/noindex> pentru identificarea cauzelor defect\u0103rii.<\/p>\n
A doua eroare ca popularitate: There are no more endpoints available from the endpoint mapper (1753). Clientul sau serverul RPC nu au reu\u0219it s\u0103-\u0219i aloce un port. Apare de obicei atunci c\u00e2nd serverul (\u00een cazul nostru, ma\u0219ina gazd\u0103) a fost configurat pentru alocarea dinamic\u0103 a porturilor dintr-un interval restr\u00e2ns, care s-a epuizat. \u0218i dac\u0103 privim din perspectiva clientului (\u00een cazul nostru, serverul VBR), \u00eenseamn\u0103 c\u0103 VeeamVssAgent-ul nostru fie nu s-a pornit, fie nu a fost \u00eenregistrat ca interfa\u021b\u0103 RPC. Pe acest subiect de asemenea exist\u0103 o KB separat\u0103<\/u><\/a><\/noindex>.<\/p>\n
\u0218i pentru a finaliza topul celor 3 erori RPC, s\u0103 ne amintim de eroarea RPC function call failed (1726). Aceasta apare dac\u0103 conexiunea a fost stabilit\u0103, dar cererile RPC nu sunt procesate. De exemplu, solicit\u0103m informa\u021bii despre starea VSS (poate tocmai se face o copie shadow \u0219i noi \u00eencerc\u0103m s\u0103 intervenim), iar r\u0103spunsul nostru este t\u0103cere \u0219i ignorare.<\/p>\n
API de backup pe band\u0103 Windows <\/strong>este necesar pentru a lucra cu biblioteci sau unit\u0103\u021bi cu band\u0103. A\u0219a cum am men\u021bionat la \u00eenceput: s\u0103 scriem proprii drivere \u0219i s\u0103 ne chinuim apoi cu suportul fiec\u0103rui dispozitiv nu ne aduce nicio satisfac\u021bie. Prin urmare, Veeam nu are drivere proprii. Totul se face prin API-ul standard, al c\u0103rui suport este implementat de furnizorii de hardware. A\u0219a c\u0103 este mult mai logic, nu-i a\u0219a?<\/p>\n
SMB\/CIFS<\/strong> Toat\u0103 lumea le scrie din obicei al\u0103turi, de\u0219i nu toat\u0103 lumea \u00ee\u0219i aminte\u0219te c\u0103 CIFS (Common Internet File System) este doar o variant\u0103 privat\u0103 a SMB (Server Message Block). A\u0219a c\u0103 nu este nimic r\u0103u \u00een a generaliza aceste concepte. Dar Samba \u2014 aceasta este o implementare LinuxUnix, \u0219i are propriile sale particularit\u0103\u021bi, dar m-am ab\u0103tut de la subiect. Ceea ce este important aici: atunci c\u00e2nd Veeam solicit\u0103 s\u0103 scrie ceva pe un drum UNC (serverdirectory), serverul folose\u0219te ierarhia driverelor sistemului de fi\u0219iere, inclusiv mup \u0219i mrxsmb, pentru a scrie pe share. \u00cen consecin\u021b\u0103, aceste drivere vor genera \u0219i erorile.<\/p>\n
Nu se poate s\u0103 scapi f\u0103r\u0103 Winsock API<\/strong>. Dac\u0103 exist\u0103 ceva de f\u0103cut prin re\u021bea, VBR func\u021bioneaz\u0103 prin Windows Socket API, cunoscut pe scar\u0103 larg\u0103 sub numele de Winsock. A\u0219adar, dac\u0103 vedem \u00een jurnal o leg\u0103tur\u0103 IP:Port, acesta este. \u00cen documenta\u021bia oficial\u0103 exist\u0103 o list\u0103 destul de bun\u0103 a posibilelor erori<\/u><\/a><\/noindex>.<\/p>\n
Men\u021bionat anterior WMI<\/strong> (Windows Management Instrumentation) \u2014 este un API omnipotent pentru gestionarea tuturor aspectelor din lumea Windows. De exemplu, c\u00e2nd lucr\u0103m cu Hyper-V, aproape toate solicit\u0103rile c\u0103tre gazd\u0103 se fac prin intermediul acestuia. Pe scurt, este un instrument absolut indispensabil \u0219i extrem de puternic \u00een capacit\u0103\u021bile sale. \u00cen \u00eencerc\u0103rile de a ajuta la determinarea locului \u0219i cauzei unor probleme, instrumentul \u00eencorporat WBEMtest.exe este de mare ajutor.<\/p>\n
\u0218i ultimul pe list\u0103, dar cu siguran\u021b\u0103 nu cel de urm\u0103rit \u2014 VSS<\/strong> (Volume Shadow Storage). Subiectul este at\u00e2t de inepuizabil \u0219i misterios c\u00e2t de mult\u0103 documenta\u021bie s-a scris despre el. Shadow Copy este cel mai u\u0219or de \u00een\u021beles ca un tip special de snapshot, care de fapt acesta este. Datorit\u0103 lui, \u00een VMware putem face backup-uri aplica\u021bie-consistente, iar \u00een Hyper-V practic totul. Am planificat s\u0103 scriu un articol separat cu o sintez\u0103 despre VSS, dar p\u00e2n\u0103 atunci, pute\u021bi \u00eencerca s\u0103 citi\u021bi aceast\u0103 descriere<\/u><\/a><\/noindex>. Doar fi\u021bi aten\u021bi, deoarece \u00eencercarea de a \u00een\u021belege VSS pe fug\u0103 poate duce la dureri de cap.<\/p>\n
Pe acest subiect, cred c\u0103 ne putem opri. Consider c\u0103 am explicat cele mai fundamentale aspecte, a\u0219a c\u0103 \u00een urm\u0103torul capitol ne vom uita la loguri. Dar dac\u0103 mai ave\u021bi \u00eentreb\u0103ri, nu ezita\u021bi s\u0103 le adresa\u021bi \u00een comentarii.<\/p>\n<\/p>\n
Sursa: 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\udd47De unde provin jurnalele? Veeam Log Diving | ProHoster","description":"Continu\u0103m imersia noastr\u0103 \u00een lumea fascinant\u0103 a ghicirilor...","canonical_url":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"ro_RO","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\/ro\/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\/ro\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/ro\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}