{"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\/no\/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 fortsetter v\u00e5r dykking inn i den fascinerende verden av troubleshooting gjennom logger. den forrige artikkelen<\/a><\/noindex> Vi har blitt enige om betydningen av grunnleggende begreper og tatt en rask titt p\u00e5 den generelle strukturen av Veeam som en samlet applikasjon. M\u00e5let denne gangen er \u00e5 forst\u00e5 hvordan loggfiler dannes, hvilken informasjon de inneholder, og hvorfor de ser ut som de gj\u00f8r.<\/p>\n

Hva tror du egentlig disse \u00abloggene\u00bb er? If\u00f8lge de fleste b\u00f8r logger fra enhver applikasjon ha rollen som en allmektig enhet som for det meste ligger p\u00e5 sidelinjen, men som i et kritisk \u00f8yeblikk dukker opp ut av intet i str\u00e5lende rustning og redder dagen. Det vil si at de b\u00f8r inneholde alt fra de minste feilene i hver komponent til enkelttransaksjoner i databasen. Og etter en feil b\u00f8r det umiddelbart skrives ned hvordan man kan rette opp i det. Og alt dette m\u00e5 f\u00e5 plass i et par megabyte, ikke mer. Det er jo bare tekst! Kan ikke tekstfiler ta opp titalls gigabyte, jeg har h\u00f8rt det et sted!<\/p>\n

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

I den virkelige verden er logger kun et arkiv av diagnostisk informasjon. Og hva som skal lagres, hvor informasjonen skal hentes fra for lagring, og hvor detaljert den skal v\u00e6re, m\u00e5 besluttes av utviklerne selv. Noen f\u00f8lger minimalistisk tiln\u00e6rming, og lagrer bare p\u00e5- og av-poster, mens andre flittig samler alt de kan komme over. Det finnes ogs\u00e5 en melloml\u00f8sning der du kan velge s\u00e5kalt Logging Level, hvor du selv angir hvor detaljert informasjonen skal v\u00e6re, basert p\u00e5 hvor mye ledig plass du har p\u00e5 diskene =) VBR tilbyr faktisk hele seks niv\u00e5er av logger, bare s\u00e5 det er sagt. Og tro meg, du vil ikke se hva som skjer ved det mest detaljerte loggf\u00f8ringen med lite ledig plass p\u00e5 disken din.<\/p>\n

Greit. Vi har omtrent forst\u00e5tt hva vi \u00f8nsker \u00e5 bevare, men det oppst\u00e5r et legitimit sp\u00f8rsm\u00e5l: hvor henter vi denne informasjonen fra? En del hendelser for logging dannes selvsagt av v\u00e5re egne interne prosesser. Men hva gj\u00f8r vi n\u00e5r det skjer interaksjoner med omverdenen? For \u00e5 unng\u00e5 \u00e5 glide inn i et helvete av provisoriske l\u00f8sninger og egne sykkeldesign, har Veeam en tendens til \u00e5 ikke gjenoppfinne hjulet. N\u00e5r det allerede finnes et ferdig API, innebygd funksjonalitet i systemet, bibliotek osv., vil vi alltid prioritere de ferdige alternativene f\u00f8r vi begynner med v\u00e5re egne, kompliserte l\u00f8sninger. Selv om det ogs\u00e5 finnes mange av de siste. Derfor er det viktig \u00e5 forst\u00e5 ved analyse av logger at majoriteten av feilene gjelder meldinger fra tredjeparts APIer, systemanrop og andre biblioteker. I dette tilfellet er rollen til VBR \u00e5 videresende disse feilene til loggfiler som de er. Hovedoppgaven til brukeren er \u00e5 l\u00e6re seg \u00e5 forst\u00e5 hvilken linje som kommer fra hvem, og hva denne \u00abhvem\u00bb egentlig har ansvaret for. S\u00e5 hvis feil koden fra VBR-loggen f\u00f8rer deg til MSDN-siden, er det normalt og riktig.<\/p>\n

Som vi ble enige om tidligere: Veeam er en s\u00e5kalt SQL-basert applikasjon. Det betyr at alle innstillinger, all informasjon og generelt alt som er n\u00f8dvendig for normal drift \u2014 alt lagres i databasen. Derfor er det en enkel sannhet: det som ikke finnes i loggene, finnes sannsynligvis i databasen. Men dette er ikke en s\u00f8lvkule: det finnes ting som verken finnes i de lokale loggene til Veeam-komponentene eller i databasen. Derfor m\u00e5 man l\u00e6re \u00e5 studere vertens logger, loggene til den lokale maskinen og loggene til alt som deltar i backup- og gjenopprettingsprosessen. Og det skjer ogs\u00e5 at n\u00f8dvendig informasjon ikke finnes noe sted. Slik er veien. <\/p>\n

