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

\"Hvor<\/p>\n

Vi forts\u00e6tter vores dyk ind i den fascinerende verden af fejlfindingslogs. I i den foreg\u00e5ende artikel<\/a><\/noindex> har vi aftalt betydningen af de grundl\u00e6ggende termer og taget et kig p\u00e5 den overordnede struktur af Veeam som en samlet applikation. Opgaven denne gang er at finde ud af, hvordan logfilerne dannes, hvilken information der vises i dem, og hvorfor de ser ud, som de g\u00f8r.<\/p>\n

Hvad t\u00e6nker I egentlig, hvad er disse 'logs'? If\u00f8lge de fleste b\u00f8r loggen for enhver applikation have rollen som en alm\u00e6gtig enhed, som det meste af tiden ligger gemt et sted i baggrunden, men som i det afg\u00f8rende \u00f8jeblik dukker op fra ingenting i skinnende rustning og redder alle. Det vil sige, at der i dem skal v\u00e6re alt fra de mindste fejl i hver komponent til enkelte database-transaktioner. Og efter en fejl skal der straks skrives ned, hvordan den kan rettes. Og alt dette skal kunne v\u00e6re p\u00e5 et par megabytes, maks. Det er jo bare tekst! Tekstfiler kan ikke fylde titusinde gigabytes, det har jeg h\u00f8rt et sted!<\/p>\n

S\u00e5, logs<\/h2>\n

I den virkelige verden er logs blot arkiver af diagnostisk information. Og hvad der skal opbevares, hvor informationen skal hentes fra, og hvor detaljeret den skal v\u00e6re, bestemmer udviklerne selv. Nogle g\u00e5r minimalistisk til v\u00e6rks og gemmer kun V\u00c6GT\/AF-v\u00e6rdier, mens andre flittigt samler alt, hvad de kan n\u00e5. Der er ogs\u00e5 en mellemvej med muligheden for at v\u00e6lge s\u00e5kaldt Logging Level, hvor du selv angiver, hvor detaljeret information du \u00f8nsker at gemme, og hvor meget un\u00f8dvendig plads du har p\u00e5 dine diske =) VBR har i alt seks af disse niveauer, for at sige det s\u00e5dan. Og tro mig, du vil ikke se, hvad der sker ved maksimal detaljeringsgrad med ledig plads p\u00e5 din disk.<\/p>\n

Godt. Vi har nogenlunde forst\u00e5et, hvad vi vil gemme, men det rejser et legitimt sp\u00f8rgsm\u00e5l: hvor f\u00e5r vi disse informationer fra? En del af h\u00e6ndelserne til logning genereres selvf\u00f8lgelig af os selv gennem vores interne processer. Men hvad g\u00f8r vi, n\u00e5r der er interaktion med en ekstern tilstand? For ikke at glide ind i et helvede af n\u00f8dudgange og kreative l\u00f8sninger, har Veeam tendens til ikke at genopfinde hjulene. Altid, n\u00e5r der allerede findes et f\u00e6rdigt API, en indbygget funktionsmulighed i systemet, et bibliotek osv., vil vi prioritere disse f\u00e6rdige l\u00f8sninger, f\u00f8r vi begynder at bygge vores snedige l\u00f8sninger. Selvom der ogs\u00e5 er mange af sidstn\u00e6vnte. Derfor er det vigtigt at forst\u00e5, at st\u00f8rstedelen af fejlene stammer fra meddelelser fra tredjeparts API'er, systemopkald og andre biblioteker. I dette tilf\u00e6lde handler VBRs rolle om at videresende disse fejl til logfilerne som de er. Og den prim\u00e6re opgave for brugeren er at l\u00e6re at forst\u00e5, hvilken linje der kommer fra hvem, og hvad denne<\/p>\n

Som vi tidligere aftalte: Veeam er en s\u00e5kaldt SQL-baseret applikation. Det betyder, at alle indstillinger, al information og faktisk alt, hvad der er n\u00f8dvendigt for normal funktion, gemmes i dens database. Derfor er der en simpel sandhed: Det, der ikke findes i loggene, findes sandsynligvis i databasen. Men det er heller ikke en s\u00f8lvkugle: Nogle oplysninger findes hverken i de lokale logs fra Veeam-komponenterne eller i databasen. Derfor skal man l\u00e6re at studere logs fra v\u00e6rten, logs fra den lokale maskine og logs fra alt, hvad der deltager i backup- og restaureringsprocessen. Og det kan ske, at de n\u00f8dvendige oplysninger ikke findes nogen steder. S\u00e5dan er det. <\/p>\n

Nogle eksempler p\u00e5 s\u00e5danne API'er<\/h4>\n

