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

\"Varifr\u00e5n<\/p>\n

Vi forts\u00e4tter v\u00e5r f\u00f6rdjupning i den fascinerande v\u00e4rlden av fels\u00f6kning genom loggar. den f\u00f6reg\u00e5ende artikeln<\/a><\/noindex> Vi har kommit \u00f6verens om betydelsen av grundl\u00e4ggande termer och har med ett \u00f6ga tittat p\u00e5 den \u00f6vergripande strukturen av Veeam som en enhetlig applikation. M\u00e5let med detta \u00e4r att f\u00f6rst\u00e5 hur loggfilerna skapas, vilken information som visas i dem och varf\u00f6r de ser ut som de g\u00f6r.<\/p>\n

Vad tycker ni egentligen att dessa \"loggar\" \u00e4r? Enligt de flesta borde loggar f\u00f6r vilken applikation som helst tilldelas rollen av en allsm\u00e4ktig entitet, som oftast slumrar n\u00e5gonstans i bakgrunden men som vid r\u00e4tt tillf\u00e4lle dyker upp fr\u00e5n ingenstans i skinande rustning och r\u00e4ddar alla. Det vill s\u00e4ga de borde inneh\u00e5lla allt, fr\u00e5n de minsta felen i varje komponent till enskilda databastransaktioner. Och efter ett fel borde det skrivas direkt hur man kan r\u00e4tta till det. Och allt detta borde f\u00e5 plats i ett par megabyte, inte mer. Det h\u00e4r \u00e4r ju bara text! Textfiler kan inte ta upp tiotals gigabyte, det har jag h\u00f6rt n\u00e5gonstans!<\/p>\n

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

I den verkliga v\u00e4rlden \u00e4r loggar bara ett arkiv av diagnostisk information. Vilken information som ska lagras, hur man h\u00e4mtar informationen f\u00f6r lagring och hur detaljerad den ska vara, \u00e4r upp till utvecklarna. Vissa g\u00e5r den minimalistiska v\u00e4gen och lagrar endast p\u00e5\/av-poster, medan andra ivrigt samlar allt de kan f\u00e5 tag p\u00e5. Det finns ocks\u00e5 ett mellanl\u00e4ge med m\u00f6jlighet att v\u00e4lja s\u00e5 kallad Logging Level, d\u00e4r du sj\u00e4lv anger hur detaljerad information du vill lagra och hur mycket \u00f6verfl\u00f6digt utrymme du har p\u00e5 disken =) VBR har faktiskt hela sex s\u00e5dana niv\u00e5er. Och tro mig, du vill inte se vad som h\u00e4nder vid den mest detaljrika loggningen med fritt utrymme p\u00e5 din disk.<\/p>\n

Bra. Vi har ungef\u00e4r f\u00f6rst\u00e5tt vad vi vill spara, men en ber\u00e4ttigad fr\u00e5ga uppst\u00e5r: varifr\u00e5n ska vi h\u00e4mta denna information? En del av h\u00e4ndelserna f\u00f6r loggning skapar vi sj\u00e4lva med v\u00e5ra interna processer. Men vad ska vi g\u00f6ra n\u00e4r det sker interaktion med en extern milj\u00f6? F\u00f6r att inte glida ned i en katastrof av provisoriska l\u00f6sningar och cyklar, har Veeam en tendens att inte \u00e5teruppfinna hjulet. N\u00e4r det finns ett redan f\u00e4rdigt API, en inbyggd systemfunktion, ett bibliotek osv., s\u00e5 kommer vi att f\u00f6redra de redan etablerade l\u00f6sningarna innan vi b\u00f6rjar skapa v\u00e5ra egna intrikata l\u00f6sningar. \u00c4ven om det ocks\u00e5 finns gott om s\u00e5dana. D\u00e4rf\u00f6r \u00e4r det viktigt att f\u00f6rst\u00e5 n\u00e4r man analyserar loggar att den st\u00f6rsta delen av felen kommer fr\u00e5n meddelanden fr\u00e5n externa API:er, systemanrop och andra bibliotek. I detta fall handlar VBR:s roll om att f\u00f6ra dessa fel vidare till loggfilerna som de \u00e4r. Den prim\u00e4ra uppgiften f\u00f6r anv\u00e4ndaren \u00e4r att l\u00e4ra sig f\u00f6rst\u00e5 vilken rad som kommer fr\u00e5n vem, och vad denna \"vem\" ansvarar f\u00f6r. S\u00e5 om felkoden fr\u00e5n VBR-loggen leder dig till en MSDN-sida, \u00e4r det normalt och korrekt.<\/p>\n

