{"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\/pt\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"De onde v\u00eam os logs? Mergulho nos Logs da Veeam","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De<\/p>\n

Continuamos nossa imers\u00e3o no fascinante mundo da resolu\u00e7\u00e3o de problemas atrav\u00e9s de logs. No artigo anterior<\/a><\/noindex> analisamos o significado de termos b\u00e1sicos e espiamos brevemente a estrutura geral do Veeam como um \u00fanico aplicativo. A tarefa agora \u00e9 entender como os arquivos de log s\u00e3o formados, que informa\u00e7\u00f5es eles cont\u00eam e por que eles t\u00eam a apar\u00eancia que possuem.<\/p>\n

O que voc\u00ea acha que s\u00e3o esses 'logs'? Para a maioria, os logs de qualquer aplicativo deveriam desempenhar o papel de uma entidade onipotente que passa a maior parte do tempo escondida, mas que em um momento cr\u00edtico surge do nada em armaduras reluzentes e salva a todos. Ou seja, deveriam conter tudo, desde os menores erros em cada componente at\u00e9 transa\u00e7\u00f5es espec\u00edficas do banco de dados. E, ap\u00f3s um erro, deveria haver uma descri\u00e7\u00e3o de como corrigi-lo. Tudo isso precisaria caber em alguns megabytes, no m\u00e1ximo. Afinal, \u00e9 s\u00f3 texto! Arquivos de texto n\u00e3o podem ocupar dezenas de gigabytes, ouvi isso em algum lugar!<\/p>\n

Assim, os logs<\/h2>\n

No mundo real, os logs s\u00e3o apenas um arquivo de informa\u00e7\u00f5es de diagn\u00f3stico. E o que armazenar, de onde obter as informa\u00e7\u00f5es para armazenamento e qu\u00e3o detalhadas elas devem ser, cabe aos desenvolvedores decidirem. Alguns optam pelo minimalismo, armazenando apenas registros de LIGADO\/DESLIGADO, enquanto outros coletam diligentmente tudo o que conseguem alcan\u00e7ar. Embora exista uma op\u00e7\u00e3o intermedi\u00e1ria com a possibilidade de escolher o chamado N\u00edvel de Registro, onde voc\u00ea mesmo indica qu\u00e3o detalhadas as informa\u00e7\u00f5es que deseja manter e quanto espa\u00e7o extra voc\u00ea possui em seus discos =) No VBR, existem seis desses n\u00edveis, a prop\u00f3sito. E, acredite, voc\u00ea n\u00e3o quer ver o que acontece quando o registro \u00e9 feito no n\u00edvel mais detalhado com espa\u00e7o livre em seu disco.<\/p>\n

Bem. J\u00e1 entendemos aproximadamente o que queremos manter, mas surge a pergunta leg\u00edtima: de onde obter essas informa\u00e7\u00f5es? Parte dos eventos para logar, \u00e9 claro, s\u00e3o gerados por n\u00f3s mesmos atrav\u00e9s dos nossos processos internos. Mas o que fazer quando ocorre uma intera\u00e7\u00e3o com o ambiente externo? Para n\u00e3o mergulhar em um verdadeiro caos de gambiarras e solu\u00e7\u00f5es improvisadas, o Veeam tende a n\u00e3o reinventar a roda. Sempre que h\u00e1 uma API j\u00e1 existente, uma fun\u00e7\u00e3o embutida no sistema, uma biblioteca, etc., devemos priorizar as op\u00e7\u00f5es prontas antes de criarmos nossas pr\u00f3prias solu\u00e7\u00f5es engenhosas. Embora haja muitas delas tamb\u00e9m. Portanto, ao analisar logs, \u00e9 importante entender que a grande maioria dos erros vem de mensagens de APIs externas, chamadas de sistema e outras bibliotecas. Nesse caso, o papel do VBR \u00e9 encaminhar esses erros para os arquivos de log exatamente como est\u00e3o. E a principal tarefa do usu\u00e1rio \u00e9 aprender a entender qual linha vem de quem e a que esse \u201cquem\u201d se refere. Portanto, se o c\u00f3digo de erro do log do VBR te direciona para uma p\u00e1gina do MSDN, isso \u00e9 normal e correto.<\/p>\n