Denne liste har ikke til form\u00e5l at v\u00e6re udt\u00f8mmende, s\u00e5 der er ingen grund til at lede efter den endelige sandhed her. Dens opgave er blot at vise de mest almindelige tredjeparts API'er og teknologier, der anvendes i vores produkter.<\/p>\n

Lad os starte med VMware<\/strong>. <\/p>\n

F\u00f8rst p\u00e5 listen er vSphere API<\/strong>. Den anvendes til autentificering, l\u00e6sning af hierarkiet, oprettelse og sletning af snapshots, foresp\u00f8rgsel om information om maskiner og meget (meget) andet. Funktionaliteten er meget bred, s\u00e5 jeg kan varmt anbefale VMware vSphere API Reference for version 5.5<\/u><\/a><\/noindex> og 6.0<\/u><\/a><\/noindex>. For mere aktuelle versioner er det bare at s\u00f8ge p\u00e5 Google.<\/p>\n

VIX API<\/strong>. Den sorte magi ved hypervisoren, som har en s\u00e6rskilt fejlliste<\/u><\/a><\/noindex>. VMware API til at arbejde med filer p\u00e5 v\u00e6rten uden at v\u00e6re tilsluttet dem over netv\u00e6rket. En sidste udvej, n\u00e5r man skal l\u00e6gge en fil p\u00e5 en maskine, som man ikke har bedre forbindelser til. Det kan v\u00e6re en smerte, hvis filen er stor, og v\u00e6rten er belastet. Men her g\u00e6lder reglen, at selv 56,6 Kb\/s er bedre end 0 Kb\/s. I Hyper-V kaldes en lignende funktion PowerShell Direct. Men det var kun indtil<\/p>\n

vSpehere Web Services API<\/strong> Fra og med vSphere 6.0 ( cirka, da dette API f\u00f8rst blev pr\u00e6senteret i version 5.5) anvendes det til at arbejde med g\u00e6stemaskiner og har n\u00e6sten helt erstattet VIX. I bund og grund er det endnu et API til at styre vSphere. Dem, der er interesserede, kan jeg anbefale at studere den fremragende<\/u><\/a><\/noindex> manual. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Et bibliotek, som delvist blev n\u00e6vnt i denne artikel<\/u><\/a><\/noindex>. Den bruges til at l\u00e6se virtuelle diske. Engang var den en del af VIX, men med tiden blev den adskilt som et selvst\u00e6ndigt produkt. Men som arvtager bruger den de samme fejlkoder som VIX. Men af en eller anden grund er der ingen beskrivelse af disse fejl i selve SDK'en. Derfor blev det gennem erfaring klart, at VDDK-fejl med andre koder blot er en overs\u00e6ttelse fra bin\u00e6rt til decimalt format. Den best\u00e5r af to dele - den f\u00f8rste halvdel er uofficiel information om konteksten, mens den anden del er de traditionelle VIX\/VDDK-fejl. For eksempel, hvis vi ser:<\/p>\n

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

S\u00e5 kan vi trygt konvertere det til hex og f\u00e5 132200000001. Den uinformerede begyndelse 132200 kasserer vi, og resten vil v\u00e6re vores fejlkode (VDDK 1: Ukendt fejl). For nylig blev der netop skrevet en separat artikel<\/u><\/a><\/noindex>.<\/p>\n

Nu lader os se p\u00e5 Windows<\/strong>. <\/p>\n

Her kan vi finde alt det, der er n\u00f8dvendigt og vigtigt for os i den standard Event Viewer<\/strong>. Men der er en fangst: efter gammel tradition logger Windows ikke en fuldst\u00e6ndig fejltekst, men kun nummeret. For eksempel, fejl 5 er 'Adgang n\u00e6gtet', og 1722 er 'RPC-serveren er utilg\u00e6ngelig', og 10060 er 'Forbindelse tidsafbrudt'. Selvf\u00f8lgelig er det godt, hvis du kan huske de mest kendte, men hvad med dem, du aldrig har set f\u00f8r? <\/p>\n

Og for at livet ikke skal virke for s\u00f8dt, gemmes fejl ogs\u00e5 i hexadecimal format med pr\u00e6fixet 0x8007. For eksempel er 0x8007000e \u2014 faktisk 14, Out of Memory. Hvorfor og for hvem det blev gjort \u2014 er en hemmelighed d\u00e6kket af m\u00f8rke. Du kan dog downloade den fulde liste over fejl gratis og uden SMS fra udviklercentret<\/u><\/a><\/noindex>.<\/p>\n