Som vi har kommit \u00f6verens om tidigare: Veeam \u00e4r en s\u00e5 kallad SQL-baserad applikation. Det betyder att alla inst\u00e4llningar, all information och egentligen allt som beh\u00f6vs f\u00f6r normal funktionalitet lagras i dess databas.  D\u00e4rifr\u00e5n f\u00f6ljer en enkel sanning: det som inte finns i loggarna finns troligen i databasen. Men detta \u00e4r inte en silverkula: vissa saker finns varken i de lokala loggarna f\u00f6r Veeam-komponenterna eller i dess databas. D\u00e4rf\u00f6r beh\u00f6ver vi l\u00e4ra oss att granska v\u00e4rdloggar, loggar fr\u00e5n den lokala maskinen och loggar fr\u00e5n allt som deltar i backup- och restaureringsprocessen. Och ibland kan det h\u00e4nda att den n\u00f6dv\u00e4ndiga informationen inte finns n\u00e5gonstans. S\u00e5 h\u00e4r \u00e4r verkligheten. <\/p>\n

N\u00e5gra exempel p\u00e5 s\u00e5dana API:er<\/h4>\n

Denna lista har inte som m\u00e5l att vara fullst\u00e4ndig, s\u00e5 man ska inte f\u00f6rv\u00e4nta sig att finna den sista sanningen h\u00e4r. Dess syfte \u00e4r endast att visa de mest vanliga externa API:erna och teknologierna som anv\u00e4nds i v\u00e5ra produkter.<\/p>\n

L\u00e5t oss b\u00f6rja med VMware<\/strong>. <\/p>\n

F\u00f6rst i listan kommer vSphere API<\/strong>. Anv\u00e4nds f\u00f6r autentisering, l\u00e4sning av hierarkier, skapande och radering av snapshots, f\u00f6rfr\u00e5gan om information om maskiner och mycket (mycket) mer. Funktionaliteten \u00e4r mycket omfattande, s\u00e5 jag kan rekommendera  VMware vSphere API Referens f\u00f6r versionen 5.5<\/u><\/a><\/noindex> och 6.0<\/u><\/a><\/noindex>. F\u00f6r mer aktuella versioner kan man enkelt googla.<\/p>\n

VIX API<\/strong>. Den svarta magin hos hypervisorn, f\u00f6r vilken det finns en separat lista \u00f6ver fel<\/u><\/a><\/noindex>. VMware API f\u00f6r att arbeta med filer p\u00e5 v\u00e4rden utan n\u00e4tverksanslutning. En sista utv\u00e4g n\u00e4r man beh\u00f6ver l\u00e4gga en fil p\u00e5 en maskin som inte har b\u00e4ttre kommunikationskanaler. Det inneb\u00e4r en del sm\u00e4rta och lidande om filen \u00e4r stor och v\u00e4rden \u00e4r belastad. Men h\u00e4r g\u00e4ller regeln att \u00e4ven 56,6 Kb\/s \u00e4r b\u00e4ttre \u00e4n 0 Kb\/s. I Hyper-V kallas en liknande funktion PowerShell Direct. Men s\u00e5 var det bara fram till introduktionen av<\/p>\n

vSphere Web Services API<\/strong> . Fr\u00e5n och med vSphere 6.0 (ungef\u00e4r, eftersom detta API f\u00f6rsta g\u00e5ngen introducerades i version 5.5) anv\u00e4nds det f\u00f6r att hantera g\u00e4stmaskiner och har redan praktiskt taget ersatt VIX \u00f6verallt. I grund och botten \u00e4r det \u00e4nnu ett API f\u00f6r att hantera vSphere. F\u00f6r den intresserade kan jag rekommendera att studera den utm\u00e4rkta<\/u><\/a><\/noindex> manualen. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Ett bibliotek som delvis n\u00e4mndes i denna artikeln<\/u><\/a><\/noindex>. Anv\u00e4nds f\u00f6r att l\u00e4sa virtuella diskar. En g\u00e5ng i tiden var den en del av VIX, men har med tiden avskilts till en egen produkt. Den anv\u00e4nder dock samma felkoder som VIX eftersom den \u00e4r dess arvtagare.  Men av n\u00e5gon anledning finns det ingen beskrivning av dessa fel i sj\u00e4lva SDK:n. D\u00e4rf\u00f6r har man genom erfarenhet kommit fram till att fel fr\u00e5n VDDK med andra koder endast \u00e4r en \u00f6vers\u00e4ttning fr\u00e5n bin\u00e4r till decimal kod. Den best\u00e5r av tv\u00e5 delar \u2013 den f\u00f6rsta halvan \u00e4r icke-dokumenterad information om kontexten, medan den andra delen inneh\u00e5ller traditionella VIX\/VDDK-fel. Till exempel, om vi ser:<\/p>\n

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