Como combinamos anteriormente: Veeam \u00e9 um aplicativo baseado em SQL. Isso significa que todas as configura\u00e7\u00f5es, todas as informa\u00e7\u00f5es e, na verdade, tudo o que \u00e9 necess\u00e1rio para seu funcionamento adequado est\u00e3o armazenados em seu banco de dados. Da\u00ed a verdade simples: o que n\u00e3o est\u00e1 nos logs, provavelmente est\u00e1 no banco. Mas isso n\u00e3o \u00e9 uma solu\u00e7\u00e3o m\u00e1gica: algumas informa\u00e7\u00f5es n\u00e3o est\u00e3o nos logs locais dos componentes do Veeam, nem em seu banco de dados. Portanto, \u00e9 necess\u00e1rio aprender a examinar os logs do host, os logs da m\u00e1quina local e os logs de tudo que participa do processo de backup e restaura\u00e7\u00e3o. \u00c0s vezes, a informa\u00e7\u00f5es necess\u00e1ria pode n\u00e3o estar em lugar nenhum. Este \u00e9 o caminho. <\/p>\n

Alguns exemplos de tais APIs<\/h4>\n

Esta lista n\u00e3o tem como objetivo ser de uma completude exclusiva, ent\u00e3o n\u00e3o procure nela a verdade em \u00faltima inst\u00e2ncia. Sua tarefa \u00e9 apenas mostrar as APIs e tecnologias de terceiros mais comuns usadas em nossos produtos.<\/p>\n

Vamos come\u00e7ar com VMware<\/strong>. <\/p>\n

O primeiro da lista ser\u00e1 vSphere API<\/strong>. Usado para autentica\u00e7\u00e3o, leitura de hierarquia, cria\u00e7\u00e3o e exclus\u00e3o de snapshots, solicita\u00e7\u00e3o de informa\u00e7\u00f5es sobre m\u00e1quinas e muito (muito) mais. A funcionalidade da solu\u00e7\u00e3o \u00e9 bastante ampla, portanto, recomendo a todos que desejam consultar o  VMware vSphere API Reference para a vers\u00e3o 5.5<\/u><\/a><\/noindex> e 6.0<\/u><\/a><\/noindex>. Para vers\u00f5es mais atuais, \u00e9 f\u00e1cil encontrar informa\u00e7\u00f5es na internet.<\/p>\n

VIX API<\/strong>. Magia negra do hipervisor, para a qual h\u00e1 uma lista separada de erros<\/u><\/a><\/noindex>. API do VMware para trabalhar com arquivos no host sem conex\u00e3o de rede. Uma op\u00e7\u00e3o de \u00faltimo recurso quando \u00e9 necess\u00e1rio colocar um arquivo na m\u00e1quina que n\u00e3o possui um canal de comunica\u00e7\u00e3o melhor. \u00c9 uma fonte de dor e sofrimento se o arquivo for grande e o host estiver sobrecarregado. Mas a regra aqui \u00e9 que mesmo 56,6 Kb\/s \u00e9 melhor do que 0 Kb\/s. No Hyper-V, uma coisa semelhante \u00e9 chamada de PowerShell Direct. Mas isso s\u00f3 era verdade at\u00e9 o advento<\/p>\n

do vSphere Web Services API<\/strong> . Come\u00e7ando com o vSphere 6.0 (aproximadamente, j\u00e1 que esse API foi introduzido pela primeira vez na vers\u00e3o 5.5), \u00e9 usado para trabalhar com m\u00e1quinas virtuais e h\u00e1 muito substituiu o VIX. Na verdade, \u00e9 mais uma API para gerenciar o vSphere. Para os interessados, recomendo estudar um excelente<\/u><\/a><\/noindex> manual. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Uma biblioteca que foi parcialmente mencionada neste artigo<\/u><\/a><\/noindex>. Usado para leitura de discos virtuais. H\u00e1 muito tempo fazia parte do VIX, por\u00e9m foi eventualmente separado em um produto separado. Contudo, como herdeiro, utiliza os mesmos c\u00f3digos de erro que o VIX. Mas, por algum motivo, o pr\u00f3prio SDK n\u00e3o tem nenhuma descri\u00e7\u00e3o desses erros. Portanto, foi descoberto empiricamente que erros do VDDK com outros c\u00f3digos s\u00e3o apenas uma tradu\u00e7\u00e3o de bin\u00e1rio para decimal. Consiste em duas partes \u2013 a primeira metade apresenta informa\u00e7\u00f5es n\u00e3o documentadas sobre o contexto, e a segunda parte \u2013 os erros tradicionais do VIX\/VDDK. Por exemplo, se vemos:<\/p>\n