Forresten, nogle gange er der ogs\u00e5 andre pr\u00e6fikser end blot 0x8007. I s\u00e5dan en trist situation skal du dykke endnu dybere ned i dokumentationen<\/u><\/a><\/noindex> for udviklere. I det daglige liv vil jeg ikke anbefale dig at g\u00f8re det, men hvis du pludselig er presset mod v\u00e6ggen eller bare er nysgerrig, s\u00e5 ved du nu, hvad du skal g\u00f8re.<\/p>\n

Men folkene hos Microsoft viste noget medf\u00f8lelse over for os og pr\u00e6senterede en nyttig v\u00e6rkt\u00f8j ERR<\/u><\/a><\/noindex>. Dette er et lille stykke konsollykke, der kan overs\u00e6tte fejlkoder til menneskelig forst\u00e5else uden brug af Google. Den fungerer omtrent s\u00e5dan her.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# En intern fejl opstod.\n# som en HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# En intern fejl opstod.\n# 2 matches found for \"0x54f\"<\/code><\/pre>\n
Der opst\u00e5r det legitime sp\u00f8rgsm\u00e5l: hvorfor skriver vi ikke straks overs\u00e6ttelsen i loggene, men efterlader disse mystiske koder? Svaret ligger i tredjepartsapplikationer. N\u00e5r du selv kalder en WinAPI-funktion, er det ikke en udfordring at overs\u00e6tte dens svar, da der endda findes en s\u00e6rlig WinAPI-funktion til det. Men som tidligere n\u00e6vnt, havner alt, hvad vi f\u00e5r i svarene, i vores logs. Og her m\u00e5tte vi konstant overv\u00e5ge denne bevidsthedsstr\u00f8m, tr\u00e6kke de dele med Windows-fejl ud, overs\u00e6tte dem og inds\u00e6tte dem tilbage. Lad os v\u00e6re \u00e6rlige, det er ikke den mest underholdende aktivitet.<\/p>\n
Windows File Management API <\/strong>bliver flittigt brugt til at arbejde med filer. Oprettelse af filer, sletning, \u00e5bning til skrivning, arbejde med attributter og meget mere.<\/p>\n
Den n\u00e6vnte ovenfor PowerShell Direct<\/strong> som en analog til VIX API i Hyper-V verdenen. Desv\u00e6rre ikke s\u00e5 fleksibel: mange funktionalitetsbegr\u00e6nsninger, fungerer ikke med hver v\u00e6rtversion og heller ikke med alle g\u00e6ster.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Jeg mener, at der ikke er nogen, der har arbejdet med Windows, som ikke har set fejl relateret til RPC. P\u00e5 trods af den udbredte misforst\u00e5else er dette ikke en enkelt protokol, men enhver klient-server protokol, der opfylder en r\u00e6kke krav. Men hvis vi har en RPC-fejl i vores logs, er det i 90% af tilf\u00e6ldene en fejl fra Microsoft RPC, som er en del af DCOM (Distributed Component Object Model). Der findes et stort antal dokumentation om emnet p\u00e5 nettet, men meget af det er ret for\u00e6ldet. Men hvis du har en st\u00e6rk trang til at studere emnet, kan jeg anbefale artiklerne Hvad er RPC?<\/u><\/a><\/noindex>, Hvordan RPC fungerer<\/u> <\/a><\/noindex>og en lang liste af RPC-fejl<\/u><\/a><\/noindex>.<\/p>\n
De prim\u00e6re \u00e5rsager til RPC-fejl i vores logs \u2014 er mislykkedes fors\u00f8g p\u00e5 kommunikation mellem VBR-komponenter (server > proxy, for eksempel) og oftest p\u00e5 grund af kommunikationsproblemer.<\/p>\n
Den mest toppe af alle toppe \u2014 er fejlen The RPC server is unavailable (1722). Kort sagt, klienten kunne ikke oprette forbindelse til serveren. Hvordan og hvorfor \u2014 der er ikke et entydigt svar, men det er normalt et problem med autentificering eller netv\u00e6rksadgang til port 135. Det sidste er typisk for infrastrukturer med dynamisk tildeling af porte. Der er endda noget separat KB<\/u><\/a><\/noindex>. Hos Microsoft \u2014 omfattende guide<\/u><\/a><\/noindex> til fejlfinding af problemer.<\/p>\n
Den n\u00e6st mest almindelige fejl: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller serveren kunne ikke tildele en port til sig selv. Dette opst\u00e5r typisk, n\u00e5r serveren (i vores tilf\u00e6lde den virtuelle maskine) er konfigureret til dynamisk portallokering fra et sn\u00e6vert interval, som er opbrugt. Hvis vi ser p\u00e5 det fra klientens side (i vores tilf\u00e6lde VBR-serveren), betyder det, at vores VeeamVssAgent ikke er startet, eller ikke er blevet registreret som RPC-interface. Der er ogs\u00e5 artikler om dette. separat KB<\/u><\/a><\/noindex>.<\/p>\n
Og for at afslutte Top-3 RPC-fejlene, lad os n\u00e6vne RPC function call failed (1726). Denne fejl opst\u00e5r, hvis forbindelsen er etableret, men RPC-anmodningerne ikke g\u00e5r igennem. For eksempel, hvis vi anmoder om information om VSS-status (hvis der lige nu tages en skyggekopi, og vi fors\u00f8ger at f\u00e5 adgang til det), men vi f\u00e5r stilhed og bliver ignoreret.<\/p>\n
Windows Tape Backup API <\/strong>er n\u00f8dvendigt for arbejde med b\u00e5ndbiblioteker eller drev. Som jeg n\u00e6vnte i starten: det er ikke s\u00e6rlig sjovt at skrive sine egne drivere og s\u00e5 k\u00e6mpe med at st\u00f8tte hver enhed. Derfor har Veeam ikke sine egne drivere. Alt g\u00e5r gennem en standard API, som hardwareleverand\u00f8rerne selv implementerer. Det giver meget mere mening, ikke?<\/p>\n
SMB\/CIFS<\/strong> Alle skriver dem ved siden af hinanden af vane, selvom ikke alle husker, at CIFS (Common Internet File System) \u2014 blot er en privat version af SMB (Server Message Block). S\u00e5 der er ikke noget d\u00e5rligt i at generalisere disse begreber. Samba \u2014 er allerede en Linux\/Unix implementering, og der er sine egne forskelle, men det er en anden historie. Det, der er vigtigt her: n\u00e5r Veeam beder om at skrive noget til en UNC-sti (serverdirectory), bruger serveren hierarkiet af filsystemdrivere, herunder mup og mrxsmb, til at skrive til drevet. Som f\u00f8lge heraf vil disse drivere ogs\u00e5 generere fejl.<\/p>\n
Man kan p\u00e5 ingen m\u00e5de undv\u00e6re Winsock API<\/strong>. Hvis der skal g\u00f8res noget over netv\u00e6rket, virker VBR gennem Windows Socket API, kendt som Winsock. S\u00e5 hvis vi ser IP:Port linket i loggen, er det d\u00e9t. I den officielle dokumentation er der en god liste over mulige af fejl<\/u><\/a><\/noindex>.<\/p>\n
Den n\u00e6vnte ovenfor WMI<\/strong> (Windows Management Instrumentation) \u2014 det er et alm\u00e6gtigt API til at styre alt og alle i Windows-verdenen. For eksempel, n\u00e5r man arbejder med Hyper-V, sker n\u00e6sten alle foresp\u00f8rgsler til v\u00e6rten netop gennem det. Med andre ord, det er en uundg\u00e5elig og meget kraftfuld l\u00f8sning. I fors\u00f8g p\u00e5 at finde ud af, hvor og hvad der er g\u00e5et galt, er det indbyggede v\u00e6rkt\u00f8j WBEMtest.exe meget hj\u00e6lpsomt.<\/p>\n
Og den sidste p\u00e5 listen, men bestemt ikke mindre vigtig \u2014 VSS<\/strong> (Volume Shadow Storage). Emnet er s\u00e5 ubegribelig og mystisk, som der er skrevet meget dokumentation om. Shadow Copy kan bedst forst\u00e5s som en s\u00e6rlig type snapshot, som den i bund og grund er. Takket v\u00e6re det kan man i VMware lave applikationskonsistente backups, og i Hyper-V kan man faktisk g\u00f8re n\u00e6sten alt. Jeg har planer om at lave en separat artikel med en slags resum\u00e9 om VSS, men indtil videre kan du pr\u00f8ve at l\u00e6se denne beskrivelse<\/u><\/a><\/noindex>. Bare v\u00e6r forsigtig, da et fors\u00f8g p\u00e5 at forst\u00e5 VSS hurtigt kan f\u00f8re til hjernerystelser.<\/p>\n
P\u00e5 dette punkt kan vi vel stoppe. Jeg anser opgaven med at forklare de mest grundl\u00e6ggende ting for fuldf\u00f8rt, s\u00e5 i det n\u00e6ste kapitel ser vi p\u00e5 loggene. Men hvis der er sp\u00f8rgsm\u00e5l, s\u00e5 t\u00f8v ikke med at stille dem i kommentarerne.<\/p>\n<\/p>\n
Kilde: 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\udd47Hvor kommer loggene fra? Veeam Log Diving | ProHoster","description":"Vi forts\u00e6tter vores dyk ned i den fascinerende verden af sp\u00e5dom...","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}