{"id":84809,"date":"2020-06-11T01:42:41","date_gmt":"2020-06-10T23:42:41","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10"},"modified":"2020-06-11T01:42:41","modified_gmt":"2020-06-10T23:42:41","slug":"chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","title":{"rendered":"O que mudou no Capacity Tier quando a Veeam passou a ser a v10","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>O Capacity Tier (ou como o chamamos internamente no Veeam \u2014 captier) surgiu ainda na \u00e9poca do Veeam Backup and Replication 9.5 Update 4 com o nome de Archive Tier. A ideia por tr\u00e1s dele \u00e9 permitir a movimenta\u00e7\u00e3o de backups que ficaram fora da chamada janela de restaura\u00e7\u00e3o operacional para armazenamentos de objetos. Isso ajudou a liberar espa\u00e7o em disco para os usu\u00e1rios que tinham pouco espa\u00e7o dispon\u00edvel. Essa op\u00e7\u00e3o \u00e9 chamada de Move Mode.<\/p>\n<p>Para realizar essa a\u00e7\u00e3o simples (como parece), era necess\u00e1rio observar duas condi\u00e7\u00f5es: todos os pontos do backup em movimento devem estar fora da janela de restaura\u00e7\u00e3o operacional mencionada, que \u00e9 definida explicitamente na interface do usu\u00e1rio. E a segunda: a cadeia deve estar em um chamado \"formato selado\" (sealed backup chain ou Inactive Backup Chain). Ou seja, ao longo do tempo, n\u00e3o ocorrem altera\u00e7\u00f5es nessa cadeia.<\/p>\n<p>Mas no VBR v10, a concep\u00e7\u00e3o foi complementada com novas funcionalidades \u2014 surgiram o Copy Mode, o Sealed Mode e uma coisa com um nome complicado chamado Immutability.<\/p>\n<p>\u00c9 sobre essas coisas fascinantes que iremos falar hoje. Primeiro, sobre como funcionava no VBR9.5u4, e depois sobre as mudan\u00e7as na d\u00e9cima vers\u00e3o.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/954adcc5592fe2a7ea64ec24b06ecc91.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE que os defensores da linguagem pura me perdoem, mas muitos termos s\u00e3o imposs\u00edveis de traduzir.<br \/>\nEnt\u00e3o aqui haver\u00e1 uma abund\u00e2ncia de anglicismos.<br \/>\nE muitas anima\u00e7\u00f5es. <br \/>\nE imagens.<\/p>\n<ul>\n<li>Sem o menor arrependimento. Autor do artigo.<\/li>\n<\/ul>\n<p>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h1>Como foi<\/h1>\n<p>\nEnt\u00e3o, vamos come\u00e7ar com a an\u00e1lise da janela de restaura\u00e7\u00e3o operacional e do backup selado (ou como s\u00e3o chamados na documenta\u00e7\u00e3o, Inactive Backup Chain). Sem entender isso, n\u00e3o ser\u00e1 poss\u00edvel explicar mais adiante.<\/p>\n<p>Como podemos ver na imagem, temos uma cadeia de backup com blocos de dados, que est\u00e1 localizada no reposit\u00f3rio Performance tier SOBR, ao qual o Capacity Tier est\u00e1 conectado. Nossa janela de backup operacional \u00e9 de tr\u00eas dias.<\/p>\n<p>Consequentemente, o .vbk criado na segunda-feira sela a cadeia anterior, cuja janela est\u00e1 definida em tr\u00eas dias. E, portanto, podemos tranquilamente come\u00e7ar a levar para o capacity tier tudo que for mais antigo do que esses tr\u00eas dias.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/430f31d181bb79c2bd6001011511e3f9.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMas o que exatamente era entendido por uma cadeia selada e o que poderia ser enviado para o capacity tier na update 4?<\/p>\n<p>Para o Forward Incremental, o sinal de selagem da cadeia \u00e9 a cria\u00e7\u00e3o de um novo full backup. E n\u00e3o importa como esse full \u00e9 obtido: tanto o synthetic full quanto o active full s\u00e3o considerados backups completos.<\/p>\n<p>No caso do Reverse, s\u00e3o todos os arquivos que n\u00e3o entram na janela operacional. <\/p>\n<p>No caso do Forward increment com rollbacks, todos os rollbacks e .vbk s\u00e3o considerados, se houver outro .vbk no extente de desempenho.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/4cb6f168862acabadbdab771cc48fe7f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAgora vamos considerar a op\u00e7\u00e3o de trabalhar com cadeias de Backup Copy. Aqui, apenas os que se enquadravam na reten\u00e7\u00e3o GFS eram mantidos. Porque tudo armazenado nas cadeias de backup copy mais recentes pode ser de alguma forma alterado.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/4c263058110b7c502501f01940977f1a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAgora vamos dar uma olhada sob o cap\u00f4. L\u00e1 ocorre um processo chamado desidrata\u00e7\u00e3o \u2014 a \u043e\u0441\u0442\u0430\u0432a\u00e7\u00e3o de espa\u00e7os vazios dos arquivos de backup no extente e a transfer\u00eancia de blocos desses arquivos para o armazenamento de capacidade. Para otimizar esse processo, utiliza-se o chamado \u00edndice de desidrata\u00e7\u00e3o, que permite n\u00e3o copiar blocos que j\u00e1 foram copiados para o armazenamento de capacidade. <\/p>\n<p>Vamos ver como isso funciona com um exemplo: suponha que temos um .vbk que saiu da janela operacional e faz parte de uma cadeia selada. Isso significa que temos total direito de transferi-lo para o armazenamento de capacidade. No momento da transfer\u00eancia, um arquivo de metadados \u00e9 criado no armazenamento de capacidade, e os blocos do arquivo que est\u00e1 sendo transferido. No arquivo de metadados, no n\u00edvel de refer\u00eancias, \u00e9 descrito de quais blocos nosso arquivo \u00e9 composto. No caso da imagem, nosso primeiro arquivo consiste nos blocos a, b, c e as refer\u00eancias a esses blocos est\u00e3o nos metadados. Quando temos um segundo arquivo .vbk, pronto para a transfer\u00eancia e composto pelos blocos a, b e d, ao analisarmos o \u00edndice de desidrata\u00e7\u00e3o, entendemos que precisamos transferir apenas o bloco d. E seu arquivo de metadados conter\u00e1 refer\u00eancias aos dois blocos anteriores e um novo.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/5c502030b8727ecd85c5229df1761c85.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAssim, o processo de preenchimento reverso desses espa\u00e7os vazios com dados \u00e9 chamado de reidrata\u00e7\u00e3o. Aqui, um \u00edndice de reidrata\u00e7\u00e3o pr\u00f3prio \u00e9 utilizado, baseado no arquivo .vbk mais antigo no extente de desempenho local. Ou seja, se o usu\u00e1rio deseja restaurar um arquivo do armazenamento de capacidade, primeiro criamos um \u00edndice dos blocos do backup completo mais antigo e transferimos do armazenamento de capacidade apenas os blocos que faltam. No caso apresentado na imagem, para reidratar o FullBackup1.vbk de acordo com o \u00edndice de reidrata\u00e7\u00e3o, s\u00f3 nos falta o bloco C, que pegamos do armazenamento de capacidade. Se o armazenamento de capacidade for um armazenamento de objetos em nuvem, isso permite economizar enormes quantias de dinheiro.<\/p>\n<p>Pode parecer que essa tecnologia \u00e9 id\u00eantica \u00e0 utilizada em WAN Accelerators, mas isso \u00e9 apenas uma impress\u00e3o. Nos aceleradores, a deduplica\u00e7\u00e3o \u00e9 global, enquanto aqui usamos a deduplica\u00e7\u00e3o local dentro de cada arquivo a um determinado offset. Isso se deve \u00e0 diferen\u00e7a nas tarefas a serem resolvidas: aqui precisamos copiar grandes arquivos de backups completos, e, de acordo com nossas pesquisas, mesmo que entre eles haja um longo intervalo de tempo, esse algoritmo de deduplica\u00e7\u00e3o oferece os melhores resultados.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/1db1a696e289187ae02bd84d9edd6f66.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nMas mais \u00edndices para o deus dos \u00edndices! H\u00e1 tamb\u00e9m um \u00edndice para recupera\u00e7\u00e3o de dados! Quando iniciamos a recupera\u00e7\u00e3o de uma m\u00e1quina localizada no capacity tier, leremos apenas os blocos de dados \u00fanicos que n\u00e3o est\u00e3o no performance tier.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/257593c39e63bfb6f7e13d228bcebbae.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h1>Como se tornou<\/h1>\n<p>\nCom isso, encerramos a parte introdut\u00f3ria. \u00c9 bastante detalhada, mas, como mencionado anteriormente, sem esses detalhes n\u00e3o seria poss\u00edvel explicar como funcionam as novas funcionalidades. Ent\u00e3o, sem mais pre\u00e2mbulos, vamos \u00e0 primeira.<\/p>\n<h3>Modo de c\u00f3pia<\/h3>\n<p>\nBaseia-se em grande parte em tecnologias existentes, mas traz uma l\u00f3gica de uso completamente diferente.\u00a0<\/p>\n<p>O objetivo deste modo \u00e9 garantir que todos os dados localizados no extento local tenham uma c\u00f3pia no capacity tier.<\/p>\n<p>Se compararmos diretamente os modos Move e Copy, teremos o seguinte:<\/p>\n<ul>\n<li>Voc\u00ea pode mover apenas uma cadeia selada. No caso do modo de c\u00f3pia, tudo \u00e9 transportado, independentemente do que acontece no trabalho de backup.<\/li>\n<li>A movimenta\u00e7\u00e3o \u00e9 acionada quando os arquivos excedem os limites da janela operacional de backup, enquanto a c\u00f3pia \u00e9 acionada assim que um arquivo de backup aparece.<\/li>\n<li>O rastreamento de novos dados para c\u00f3pia ocorre continuamente, enquanto a movimenta\u00e7\u00e3o \u00e9 verificada a cada 4 horas.<\/li>\n<\/ul>\n<p>\nPara considerar o novo modo, sugiro come\u00e7armos por exemplos simples e avan\u00e7armos para os complexos.<\/p>\n<p>No caso mais trivial, simplesmente surgem novos arquivos com incrementos e n\u00f3s os copiamos para o capacity tier. Independentemente do modo utilizado no trabalho de backup, se pertence ou n\u00e3o \u00e0 parte selada da cadeia, ou se a nossa janela operacional expirou. Apenas pegamos e copiamos.<\/p>\n<p>O processo por tr\u00e1s disso ainda \u00e9 a desidrata\u00e7\u00e3o conforme descrito acima. No modo de c\u00f3pia, ele tamb\u00e9m garante que n\u00e3o copiamos blocos que j\u00e1 est\u00e3o no nosso armazenamento. A \u00fanica diferen\u00e7a \u00e9 que, no modo de movimento, substitu\u00edmos arquivos reais por arquivos vazios, enquanto aqui n\u00e3o mexemos neles e deixamos tudo como est\u00e1. No restante, \u00e9 exatamente o mesmo \u00edndice de desidrata\u00e7\u00e3o que se esfor\u00e7a para economizar o seu dinheiro e tempo.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/b3a033f4a0d0cbce8cecee152660c67c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSurge a quest\u00e3o \u2014 se olharmos para a interface do usu\u00e1rio, h\u00e1 a possibilidade de escolher ambas as op\u00e7\u00f5es ao mesmo tempo. Como funcionar\u00e1 esse modo combinado?<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/12f658765a05e120dc5068920886edb5.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVamos entender.<\/p>\n<p>O in\u00edcio \u00e9 padr\u00e3o: cria-se um arquivo de backup e \u00e9 imediatamente copiado. Um incremento \u00e9 criado para ele e tamb\u00e9m copiado. Isso acontece at\u00e9 o momento em que percebemos que os arquivos sa\u00edram da nossa janela operacional e surgiu uma cadeia selada. Nesse momento, realizamos a opera\u00e7\u00e3o de desidrata\u00e7\u00e3o e substitu\u00edmos esses arquivos por arquivos vazios. Naturalmente, n\u00e3o copiamos nada novamente no n\u00edvel de capacidade.<\/p>\n<p>Toda essa l\u00f3gica fascinante \u00e9 controlada apenas por uma caixa de sele\u00e7\u00e3o na interface: Copy backups to object storage as soon as they are created.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/1a0e27c04428ebd48b13d8927a453d62.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>E qual a import\u00e2ncia desse modo de c\u00f3pia? <\/h3>\n<p>\nSeria melhor reformular a pergunta assim \u2014 de quais riscos nos protegemos com isso? Que problema ele nos ajuda a resolver?<\/p>\n<p>A resposta \u00e9 \u00f3bvia: claro que se trata de recupera\u00e7\u00e3o de dados. Se temos uma c\u00f3pia completa dos dados locais no armazenamento de objetos, n\u00e3o importa o que aconte\u00e7a com nosso ambiente de produ\u00e7\u00e3o, sempre podemos restaurar os dados dos arquivos localizados em um suposto Amazon.<\/p>\n<p>Portanto, vamos passar por poss\u00edveis cen\u00e1rios, do mais simples ao mais complexo.<\/p>\n<p>O problema mais simples que pode nos atingir \u00e9 a indisponibilidade de um dos arquivos na cadeia de backup.<\/p>\n<p>Uma hist\u00f3ria mais triste \u00e9 que um dos extents do nosso reposit\u00f3rio SOBR quebrou.<\/p>\n<p>Fica ainda pior quando todo o reposit\u00f3rio SOBR se torna indispon\u00edvel, mas o n\u00edvel de capacidade est\u00e1 funcionando.<br \/>\nE tudo fica muito mal quando o servidor de backup morre e seu primeiro desejo \u00e9 tentar correr at\u00e9 a fronteira canadense em dez minutos.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/868d71412901ed362956e1e2157ed895.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAgora, vamos analisar cada situa\u00e7\u00e3o separadamente.<\/p>\n<p>Quando perdemos um (ou at\u00e9 v\u00e1rios) arquivos de backup, podemos simplesmente iniciar o processo de nova verifica\u00e7\u00e3o do reposit\u00f3rio, e o arquivo perdido ser\u00e1 substitu\u00eddo por um arquivo vazio. E com o processo de reidrata\u00e7\u00e3o (sobre o qual falamos no in\u00edcio do artigo), o usu\u00e1rio poder\u00e1 baixar os dados do n\u00edvel de capacidade para o armazenamento local.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/5066a21cbd17565569891f8e23cac4fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAgora a situa\u00e7\u00e3o \u00e9 um pouco mais complicada. Suponha que nosso SOBR consista em dois extents, operando no modo Performance, o que significa que nossos .vbk e .vib est\u00e3o distribu\u00eddos de maneira bastante n\u00e3o uniforme entre eles. E, em algum momento, um dos extents se torna indispon\u00edvel, e o usu\u00e1rio precisa urgentemente restaurar a m\u00e1quina, parte dos dados da qual est\u00e1 precisamente nesse extent. <\/p>\n<p>O usu\u00e1rio inicia o assistente de recupera\u00e7\u00e3o, escolhe o ponto para o qual deseja restaurar, e o assistente, durante o processo, percebe que n\u00e3o possui todos os dados necess\u00e1rios para a recupera\u00e7\u00e3o localmente, e portanto, precisa baix\u00e1-los do n\u00edvel de capacidade. Nesse caso, os blocos que permaneceram no armazenamento local n\u00e3o ser\u00e3o baixados da nuvem. Gra\u00e7as ao \u00edndice de restaura\u00e7\u00e3o (sim, ele tamb\u00e9m foi mencionado no in\u00edcio do artigo).<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/88b38ddf122d20a3e41a0afcba544749.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUma variante desse caso \u00e9 quando todo o reposit\u00f3rio SOBR se torna indispon\u00edvel. Nesse caso, n\u00e3o temos nada para copiar dos armazenamentos locais, e todos os blocos s\u00e3o baixados da nuvem.<\/p>\n<p>E a situa\u00e7\u00e3o mais interessante \u2014 o servidor de backup morreu. Aqui h\u00e1 duas op\u00e7\u00f5es: o administrador fez um bom trabalho e configurou backups de configura\u00e7\u00e3o, ou o administrador se comportou como um vil\u00e3o e n\u00e3o fez um backup de configura\u00e7\u00e3o.<\/p>\n<p>No primeiro caso, ser\u00e1 suficiente para ele simplesmente implantar uma instala\u00e7\u00e3o limpa do VBR em algum lugar e restaurar seu banco de dados a partir do backup usando as ferramentas padr\u00e3o. Ap\u00f3s a conclus\u00e3o desse processo, tudo voltar\u00e1 ao normal. Ou ser\u00e1 restaurado de acordo com um dos cen\u00e1rios mencionados acima.<\/p>\n<p>Mas se o admin \u00e9 seu pr\u00f3prio inimigo, ou se o backup da configura\u00e7\u00e3o tamb\u00e9m enfrentou uma s\u00e9ria falha, mesmo aqui n\u00e3o vamos deix\u00e1-lo \u00e0 merc\u00ea do destino. Para esse caso, introduzimos um novo procedimento chamado Import Object Storage. Ele permite pular o processo de recria\u00e7\u00e3o manual do reposit\u00f3rio SOBR e a anexa\u00e7\u00e3o de um disco de capacidade a ele, seguida de um novo escaneamento, e simplesmente adicionar o storage de objetos na interface do Veeam e iniciar o procedimento Import Storage Repository. A \u00fanica coisa que pode se interpor entre voc\u00ea e seus backups \u00e9 um pedido para inserir a senha, caso seus backups tenham sido criptografados.<\/p>\n<p>Com isso, sobre o Modo de C\u00f3pia, \u00e9 tudo e passamos para<\/p>\n<h3>Modo Selado<\/h3>\n<p>\nA ideia principal \u00e9 que novos backups n\u00e3o podem ser criados no volume selecionado do reposit\u00f3rio SOBR. At\u00e9 a vers\u00e3o 10, t\u00ednhamos apenas o Modo de Manuten\u00e7\u00e3o, onde qualquer opera\u00e7\u00e3o no reposit\u00f3rio era completamente proibida. Uma esp\u00e9cie de modo hardcore para retirar o storage de opera\u00e7\u00e3o, onde apenas o bot\u00e3o Evacuar estava dispon\u00edvel, movendo os backups para outro volume de forma \u00fanica.<\/p>\n<p>O modo Selado \u00e9 uma vers\u00e3o \u201csuave\u201d: proibimos a cria\u00e7\u00e3o de novos backups e removemos gradualmente os antigos de acordo com a reten\u00e7\u00e3o escolhida, mas no processo n\u00e3o perdemos a capacidade de restaurar a partir dos pontos armazenados. Uma ferramenta muito \u00fatil, quando o tempo de vida do hardware est\u00e1 se esgotando e precisa ser substitu\u00eddo, ou simplesmente precisa ser liberado para algo mais importante, e n\u00e3o h\u00e1 como mudar tudo de uma vez. Ou n\u00e3o \u00e9 poss\u00edvel deletar. <\/p>\n<p>Portanto, o princ\u00edpio de opera\u00e7\u00e3o \u00e9 bastante simples: \u00e9 necess\u00e1rio proibir todas as opera\u00e7\u00f5es de grava\u00e7\u00e3o (aparecimento de novos dados), mantendo leitura (restaura\u00e7\u00f5es) e exclus\u00e3o (reten\u00e7\u00e3o).<\/p>\n<p>Ambos os modos podem ser usados simultaneamente, mas deve-se considerar que o Modo de Manuten\u00e7\u00e3o tem prioridade.<\/p>\n<p>Como exemplo, vamos considerar um SOBR composto por dois volumes. Suponha que, nos primeiros quatro dias, realizamos backups no modo Forward Forever Incremental, e depois selamos o volume. Isso leva \u00e0 cria\u00e7\u00e3o de um novo full active no segundo volume dispon\u00edvel. Se nossa reten\u00e7\u00e3o \u00e9 de quatro, quando toda a cadeia no volume selado ultrapassa sua validade, ela \u00e9 apagada sem remorso.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/5476ebcf9b57eeb6c0326499ac42763f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nExistem situa\u00e7\u00f5es em que a exclus\u00e3o ocorre mais cedo. Por exemplo, isso acontece com o Forward incremental com fulls peri\u00f3dicos. Se nos primeiros dois dias fizemos backups completos, e na quinta-feira decidimos fechar o reposit\u00f3rio, ent\u00e3o na sexta-feira, quando um novo full for criado, o arquivo de segunda-feira ser\u00e1 exclu\u00eddo, pois n\u00e3o h\u00e1 depend\u00eancias at\u00e9 esse ponto. E esse ponto n\u00e3o depende de ningu\u00e9m. Depois disso, aguardamos a cria\u00e7\u00e3o de quatro pontos no extent dispon\u00edvel e removemos os tr\u00eas restantes, que n\u00e3o podem ser exclu\u00eddos independentemente uns dos outros.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/c6cc452f98336803731163dfd794f828.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs coisas s\u00e3o mais simples com o Reverse Incremental. Nele, os pontos mais antigos n\u00e3o dependem de nada e podem ser exclu\u00eddos sem problemas. Portanto, assim que um novo .vbk \u00e9 criado em um novo extent, os antigos .vrb s\u00e3o removidos um a um.<\/p>\n<p>A prop\u00f3sito, por que criamos um novo .vbk cada vez: se n\u00e3o o fizermos e continuarmos a antiga cadeia de incrementos, o antigo .vbk ficaria preso por um tempo indeterminado em qualquer modo, impedindo a sua exclus\u00e3o. Assim, foi decidido que assim que o extent \u00e9 fechado, criamos um backup completo em um extent livre.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/3757fae46ad76d64cdddfb941309d557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nAs coisas s\u00e3o mais complicadas com o capacity tier. <\/p>\n<p>Primeiro, vamos considerar o modo copy. Suponha que criamos backups ativamente por quatro dias e depois o capacity tier foi fechado. N\u00e3o exclu\u00edmos nada, mas pacientemente aguardamos a reten\u00e7\u00e3o, ap\u00f3s o que exclu\u00edmos os dados do capacity tier.<\/p>\n<p>Acontece algo semelhante no modo move \u2014 aguardamos a reten\u00e7\u00e3o, exclu\u00edmos o antigo no armazenamento local e removemos o que est\u00e1 armazenado no object storage.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/391d3b231c7de5da1d13e19c31bd6b7c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUm exemplo interessante \u00e9 o Forever forward incremental. Definimos a reten\u00e7\u00e3o em tr\u00eas pontos e come\u00e7amos a fazer backups na segunda-feira, que s\u00e3o corretamente copiados para a nuvem. Ap\u00f3s o fechamento do armazenamento, os backups continuam a ser criados, mantendo tr\u00eas pontos, mas os dados armazenados no capacity tier permanecem dependentes e n\u00e3o podem ser exclu\u00eddos. Portanto, aguardamos at\u00e9 quinta-feira, quando nosso .vbk ultrapassa a reten\u00e7\u00e3o, e somente ent\u00e3o removemos toda a cadeia salva.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/617a42452060210b58148e1fe942a540.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE uma pequena ressalva: todos os exemplos aqui foram mostrados com uma \u00fanica m\u00e1quina. Se voc\u00ea tiver v\u00e1rias em backup, a reten\u00e7\u00e3o delas ser\u00e1 diferente dependendo de ter sido feito um Active Full ou n\u00e3o.<\/p>\n<p>\u00c9 basicamente isso. Ent\u00e3o, vamos para o recurso mais hardcore \u2014 <\/p>\n<h3>Imutabilidade <\/h3>\n<p>\nAssim como nos pontos anteriores, vamos primeiro falar sobre qual problema essa fun\u00e7\u00e3o resolve. Assim que transferimos nossos backups para armazenamento, surge o desejo urgente de garantir sua integridade, ou seja, proibir fisicamente sua exclus\u00e3o e qualquer modifica\u00e7\u00e3o durante o per\u00edodo definido de reten\u00e7\u00e3o. Isso inclui os administradores, mesmo com suas contas de root. Isso protege os backups contra corrup\u00e7\u00e3o acidental ou intencional. Quem trabalha com AWS pode ter encontrado uma fun\u00e7\u00e3o semelhante chamada Object Lock.<\/p>\n<p>Agora vamos considerar o modo de forma geral e depois nos aprofundaremos nos detalhes. No nosso exemplo, a Imutabilidade ser\u00e1 ativada para nosso tier de capacidade com uma reten\u00e7\u00e3o de quatro dias. E o backup ter\u00e1 o modo Copia ativado.<\/p>\n<p>A Imutabilidade n\u00e3o interage com a reten\u00e7\u00e3o geral. Por exemplo, ela n\u00e3o adiciona pontos adicionais ou algo assim. Simplesmente, durante quatro dias, a pessoa n\u00e3o pode excluir os arquivos de backup. Se um backup for feito na segunda-feira, o arquivo s\u00f3 poder\u00e1 ser exclu\u00eddo na sexta-feira.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/131e50058c1a015ec78089ed4d038bfc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nTodos os conceitos previamente explicados de desidrata\u00e7\u00e3o, \u00edndices e metadados continuam a funcionar exatamente da mesma forma. Mas com uma condi\u00e7\u00e3o \u2014 o bloqueio \u00e9 aplicado n\u00e3o apenas aos dados, mas tamb\u00e9m aos metadados. Isso \u00e9 feito caso um malicioso atacante decida apagar nossa base de metadados e para evitar que os blocos de dados se tornem uma pilha bin\u00e1ria in\u00fatil.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/edfe5c04a082594cf5d67f4bafeccb3a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE agora chegou o momento perfeito para explicar nossa tecnologia de gera\u00e7\u00e3o de blocos. Ou block generation. Para isso, vamos considerar a situa\u00e7\u00e3o que levou ao seu surgimento.<\/p>\n<p>Vamos considerar uma linha do tempo de seis dias e marcar em baixo o tempo esperado para a expira\u00e7\u00e3o da immutability. No primeiro dia, criamos um arquivo que consiste no bloco a e seus metadados. Se a immutability estiver definida para tr\u00eas dias, \u00e9 l\u00f3gico supor que no quarto dia os dados ser\u00e3o desbloqueados e removidos. No segundo dia, adicionaremos um novo file2, composto pelo bloco b com as mesmas configura\u00e7\u00f5es. O bloco a ainda deve ser removido no quarto dia. Mas no terceiro dia acontece algo terr\u00edvel \u2014 \u00e9 criado um arquivo File3, que consiste em um novo bloco d e uma refer\u00eancia ao antigo bloco a. Isso significa que para o bloco a, seu estado de immutability deve ser redefinido para um novo per\u00edodo, que \u00e9 estendido at\u00e9 o sexto dia. E aqui surge um problema \u2014 em backups reais, tais blocos geram uma quantidade enorme. E para estender o per\u00edodo de immutability, \u00e9 necess\u00e1rio fazer uma quantidade enorme de solicita\u00e7\u00f5es a cada vez. E na pr\u00e1tica, isso ser\u00e1 um processo quase infinito di\u00e1rio, pois com grande probabilidade a cada c\u00f3pia encontraremos enormes pilhas de blocos desduplicados. E o que significa uma grande quantidade de solicita\u00e7\u00f5es para provedores de armazenamento de objetos? Exatamente! Uma conta enorme no final do m\u00eas.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/ce9c5d0da67f99019b00c4a666302fee.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nE para n\u00e3o acabar cobrando uma fortuna dos nossos valiosos clientes por motivos triviais, foi inventado um mecanismo de gera\u00e7\u00e3o de blocos. Este \u00e9 um per\u00edodo adicional que adicionamos ao per\u00edodo de immutability estabelecido. No exemplo abaixo, esse per\u00edodo \u00e9 igual a dois dias. Mas isso \u00e9 apenas um exemplo. Na realidade, \u00e9 usada uma f\u00f3rmula pr\u00f3pria que fornece cerca de dez dias adicionais em um bloqueio mensal. <\/p>\n<p>Vamos continuar a analisar a mesma situa\u00e7\u00e3o, mas j\u00e1 com a gera\u00e7\u00e3o de blocos. No primeiro dia, criamos o file1 a partir do bloco a e dos metadados. A contagem do per\u00edodo de gera\u00e7\u00f5es e a imutabilidade significa que a possibilidade de excluir o arquivo ser\u00e1 no sexto dia. Se no segundo dia criarmos o File2, que consiste no bloco b e uma refer\u00eancia ao bloco a, a data prevista para a exclus\u00e3o permanece a mesma. Ela continua marcada para o sexto dia. Assim, estamos tentando economizar dinheiro no n\u00famero de solicita\u00e7\u00f5es. A \u00fanica situa\u00e7\u00e3o em que o prazo pode ser alterado \u00e9 se o per\u00edodo de gera\u00e7\u00e3o expirar. Ou seja, se no terceiro dia o novo File3 contiver uma refer\u00eancia ao bloco a, a gera\u00e7\u00e3o 2 ser\u00e1 adicionada, pois a Gen1 j\u00e1 expirou. A data esperada para a exclus\u00e3o do bloco a ser\u00e1 antecipada para o oitavo dia. Isso nos permite reduzir drasticamente o n\u00famero de solicita\u00e7\u00f5es para prorrogar a vida \u00fatil de blocos deduplicados, economizando muito dinheiro para os clientes.<\/p>\n<p><img decoding=\"async\" alt=\"O que mudou no Capacity Tier quando a Veeam passou a ser a v10\" src=\"\/wp-content\/uploads\/2020\/06\/2056d0c15e4e7fcdd67a56b11f973119.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA pr\u00f3pria tecnologia est\u00e1 dispon\u00edvel para os usu\u00e1rios S3 e hardware compat\u00edvel com S3, cujos fabricantes garantem que sua implementa\u00e7\u00e3o n\u00e3o difere da da Amazon. Daqui vem a resposta para a pergunta leg\u00edtima sobre por que o Azure n\u00e3o \u00e9 suportado \u2014 eles t\u00eam um recurso semelhante, mas ele funciona no n\u00edvel de cont\u00eaineres e n\u00e3o de objetos individuais. A prop\u00f3sito, na pr\u00f3pria Amazon, o Object Lock existe em dois modos: compliance e governance. No segundo caso, ainda existe a possibilidade de que o maior administrador de todos os tempos, apesar da prote\u00e7\u00e3o do Object Lock, exclua os dados. No caso de compliance, tudo fica absolutamente fixado e os backups n\u00e3o podem ser exclu\u00eddos por ningu\u00e9m. Mesmo pelos administradores da Amazon (segundo suas declara\u00e7\u00f5es oficiais). N\u00f3s suportamos exatamente esse modo.<\/p>\n<p>\nE, tradicionalmente, algumas links \u00fateis:<\/p>\n<ul>\n<li>Sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/block_generation.html?ver=100\">Gera\u00e7\u00e3o de Blocos<\/a><\/noindex> em todos os detalhes.<\/li>\n<li>Todas as informa\u00e7\u00f5es sobre <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/overview.html?ver=100\">Veeam Backup &amp; Replication 10<\/a><\/noindex> da melhor forma<\/li>\n<li>A <noindex><a rel=\"nofollow\" href=\"https:\/\/helpcenter.veeam.com\/docs\/backup\/vsphere\/capacity_tier.html?ver=100\">Capacity Tier<\/a><\/noindex> em detalhes<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/veeam\/blog\/505818\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier. \u0417\u0430\u043b\u043e\u0436\u0435\u043d\u043d\u0430\u044f \u0432 \u043d\u0435\u0433\u043e \u0438\u0434\u0435\u044f \u2014 \u044d\u0442\u043e \u0434\u0430\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u043f\u0435\u0440\u0435\u043c\u0435\u0449\u0430\u0442\u044c \u0431\u0435\u043a\u0430\u043f\u044b, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0432\u044b\u043f\u0430\u043b\u0438 \u0438\u0437 \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u043e\u0433\u043e operational restore window, \u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u044b\u0435 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430. \u042d\u0442\u043e \u043f\u043e\u043c\u043e\u0433\u0430\u043b\u043e \u0440\u0430\u0441\u0447\u0438\u0449\u0430\u0442\u044c \u0434\u0438\u0441\u043a\u043e\u0432\u043e\u0435 \u043f\u0440\u043e\u0441\u0442\u0440\u0430\u043d\u0441\u0442\u0432\u043e \u0442\u0435\u043c [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84810,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84809","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-06-10T23:42:41+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47 O que mudou no Capacity Tier quando o Veeam se tornou v10 | ProHoster","description":"O Capacity Tier (ou como chamamos internamente no Veeam \u2014 cap-tier) surgiu na \u00e9poca do Veeam Backup and Replication 9.5 Update 4 sob o nome Archive Tier.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","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\u0427\u0442\u043e \u0438\u0437\u043c\u0435\u043d\u0438\u043b\u043e\u0441\u044c \u0432 Capacity Tier, \u043a\u043e\u0433\u0434\u0430 Veeam \u0441\u0442\u0430\u043b v10 | ProHoster","og:description":"Capacity Tier (\u0438\u043b\u0438 \u043a\u0430\u043a \u043c\u044b \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0435\u0433\u043e \u0443 \u0441\u0435\u0431\u044f \u0432\u043d\u0443\u0442\u0440\u0438 \u0432\u0438\u043c\u0430 \u2014 \u043a\u0430\u043f\u0442\u0438\u0440) \u043f\u043e\u044f\u0432\u0438\u043b\u0441\u044f \u0435\u0449\u0451 \u0432\u043e \u0432\u0440\u0435\u043c\u0435\u043d\u0430 Veeam Backup and Replication 9.5 Update 4 \u043f\u043e\u0434 \u0438\u043c\u0435\u043d\u0435\u043c Archive Tier.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/chto-izmenilos-v-capacity-tier-kogda-veeam-stal-v10","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-06-10T23:42:41+00:00","article:modified_time":"2020-06-10T23:42:41+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84809","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 14:49:54","updated":"2022-09-29 08:38:47","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\/84809","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=84809"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/84809\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/84810"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=84809"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=84809"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=84809"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}