Erro VDDK: 21036749815809.Erro desconhecido<\/code><\/p>\n

Convertamos isso para hex e obtemos 132200000001. O in\u00edcio n\u00e3o informativo 132200 \u00e9 descartado, e o restante ser\u00e1 nosso c\u00f3digo de erro (VDDK 1: Erro desconhecido). Recentemente, houve uma publica\u00e7\u00e3o separada sobre os erros VDDK mais frequentes. artigo<\/u><\/a><\/noindex>.<\/p>\n

Agora vamos olhar para Windows<\/strong>. <\/p>\n

. Aqui, tudo o que precisamos e \u00e9 importante pode ser encontrado no Event Viewer<\/strong>. Mas h\u00e1 um por\u00e9m: por uma antiga tradi\u00e7\u00e3o, o Windows n\u00e3o registra o texto completo do erro, apenas seu n\u00famero. Por exemplo, o erro 5 \u00e9 \"Acesso negado\", e 1722 \u00e9 \"O servidor RPC n\u00e3o est\u00e1 dispon\u00edvel\", al\u00e9m do 10060 que \u00e9 \"Tempo de conex\u00e3o esgotado\". \u00c9 \u00f3timo se voc\u00ea se lembra dos mais conhecidos, mas como proceder com os at\u00e9 ent\u00e3o nunca vistos? <\/p>\n

E para que a vida n\u00e3o pare\u00e7a t\u00e3o doce, os erros tamb\u00e9m s\u00e3o armazenados em formato hexadecimal, com o prefixo 0x8007. Por exemplo, 0x8007000e \u2014 isso na verdade significa 14, Out of Memory. Por que e para quem foi feito assim \u2014 \u00e9 um mist\u00e9rio. No entanto, uma lista completa de erros pode ser baixada gratuitamente e sem SMS de desenvolvedores<\/u><\/a><\/noindex>.<\/p>\n

Ali\u00e1s, \u00e0s vezes aparecem outros prefixos, n\u00e3o s\u00f3 0x8007. Nessa situa\u00e7\u00e3o triste, para entender o HRESULT (\u201chandle de resultado\u201d), \u00e9 preciso se aprofundar ainda mais em documenta\u00e7\u00e3o<\/u><\/a><\/noindex> para desenvolvedores. Na vida cotidiana, n\u00e3o recomendo fazer isso, mas caso voc\u00ea esteja realmente pressionado ou apenas curiosidade, agora voc\u00ea sabe o que fazer.<\/p>\n