D\u00e5 konverterar vi detta till hex och f\u00e5r 132200000001. Den oinformationsrika b\u00f6rjan 132200 avst\u00e5r vi fr\u00e5n, och resten blir v\u00e5r felkod (VDDK 1: Ok\u00e4nt fel).  Det har nyligen skrivits en separat artikel om de vanligaste VDDK-felen. artikeln<\/u><\/a><\/noindex>.<\/p>\n

Nu ska vi titta p\u00e5 Windows<\/strong>. <\/p>\n

H\u00e4r hittar vi allt som \u00e4r n\u00f6dv\u00e4ndigt och viktigt f\u00f6r oss i den standard Event Viewer<\/strong>. Men det finns en hake: enligt en gammal tradition loggar Windows inte den fullst\u00e4ndiga feltexten, utan endast numret. Till exempel, fel 5 \u2014 det \u00e4r \u201c\u00c5tkomst nekad\u201d, och 1722 \u2014 det \u00e4r \u201cRPC-servern \u00e4r inte tillg\u00e4nglig\u201d, och 10060 \u2014 det \u00e4r \u201cAnslutningen har tids\u00f6verstridit\u201d. Sj\u00e4lvklart \u00e4r det bra om man minns de mest k\u00e4nda, men hur g\u00f6r man med s\u00e5nt man aldrig sett f\u00f6rut? <\/p>\n

F\u00f6r att livet inte ska verka allt f\u00f6r enkelt, lagras fel ocks\u00e5 i hexadecimalt format, med prefixet 0x8007. Till exempel, 0x8007000e \u2014 det \u00e4r faktiskt 14, Out of Memory. Varf\u00f6r och f\u00f6r vem det gjordes \u00e4r en g\u00e5ta. Men en fullst\u00e4ndig lista \u00f6ver fel kan laddas ner gratis och utan SMS fr\u00e5n utvecklingscentret<\/u><\/a><\/noindex>.<\/p>\n