Noen eksempler p\u00e5 slike API-er<\/h4>\n

Denne listen har ikke som m\u00e5l \u00e5 v\u00e6re utelukkende komplett, s\u00e5 man skal ikke lete etter sannheten i den endelige instans. Dens oppgave er bare \u00e5 vise de mest vanlige eksterne API-ene og teknologiene som brukes i v\u00e5re produkter.<\/p>\n

La oss begynne med VMware.<\/strong>. <\/p>\n

F\u00f8rst p\u00e5 listen er vSphere API<\/strong>. Brukes for autentisering, lesing av hierarkier, oppretting og sletting av \u00f8yeblikksbilder, foresp\u00f8rsel om informasjon om maskiner og mye (veldig mye) annet. Funksjonaliteten til l\u00f8sningen er veldig bred, s\u00e5 jeg anbefaler alle interesserte \u00e5 se p\u00e5 VMware vSphere API Reference for versjonen 5.5<\/u><\/a><\/noindex> og 6.0<\/u><\/a><\/noindex>. For nyere versjoner finner du det enkelt med litt Googling.<\/p>\n

VIX API<\/strong>. Den svarte magien til hypervisoren, som har sin egen liste over feil<\/u><\/a><\/noindex>. VMware API for \u00e5 jobbe med filer p\u00e5 verten uten nettverkstilkobling. En siste utvei n\u00e5r man m\u00e5 legge en fil p\u00e5 en maskin som ikke har bedre forbindelser. Det blir smertefullt hvis filen er stor og verten er overbelastet. Men regelen gjelder her at 56,6 Kb\/s er bedre enn 0 Kb\/s. I Hyper-V kalles dette PowerShell Direct. Men dette var bare tilfelle f\u00f8r<\/p>\n

vSphere Web Services API<\/strong> . Fra vSphere 6.0 (omtrent, ettersom dette APIet f\u00f8rst ble introdusert i versjon 5.5) brukes det for \u00e5 jobbe med gjestemaskiner og har allerede nesten helt utskiftet VIX. I bunn og grunn er dette et annet API for \u00e5 administrere vSphere. Til de interesserte vil jeg anbefale \u00e5 studere denne utmerkede<\/u><\/a><\/noindex> manualen. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Et bibliotek som ble delvis omtalt i denne artikkelen<\/u><\/a><\/noindex>. Brukes for lesing av virtuelle disker. For lenge siden var den en del av VIX, men har med tiden blitt flyttet til et eget produkt. Den arver imidlertid de samme feilkodene som var i VIX. Men av en eller annen grunn er det ingen beskrivelser av disse feilene i selve SDK-en. Derfor ble det oppdaget gjennom erfaring at VDDK-feil med andre koder bare er en oversettelse fra bin\u00e6r til desimal kode. Best\u00e5r av to deler \u2014 den f\u00f8rste halvdelen presenterer udokumentert informasjon om konteksten, og den andre delen \u2014 tradisjonelle VIX\/VDDK-feil. For eksempel, hvis vi ser:<\/p>\n

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

S\u00e5 konverterer vi dette til hex og f\u00e5r 132200000001. Den uinformative begynnelsen 132200 ignorerer vi, og resten vil v\u00e6re v\u00e5r feilkode (VDDK 1: Ukjent feil). Nylig ble det laget et eget article<\/u><\/a><\/noindex>.<\/p>\n

N\u00e5 skal vi se p\u00e5 Windows<\/strong>. <\/p>\n

. Her kan vi finne alt vi trenger i den standard Event Viewer<\/strong>. Men det er en hake: etter en gammel tradisjon logger Windows ikke den fullstendige tekstfeilen, men bare nummeret. For eksempel, feil 5 \u2014 er \u201cTilgang nektet\u201d, og 1722 \u2014 er \u201cRPC-serveren er utilgjengelig\u201d, og 10060 \u2014 er \u201cTilkobling timeout\u201d. Selvf\u00f8lgelig er det flott hvis du husker de mest kjente, men hva med dem som man aldri har sett f\u00f8r? <\/p>\n

Og for at livet ikke skulle virke for perfekt, lagres feil ogs\u00e5 i heksadesimal form med prefikset 0x8007. For eksempel, 0x8007000e \u2014 dette er faktisk 14, Out of Memory. Hvorfor og for hvem dette ble gjort \u2014 er et mysterium. Imidlertid kan den komplette listen over feil lastes ned gratis og uten SMS fra devsenter<\/u><\/a><\/noindex>.<\/p>\n