Mas os companheiros da Microsoft foram um pouco mais indulgentes e apresentaram ao mundo a ferramenta ERR<\/u><\/a><\/noindex>. \u00c9 um pequeno peda\u00e7o de felicidade em console, capaz de traduzir c\u00f3digos de erro para uma linguagem compreens\u00edvel sem precisar usar o Google. Funciona mais ou menos assim.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# para hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ocorreu um erro interno.\n# como um HRESULT: Severidade: SUCESSO (0), INSTALA\u00c7\u00c3O_NULL (0x0), C\u00f3digo 0x54f\n# para hex 0x54f \/ decimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ocorreu um erro interno.\n# 2 correspond\u00eancias encontradas para \"0x54f\"<\/code><\/pre>\n
Surge uma pergunta leg\u00edtima: por que n\u00e3o escrevemos a decodifica\u00e7\u00e3o nos logs imediatamente, deixando esses c\u00f3digos misteriosos? A resposta est\u00e1 em aplicativos de terceiros. Quando voc\u00ea mesmo faz uma chamada de WinAPI, decifrar sua resposta n\u00e3o \u00e9 dif\u00edcil, pois existe at\u00e9 uma chamada especial de WinAPI para isso. Mas como j\u00e1 foi mencionado, nossos logs capturam tudo que recebemos em respostas. E aqui, para decifrar, seria necess\u00e1rio monitorar constantemente esse fluxo de consci\u00eancia, extrair peda\u00e7os com erros do Windows, decifrar e inserir de volta. Vamos ser sinceros, n\u00e3o \u00e9 a tarefa mais emocionante.<\/p>\n
API de Gerenciamento de Arquivos do Windows <\/strong>\u00e9 amplamente utilizada ao trabalhar com arquivos. Criar arquivos, excluir, abrir para grava\u00e7\u00e3o, trabalhar com atributos e muito mais.<\/p>\n
A mencionada acima PowerShell Direct<\/strong> como um an\u00e1logo ao VIX API no mundo do Hyper-V. Infelizmente, n\u00e3o t\u00e3o flex\u00edvel: muitas limita\u00e7\u00f5es funcionais, n\u00e3o funciona com todas as vers\u00f5es de host e n\u00e3o com todas as m\u00e1quinas virtuais.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Acredito que n\u00e3o h\u00e1 uma \u00fanica pessoa que trabalhou com Windows e n\u00e3o tenha visto erros relacionados ao RPC. Apesar da cren\u00e7a popular, n\u00e3o se trata de um \u00fanico protocolo, mas sim de qualquer protocolo cliente-servidor que atenda a certos par\u00e2metros. No entanto, se tivermos um erro RPC em nossos logs, em 90% das vezes ser\u00e1 um erro do Microsoft RPC, que \u00e9 parte do DCOM (Distributed Component Object Model). H\u00e1 uma enorme quantidade de documenta\u00e7\u00e3o sobre esse assunto na rede, mas a maior parte est\u00e1 bastante desatualizada. Contudo, se h\u00e1 um interesse genu\u00edno em estudar o tema, posso recomendar artigos O que \u00e9 RPC?<\/u><\/a><\/noindex>, Como RPC Funciona<\/u> <\/a><\/noindex>e uma longa lista de erros RPC<\/u><\/a><\/noindex>.<\/p>\n
As principais causas do surgimento de erros RPC em nossos logs s\u00e3o as tentativas fracassadas de intera\u00e7\u00e3o entre componentes VBR (servidor > proxy, por exemplo) e, mais frequentemente, devido a problemas de comunica\u00e7\u00e3o.<\/p>\n
O erro supremo entre todos os erros \u00e9 o erro The RPC server is unavailable (1722). Simplificando, o cliente n\u00e3o conseguiu estabelecer uma conex\u00e3o com o servidor. Como e por que \u2014 n\u00e3o h\u00e1 uma resposta \u00fanica, mas geralmente \u00e9 um problema de autentica\u00e7\u00e3o ou de acesso \u00e0 rede at\u00e9 a porta 135. Isso \u00e9 caracter\u00edstico de infraestruturas com designa\u00e7\u00e3o din\u00e2mica de portas. Sobre esse assunto, h\u00e1 at\u00e9 KBA separada<\/u><\/a><\/noindex>. E a Microsoft \u2014 extenso guia<\/u><\/a><\/noindex> para encontrar as causas da falha.<\/p>\n
O segundo erro mais comum \u00e9: There are no more endpoints available from the endpoint mapper (1753). O cliente ou servidor RPC n\u00e3o conseguiram escalar uma porta para si. Isso geralmente ocorre quando o servidor (neste caso, a m\u00e1quina virtual) foi configurado para aloca\u00e7\u00e3o din\u00e2mica de portas dentro de um intervalo restrito que foi esgotado. E se olharmos do lado do cliente (neste caso, o servidor VBR), isso significa que o nosso VeeamVssAgent n\u00e3o foi iniciado ou n\u00e3o foi registrado como interface RPC. H\u00e1 tamb\u00e9m KBA separada<\/u><\/a><\/noindex>.<\/p>\n
E para finalizar o Top 3 de erros RPC, lembremos do erro RPC function call failed (1726). Isso aparece quando a comunica\u00e7\u00e3o foi estabelecida, mas as solicita\u00e7\u00f5es RPC n\u00e3o funcionam. Por exemplo, solicitamos informa\u00e7\u00f5es sobre o status do VSS (caso uma c\u00f3pia sombra esteja em andamento, e tentamos acess\u00e1-la), mas recebemos sil\u00eancio e ignor\u00e2ncia em resposta.<\/p>\n
API de Backup de Fitas do Windows <\/strong>\u00e9 necess\u00e1rio para trabalhar com bibliotecas ou drives de fita. Como mencionei no come\u00e7o: escrever seus pr\u00f3prios drivers e depois se preocupar em dar suporte a cada dispositivo n\u00e3o \u00e9 nada agrad\u00e1vel. Portanto, a Veeam n\u00e3o possui drivers pr\u00f3prios. Tudo \u00e9 feito atrav\u00e9s da API padr\u00e3o, cujo suporte \u00e9 fornecido pelos pr\u00f3prios fornecedores de hardware. Assim, faz mais sentido, n\u00e3o faz?<\/p>\n
SMB\/CIFS<\/strong> Todos por h\u00e1bito os escrevem pr\u00f3ximos, embora nem todos se lembrem de que CIFS (Common Internet File System) \u00e9 apenas uma vers\u00e3o privada do SMB (Server Message Block). Assim, n\u00e3o h\u00e1 nada de errado em generalizar esses conceitos. O Samba \u00e9 uma implementa\u00e7\u00e3o para Linux\/Unix, e l\u00e1 h\u00e1 suas particularidades, mas deixemos isso de lado. O importante aqui \u00e9: quando o Veeam pede para gravar algo por um caminho UNC (servidor\/diret\u00f3rio), o servidor usa uma hierarquia de drivers do sistema de arquivos, incluindo mup e mrxsmb, para gravar no compartilhamento. Portanto, esses drivers tamb\u00e9m gerar\u00e3o erros.<\/p>\n
De forma alguma pode-se prescindir de Winsock API<\/strong>. Se algo precisar ser feito pela rede, o VBR opera atrav\u00e9s da Windows Socket API, popularmente conhecida como Winsock. Portanto, se vemos no log a combina\u00e7\u00e3o IP:Port, \u00e9 isso que \u00e9. A documenta\u00e7\u00e3o oficial tem uma boa lista de poss\u00edveis erros<\/u><\/a><\/noindex>.<\/p>\n
A mencionada acima WMI<\/strong> (Windows Management Instrumentation) \u2014 \u00e9 uma API poderosa para gerenciar tudo e todos no mundo Windows. Por exemplo, ao trabalhar com Hyper-V, praticamente todas as solicita\u00e7\u00f5es ao host s\u00e3o feitas atrav\u00e9s dele. Em suma, \u00e9 uma ferramenta absolutamente indispens\u00e1vel e muito poderosa em suas capacidades. A ferramenta embutida WBEMtest.exe \u00e9 extremamente \u00fatil na tentativa de descobrir onde e o que deu errado.<\/p>\n
E o \u00faltimo da lista, mas de forma alguma o menos importante \u2014 VSS<\/strong> (Volume Shadow Storage). O tema \u00e9 t\u00e3o inesgot\u00e1vel e misterioso quanto a quantidade de documenta\u00e7\u00e3o que existe sobre ele. O Shadow Copy \u00e9 mais f\u00e1cil de entender como um tipo especial de snapshot, que na verdade \u00e9 o que ele \u00e9. Gra\u00e7as a isso, no VMware \u00e9 poss\u00edvel fazer backups consistentes de aplica\u00e7\u00f5es, enquanto no Hyper-V se pode fazer quase tudo. Tenho planos de escrever um artigo separado com um resumo sobre o VSS, mas por enquanto voc\u00ea pode tentar ler esta descri\u00e7\u00e3o<\/u><\/a><\/noindex>. Apenas tome cuidado, pois tentar entender o VSS de forma superficial pode levar a dores de cabe\u00e7a.<\/p>\n
Com isso, podemos parar por aqui. Considero que consegui explicar as quest\u00f5es mais b\u00e1sicas, ent\u00e3o no pr\u00f3ximo cap\u00edtulo j\u00e1 iremos analisar os logs. Mas, se voc\u00ea tiver perguntas, n\u00e3o hesite em deix\u00e1-las nos coment\u00e1rios.<\/p>\n<\/p>\n
Fonte: 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\udd47De onde v\u00eam os logs? Mergulho nos Logs do Veeam | ProHoster","description":"Continuamos nossa imers\u00e3o no fascinante mundo do adivinha\u00e7\u00e3o...","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}