F\u00f6r \u00f6vrigt f\u00f6rekommer ibland andra prefix \u00e4n bara 0x8007. I en s\u00e5dan olycklig situation m\u00e5ste man djupare f\u00f6rst\u00e5 HRESULT (\"result handle\") dokumentationen<\/u><\/a><\/noindex> f\u00f6r utvecklarna. I det normala livet rekommenderar jag dig inte att g\u00f6ra s\u00e5 h\u00e4r, men om du skulle bli pressad mot v\u00e4ggen eller bara \u00e4r nyfiken, s\u00e5 vet du nu vad du ska g\u00f6ra.<\/p>\n

Men killarna p\u00e5 Microsoft visade lite medk\u00e4nsla och presenterade v\u00e4rlden f\u00f6r ett verktyg ERR<\/u><\/a><\/noindex>. Det \u00e4r en liten del av konsolens lycka, som kan \u00f6vers\u00e4tta felkoder till m\u00e4nskligt spr\u00e5k utan att anv\u00e4nda Google. Den fungerar ungef\u00e4r s\u00e5 h\u00e4r.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# f\u00f6r hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ett internt fel intr\u00e4ffade.\n# som ett HRESULT: Allvarlighetsgrad: SUCCESS (0), FACILITY_NULL (0x0), Kod 0x54f\n# f\u00f6r hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ett internt fel intr\u00e4ffade.\n# 2 tr\u00e4ffar hittades f\u00f6r \"0x54f\"<\/code><\/pre>\n
Det v\u00e4cker en giltig fr\u00e5ga: varf\u00f6r skriver vi inte direkt avkodningen i loggarna, utan l\u00e4mnar dessa mystiska koder? Svaret ligger i tredjepartsapplikationer. N\u00e4r du sj\u00e4lv kallar p\u00e5 n\u00e5got WinAPI-anrop \u00e4r det inte sv\u00e5rt att avkoda svaret, eftersom det finns ett speciellt WinAPI-anrop f\u00f6r det. Men som redan n\u00e4mnts hamnar allt i v\u00e5ra loggar som vi f\u00e5r i svaren. H\u00e4r skulle vi dock beh\u00f6va st\u00e4ndigt \u00f6vervaka detta fl\u00f6de av medvetande, plocka ut bitar med Windows-fel, avkoda dem och s\u00e4tta tillbaka dem. L\u00e5t oss vara \u00e4rliga, det \u00e4r inte s\u00e4rskilt sp\u00e4nnande.<\/p>\n
Windows Filhanterings-API <\/strong>anv\u00e4nds i h\u00f6g grad n\u00e4r man arbetar med filer. Skapande av filer, radering, \u00f6ppning f\u00f6r skrivning, arbete med attribut och s\u00e5 vidare.<\/p>\n
Den ovan n\u00e4mnda PowerShell Direct<\/strong> som ett alternativ till VIX API i Hyper-V v\u00e4rlden. Tyv\u00e4rr inte s\u00e5 flexibelt: m\u00e5nga begr\u00e4nsningar i funktionaliteten, fungerar inte med varje version av v\u00e4rden och l\u00e5ngt ifr\u00e5n alla g\u00e4ster.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Jag tror att det inte finns en enda person som har arbetat med Windows som inte har sett fel relaterade till RPC. Trots den popul\u00e4ra missuppfattningen \u00e4r det inte en enda protokoll, utan vilket klient-serverprotokoll som helst som uppfyller vissa kriterier. Men om vi har ett RPC-fel i v\u00e5ra loggar, \u00e4r det i 90% av fallen ett fel fr\u00e5n Microsoft RPC, som \u00e4r en del av DCOM (Distributed Component Object Model). Det finns ett stort antal dokumentationer kring detta \u00e4mne, men det mesta av det \u00e4r ganska gammalt. Men om det finns en stark vilja att studera \u00e4mnet kan jag rekommendera artiklar Vad \u00e4r RPC?<\/u><\/a><\/noindex>, Hur RPC fungerar<\/u> <\/a><\/noindex>och en l\u00e5ng lista RPC-fel<\/u><\/a><\/noindex>.<\/p>\n
De fr\u00e4msta orsakerna till RPC-fel i v\u00e5ra loggar \u00e4r misslyckade f\u00f6rs\u00f6k till interaktion mellan VBR-komponenter (server > proxy, till exempel) och oftast p\u00e5 grund av kommunikationsproblem.<\/p>\n
Det mest framst\u00e5ende felet av alla \u00e4r felet The RPC server is unavailable (1722). Om vi s\u00e4ger det enkelt, kunde klienten inte uppr\u00e4tta en anslutning till servern. Hur och varf\u00f6r \u2014 det finns inget entydigt svar, men vanligtvis \u00e4r det ett autentisering- eller n\u00e4tverksproblem till port 135. Det senaste \u00e4r typiskt f\u00f6r infrastrukturer med dynamiskt tilldelade portar. Det finns till och med en separat KB<\/u><\/a><\/noindex>. Och f\u00f6r Microsoft \u2014 en omfattande guide<\/u><\/a><\/noindex> f\u00f6r att hitta orsakerna till felet.<\/p>\n
Det n\u00e4st mest popul\u00e4ra felet: There are no more endpoints available from the endpoint mapper (1753). RPC-klienten eller servern kunde inte tilldela en port till sig sj\u00e4lva. Det intr\u00e4ffar vanligtvis n\u00e4r servern (i v\u00e5rt fall v\u00e4rdmaskinen) \u00e4r inst\u00e4lld p\u00e5 dynamisk portallokering fr\u00e5n ett smalt omr\u00e5de som har tagit slut. Om vi ser det fr\u00e5n klientens sida (i v\u00e5rt fall VBR-servern) betyder det att v\u00e5r VeeamVssAgent antingen inte startade eller inte registrerades som RPC-gr\u00e4nssnitt. Det finns ocks\u00e5 en separat KB<\/u><\/a><\/noindex>.<\/p>\n
Och f\u00f6r att avsluta topp-3 RPC-fel, l\u00e5t oss minnas RPC function call failed (1726). Det intr\u00e4ffar om anslutningen har uppr\u00e4ttats, men RPC-beg\u00e4rningarna inte genomf\u00f6rs. Till exempel, vi beg\u00e4r information om VSS-status (om det till exempel just nu g\u00f6rs shadow copy, och vi f\u00f6rs\u00f6ker g\u00e5 in), och som svar f\u00e5r vi tystnad och ignorans.<\/p>\n
Windows Tape Backup API <\/strong>Beh\u00f6vs f\u00f6r att arbeta med bandbibliotek eller enheter. Som jag n\u00e4mnde i b\u00f6rjan: det \u00e4r ingen n\u00f6je att skriva sina egna drivrutiner och sedan pl\u00e5ga sig med att st\u00f6dja varje enhet. D\u00e4rf\u00f6r har Veeam inga egna drivrutiner. Allt g\u00e5r via standard-API:n, vars st\u00f6d tillhandah\u00e5lls av h\u00e5rdvaruleverant\u00f6rerna sj\u00e4lva. S\u00e5 mycket mer logiskt, eller hur?<\/p>\n
SMB\/CIFS<\/strong> Alla skriver av gammal vana dem bredvid varandra, \u00e4ven om inte alla minns att CIFS (Common Internet File System) \u00e4r helt enkelt en privat version av SMB (Server Message Block). S\u00e5, inget fel med att generalisera dessa begrepp. H\u00e4r \u00e4r Samba en LinuxUnix-implementation, och d\u00e4r finns sina egna s\u00e4rdrag, men det \u00e4r jag avvek. Vad som \u00e4r viktigt h\u00e4r: n\u00e4r Veeam ber om att skriva n\u00e5got via UNC-s\u00f6kv\u00e4g (serverdirectory), anv\u00e4nder servern filsystemets drivrutinsstruktur, inklusive mup och mrxsmb, f\u00f6r att skriva till delningen. D\u00e4rf\u00f6r kommer \u00e4ven dessa drivrutiner att generera fel.<\/p>\n
Det g\u00e5r inte att klara sig utan Winsock API<\/strong>. Om n\u00e5got beh\u00f6ver g\u00f6ras \u00f6ver n\u00e4tverket arbetar VBR genom Windows Socket API, som allm\u00e4nt kallas Winsock. S\u00e5 om vi ser i loggen en koppling mellan IP:Port, d\u00e5 \u00e4r det det. I den officiella dokumentationen finns en ganska bra lista \u00f6ver m\u00f6jliga fel<\/u><\/a><\/noindex>.<\/p>\n
Den ovan n\u00e4mnda WMI<\/strong> (Windows Management Instrumentation) \u2014 ett allt-i-ett API f\u00f6r att hantera allt och alla i Windows-v\u00e4rlden. Till exempel, n\u00e4r man arbetar med Hyper-V sker n\u00e4stan alla f\u00f6rfr\u00e5gningar till v\u00e4rden via det. Kort sagt, en helt ov\u00e4rderlig och mycket kraftfull komponent. F\u00f6r att hj\u00e4lpa till att avg\u00f6ra var och vad som har g\u00e5tt fel \u00e4r det inbyggda verktyget WBEMtest.exe till stor hj\u00e4lp.<\/p>\n
Och sist p\u00e5 listan, men absolut inte minst vad g\u00e4ller betydelse \u2014 VSS<\/strong> (Volume Shadow Storage). \u00c4mnet \u00e4r lika outt\u00f6mligt och mystiskt som det finns mycket dokumentation skriven om det. Shadow Copy kan enklast f\u00f6rst\u00e5s som en speciell typ av snapshot, vilket det i grunden \u00e4r. Tack vare det kan man i VMware g\u00f6ra applikationskonsekventa s\u00e4kerhetskopior, och i Hyper-V n\u00e4stan allt. Jag planerar att g\u00f6ra en separat artikel med en sammanst\u00e4llning av VSS, men tills dess kan du f\u00f6rs\u00f6ka l\u00e4sa denna beskrivning<\/u><\/a><\/noindex>. Var f\u00f6rsiktig, eftersom ett f\u00f6rs\u00f6k att f\u00f6rst\u00e5 VSS p\u00e5 spr\u00e5ng kan leda till hj\u00e4rnskador.<\/p>\n
Det h\u00e4r borde r\u00e4cka. Jag anser att uppgiften att f\u00f6rklara de mest grundl\u00e4ggande sakerna \u00e4r genomf\u00f6rd, s\u00e5 i n\u00e4sta kapitel kommer vi att titta p\u00e5 loggarna. Men om du har n\u00e5gra fr\u00e5gor, tveka inte att st\u00e4lla dem i kommentarerna.<\/p>\n<\/p>\n
K\u00e4lla: 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\udd47Var kommer loggarna ifr\u00e5n? Veeam Log Diving | ProHoster","description":"Vi forts\u00e4tter v\u00e5r dykning i den fascinerande v\u00e4rlden av sp\u00e5domar...","canonical_url":"https:\/\/prohoster.info\/sv\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"sv_SE","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\/sv\/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\/sv\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sv\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}