Forresten, noen ganger finner man ogs\u00e5 andre prefikser, ikke bare 0x8007. I en s\u00e5 trist situasjon, for \u00e5 forst\u00e5 HRESULT (\"result handle\"), m\u00e5 man g\u00e5 enda dypere inn i dokumentasjonen<\/u><\/a><\/noindex> for utviklere. I det daglige vil jeg ikke anbefale \u00e5 gj\u00f8re dette, men hvis du plutselig blir presset mot veggen eller bare er nysgjerrig, vet du n\u00e5 hva du skal gj\u00f8re.<\/p>\n

Men gutta i Microsoft har v\u00e6rt litt snille mot oss og har presentert en verkt\u00f8y ERR<\/u><\/a><\/noindex>. Dette er et lite stykke konsolllykke, som kan oversette feilkoder til menneskelig spr\u00e5k uten \u00e5 bruke Google. Det fungerer omtrent slik.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# En intern feil oppstod.\n# som en HRESULT: Alvorlighetsgrad: SUKSESS (0), FAGNULL (0x0), Kode 0x54f\n# for hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# En intern feil oppstod.\n# 2 treff funnet for \"0x54f\"<\/code><\/pre>\n
Det oppst\u00e5r et legitimt sp\u00f8rsm\u00e5l: hvorfor skriver vi ikke straks avkodingen inn i loggene, men lar disse mystiske kodene v\u00e6re? Svaret ligger i tredjepartsapplikasjoner. N\u00e5r du selv kaller en WinAPI-funksjon, er det ikke vanskelig \u00e5 dekode svaret, ettersom det til og med finnes et eget spesiallagt WinAPI-anrop for dette. Men som allerede nevnt, f\u00e5r v\u00e5re logger inn alt som kommer tilbake i svarene v\u00e5re. Og her m\u00e5tte dekoding konstant overv\u00e5kes, for \u00e5 plukke ut biter med Windows-feil, dekode dem og sette dem tilbake. La oss v\u00e6re \u00e6rlige, det er ikke den mest spennende oppgaven.<\/p>\n
Windows File Management API <\/strong>bruken av dette i filbehandling er allsidig. Oppretting av filer, sletting, \u00e5pning for skriving, arbeid med attributter, og s\u00e5 videre.<\/p>\n
Den nevnte PowerShell Direct<\/strong> som et alternativ til VIX API i Hyper-V. Dessverre ikke s\u00e5 fleksibel: mange begrensninger i funksjonaliteten, fungerer ikke med hver versjon av verten og langt fra med alle gjester.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Jeg tror det ikke finnes en eneste person som har jobbet med Windows som ikke har sett feil relatert til RPC. Til tross for en popul\u00e6r misforst\u00e5else, er dette ikke en enkel protokoll, men hvilken som helst klient-serverprotokoll som oppfyller en rekke kriterier. Men hvis vi har en RPC-feil i loggene v\u00e5re, vil det i 90 % av tilfellene v\u00e6re en feil fra Microsoft RPC, som er en del av DCOM (Distributed Component Object Model). Det finnes en enorm mengde dokumentasjon om dette emnet online, men det meste er ganske foreldet. Men hvis du virkelig \u00f8nsker \u00e5 l\u00e6re mer, kan jeg anbefale artikler Hva er RPC?<\/u><\/a><\/noindex>, Hvordan RPC fungerer<\/u> <\/a><\/noindex>og en lang liste av RPC-feil<\/u><\/a><\/noindex>.<\/p>\n
De viktigste \u00e5rsakene til at RPC-feil oppst\u00e5r i loggene v\u00e5re \u2014 er mislykkede fors\u00f8k p\u00e5 \u00e5 samhandle mellom VBR-komponenter (server > proxy, for eksempel) og oftest p\u00e5 grunn av kommunikasjonsproblemer.<\/p>\n
Toppen av alle topper \u2014 er feilen The RPC server is unavailable (1722). For \u00e5 si det enkelt, klarte ikke klienten \u00e5 etablere en forbindelse med serveren. Hvordan og hvorfor \u2014 er det ingen entydig svar p\u00e5, men det er vanligvis et problem med autentisering eller nettverkstilgang til port 135. Det siste er typisk for infrastrukturer med dynamisk portallokering. Det finnes til og med informasjon om dette en egen KB<\/u><\/a><\/noindex>. Og hos Microsoft \u2014 en omfattende guide<\/u><\/a><\/noindex> for \u00e5 finne \u00e5rsakene til feilen.<\/p>\n
Den nest mest popul\u00e6re feilen: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller serveren klarte ikke \u00e5 tildele seg en port. Dette skjer vanligvis n\u00e5r serveren (i v\u00e5rt tilfelle gjeste-maskinen) var konfigurert for dynamisk tildeling av porter fra et smalt omr\u00e5de som tok slutt. Hvis vi ser fra klientens side (i v\u00e5rt tilfelle VBR-serveren), betyr det at v\u00e5r VeeamVssAgent enten ikke startet eller ikke ble registrert som RPC-grensesnitt. Det finnes ogs\u00e5 en egen KB<\/u><\/a><\/noindex>.<\/p>\n
Og for \u00e5 avslutte Topp-3 RPC-feilene, la oss huske RPC function call failed (1726). Dette skjer hvis forbindelsen ble opprettet, men RPC-foresp\u00f8rslene blir ikke behandlet. For eksempel, vi ber om informasjon om VSS-status (hvis det tilfeldigvis blir laget skyggkopi akkurat n\u00e5, og vi pr\u00f8ver \u00e5 f\u00e5 tilgang), men i svaret f\u00e5r vi stillhet og ignoreres.<\/p>\n
Windows Tape Backup API <\/strong>er n\u00f8dvendig for \u00e5 arbeide med b\u00e5ndbiblioteker eller stasjoner. Som jeg nevnte i begynnelsen: \u00e5 skrive egne drivere og slite med \u00e5 st\u00f8tte hver enhet gir oss ingen glede. Derfor har Veeam ingen egne drivere. Alt skjer via standard API, som st\u00f8ttes av maskinvareleverand\u00f8rene selv. Det er jo mye mer logisk, ikke sant?<\/p>\n
SMB\/CIFS<\/strong> Alle pleier \u00e5 skrive dem n\u00e6r hverandre, selv om ikke alle husker at CIFS (Common Internet File System) \u2014 er bare en privat versjon av SMB (Server Message Block). S\u00e5 det er ikke noe galt i \u00e5 generalisere disse begrepene. Samba \u2014 er allerede LinuxUnix-implementeringen, og der er det sine egne spesifikasjoner, men det var jeg som ble distrahert. Det som her er viktig: n\u00e5r Veeam ber om \u00e5 skrive noe til en UNC-bane (serverdirectory), bruker serveren en hierarki av filsystemdrivere, inkludert mup og mrxsmb, for \u00e5 skrive til delingen. F\u00f8lgelig vil ogs\u00e5 disse driverne generere feil.<\/p>\n
Kan ikke klare seg uten Winsock API<\/strong>. Hvis noe skal gj\u00f8res over nettverket, fungerer VBR gjennom Windows Socket API, kjent som Winsock. S\u00e5 hvis vi ser i loggen en kobling mellom IP:Port, s\u00e5 er det dette. Den offisielle dokumentasjonen har en ganske god liste over mulige feil<\/u><\/a><\/noindex>.<\/p>\n
Den nevnte WMI<\/strong> (Windows Management Instrumentation) \u2014 er et allsidig API for \u00e5 administrere alt og alle i Windows-verdenen. For eksempel skjer nesten alle foresp\u00f8rslene til verten gjennom det n\u00e5r man jobber med Hyper-V. Med andre ord, en uunnv\u00e6rlig og en sv\u00e6rt kraftig l\u00f8sning. I fors\u00f8kene p\u00e5 \u00e5 finne ut hvor og hva som har g\u00e5tt galt, er det innebygde verkt\u00f8yet WBEMtest.exe til stor hjelp.<\/p>\n
Og den siste p\u00e5 listen, men absolutt ikke minst betydningsfull \u2014 VSS<\/strong> (Volume Shadow Storage). Temaet er like uendelig og mystisk som det er skrevet mye dokumentasjon om. Shadow Copy kan enklest forst\u00e5s som en spesiell type snapshot, som det i bunn og grunn er. Takket v\u00e6re det er det mulig \u00e5 lage applikasjonskonsistente sikkerhetskopier i VMware, og i Hyper-V nesten alt. Jeg har planer om \u00e5 lage en egen artikkel med en slags oppsummering om VSS, men inntil videre kan du pr\u00f8ve \u00e5 lese denne beskrivelsen<\/u><\/a><\/noindex>. V\u00e6r forsiktig, da et fors\u00f8k p\u00e5 \u00e5 forst\u00e5 VSS i en fei kan f\u00f8re til hodeskader.<\/p>\n
P\u00e5 dette punktet kan vi kanskje stoppe. Jeg anser oppgaven med \u00e5 forklare de mest grunnleggende tingene som fullf\u00f8rt, s\u00e5 i neste kapittel vil vi se p\u00e5 loggene. Men hvis du har sp\u00f8rsm\u00e5l, ikke n\u00f8l med \u00e5 komme med dem i kommentarfeltet.<\/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 fortsetter v\u00e5r dypdykk i den fascinerende verden av sp\u00e5dom...","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}