O Capacity Tier (ou como o chamamos internamente no Veeam — captier) surgiu ainda na época do Veeam Backup and Replication 9.5 Update 4 com o nome de Archive Tier. A ideia por trás dele é permitir a movimentação de backups que ficaram fora da chamada janela de restauração operacional para armazenamentos de objetos. Isso ajudou a liberar espaço em disco para os usuários que tinham pouco espaço disponível. Essa opção é chamada de Move Mode.

Para realizar essa ação simples (como parece), era necessário observar duas condições: todos os pontos do backup em movimento devem estar fora da janela de restauração operacional mencionada, que é definida explicitamente na interface do usuário. 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ão ocorrem alterações nessa cadeia.

Mas no VBR v10, a concepção foi complementada com novas funcionalidades — surgiram o Copy Mode, o Sealed Mode e uma coisa com um nome complicado chamado Immutability.

É sobre essas coisas fascinantes que iremos falar hoje. Primeiro, sobre como funcionava no VBR9.5u4, e depois sobre as mudanças na décima versão.

E que os defensores da linguagem pura me perdoem, mas muitos termos são impossíveis de traduzir.
Então aqui haverá uma abundância de anglicismos.
E muitas animações.
E imagens.

Sem o menor arrependimento. Autor do artigo.

Como foi

Então, vamos começar com a análise da janela de restauração operacional e do backup selado (ou como são chamados na documentação, Inactive Backup Chain). Sem entender isso, não será possível explicar mais adiante.

Como podemos ver na imagem, temos uma cadeia de backup com blocos de dados, que está localizada no repositório Performance tier SOBR, ao qual o Capacity Tier está conectado. Nossa janela de backup operacional é de três dias.

Consequentemente, o .vbk criado na segunda-feira sela a cadeia anterior, cuja janela está definida em três dias. E, portanto, podemos tranquilamente começar a levar para o capacity tier tudo que for mais antigo do que esses três dias.

Mas o que exatamente era entendido por uma cadeia selada e o que poderia ser enviado para o capacity tier na update 4?

Para o Forward Incremental, o sinal de selagem da cadeia é a criação de um novo full backup. E não importa como esse full é obtido: tanto o synthetic full quanto o active full são considerados backups completos.

No caso do Reverse, são todos os arquivos que não entram na janela operacional.

No caso do Forward increment com rollbacks, todos os rollbacks e .vbk são considerados, se houver outro .vbk no extente de desempenho.

Agora vamos considerar a opção de trabalhar com cadeias de Backup Copy. Aqui, apenas os que se enquadravam na retenção GFS eram mantidos. Porque tudo armazenado nas cadeias de backup copy mais recentes pode ser de alguma forma alterado.

Agora vamos dar uma olhada sob o capô. Lá ocorre um processo chamado desidratação — a оставação de espaços vazios dos arquivos de backup no extente e a transferência de blocos desses arquivos para o armazenamento de capacidade. Para otimizar esse processo, utiliza-se o chamado índice de desidratação, que permite não copiar blocos que já foram copiados para o armazenamento de capacidade.

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ência, um arquivo de metadados é criado no armazenamento de capacidade, e os blocos do arquivo que está sendo transferido. No arquivo de metadados, no nível de referências, é descrito de quais blocos nosso arquivo é composto. No caso da imagem, nosso primeiro arquivo consiste nos blocos a, b, c e as referências a esses blocos estão nos metadados. Quando temos um segundo arquivo .vbk, pronto para a transferência e composto pelos blocos a, b e d, ao analisarmos o índice de desidratação, entendemos que precisamos transferir apenas o bloco d. E seu arquivo de metadados conterá referências aos dois blocos anteriores e um novo.

Assim, o processo de preenchimento reverso desses espaços vazios com dados é chamado de reidratação. Aqui, um índice de reidratação próprio é utilizado, baseado no arquivo .vbk mais antigo no extente de desempenho local. Ou seja, se o usuário deseja restaurar um arquivo do armazenamento de capacidade, primeiro criamos um índice 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 índice de reidratação, só 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.

Pode parecer que essa tecnologia é idêntica à utilizada em WAN Accelerators, mas isso é apenas uma impressão. Nos aceleradores, a deduplicação é global, enquanto aqui usamos a deduplicação local dentro de cada arquivo a um determinado offset. Isso se deve à diferença 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ção oferece os melhores resultados.

Mas mais índices para o deus dos índices! Há também um índice para recuperação de dados! Quando iniciamos a recuperação de uma máquina localizada no capacity tier, leremos apenas os blocos de dados únicos que não estão no performance tier.

Como se tornou

Com isso, encerramos a parte introdutória. É bastante detalhada, mas, como mencionado anteriormente, sem esses detalhes não seria possível explicar como funcionam as novas funcionalidades. Então, sem mais preâmbulos, vamos à primeira.

Modo de cópia

Baseia-se em grande parte em tecnologias existentes, mas traz uma lógica de uso completamente diferente.

O objetivo deste modo é garantir que todos os dados localizados no extento local tenham uma cópia no capacity tier.

Se compararmos diretamente os modos Move e Copy, teremos o seguinte:

Você pode mover apenas uma cadeia selada. No caso do modo de cópia, tudo é transportado, independentemente do que acontece no trabalho de backup.
A movimentação é acionada quando os arquivos excedem os limites da janela operacional de backup, enquanto a cópia é acionada assim que um arquivo de backup aparece.
O rastreamento de novos dados para cópia ocorre continuamente, enquanto a movimentação é verificada a cada 4 horas.

Para considerar o novo modo, sugiro começarmos por exemplos simples e avançarmos para os complexos.

No caso mais trivial, simplesmente surgem novos arquivos com incrementos e nós os copiamos para o capacity tier. Independentemente do modo utilizado no trabalho de backup, se pertence ou não à parte selada da cadeia, ou se a nossa janela operacional expirou. Apenas pegamos e copiamos.

O processo por trás disso ainda é a desidratação conforme descrito acima. No modo de cópia, ele também garante que não copiamos blocos que já estão no nosso armazenamento. A única diferença é que, no modo de movimento, substituímos arquivos reais por arquivos vazios, enquanto aqui não mexemos neles e deixamos tudo como está. No restante, é exatamente o mesmo índice de desidratação que se esforça para economizar o seu dinheiro e tempo.

Surge a questão — se olharmos para a interface do usuário, há a possibilidade de escolher ambas as opções ao mesmo tempo. Como funcionará esse modo combinado?

Vamos entender.

O início é padrão: cria-se um arquivo de backup e é imediatamente copiado. Um incremento é criado para ele e também copiado. Isso acontece até o momento em que percebemos que os arquivos saíram da nossa janela operacional e surgiu uma cadeia selada. Nesse momento, realizamos a operação de desidratação e substituímos esses arquivos por arquivos vazios. Naturalmente, não copiamos nada novamente no nível de capacidade.

Toda essa lógica fascinante é controlada apenas por uma caixa de seleção na interface: Copy backups to object storage as soon as they are created.

E qual a importância desse modo de cópia?

Seria melhor reformular a pergunta assim — de quais riscos nos protegemos com isso? Que problema ele nos ajuda a resolver?

A resposta é óbvia: claro que se trata de recuperação de dados. Se temos uma cópia completa dos dados locais no armazenamento de objetos, não importa o que aconteça com nosso ambiente de produção, sempre podemos restaurar os dados dos arquivos localizados em um suposto Amazon.

Portanto, vamos passar por possíveis cenários, do mais simples ao mais complexo.

O problema mais simples que pode nos atingir é a indisponibilidade de um dos arquivos na cadeia de backup.

Uma história mais triste é que um dos extents do nosso repositório SOBR quebrou.

Fica ainda pior quando todo o repositório SOBR se torna indisponível, mas o nível de capacidade está funcionando.
E tudo fica muito mal quando o servidor de backup morre e seu primeiro desejo é tentar correr até a fronteira canadense em dez minutos.

Agora, vamos analisar cada situação separadamente.

Quando perdemos um (ou até vários) arquivos de backup, podemos simplesmente iniciar o processo de nova verificação do repositório, e o arquivo perdido será substituído por um arquivo vazio. E com o processo de reidratação (sobre o qual falamos no início do artigo), o usuário poderá baixar os dados do nível de capacidade para o armazenamento local.

Agora a situação é 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ão distribuídos de maneira bastante não uniforme entre eles. E, em algum momento, um dos extents se torna indisponível, e o usuário precisa urgentemente restaurar a máquina, parte dos dados da qual está precisamente nesse extent.

O usuário inicia o assistente de recuperação, escolhe o ponto para o qual deseja restaurar, e o assistente, durante o processo, percebe que não possui todos os dados necessários para a recuperação localmente, e portanto, precisa baixá-los do nível de capacidade. Nesse caso, os blocos que permaneceram no armazenamento local não serão baixados da nuvem. Graças ao índice de restauração (sim, ele também foi mencionado no início do artigo).

Uma variante desse caso é quando todo o repositório SOBR se torna indisponível. Nesse caso, não temos nada para copiar dos armazenamentos locais, e todos os blocos são baixados da nuvem.

E a situação mais interessante — o servidor de backup morreu. Aqui há duas opções: o administrador fez um bom trabalho e configurou backups de configuração, ou o administrador se comportou como um vilão e não fez um backup de configuração.

No primeiro caso, será suficiente para ele simplesmente implantar uma instalação limpa do VBR em algum lugar e restaurar seu banco de dados a partir do backup usando as ferramentas padrão. Após a conclusão desse processo, tudo voltará ao normal. Ou será restaurado de acordo com um dos cenários mencionados acima.

Mas se o admin é seu próprio inimigo, ou se o backup da configuração também enfrentou uma séria falha, mesmo aqui não vamos deixá-lo à mercê do destino. Para esse caso, introduzimos um novo procedimento chamado Import Object Storage. Ele permite pular o processo de recriação manual do repositório SOBR e a anexação 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 única coisa que pode se interpor entre você e seus backups é um pedido para inserir a senha, caso seus backups tenham sido criptografados.

Com isso, sobre o Modo de Cópia, é tudo e passamos para

Modo Selado

A ideia principal é que novos backups não podem ser criados no volume selecionado do repositório SOBR. Até a versão 10, tínhamos apenas o Modo de Manutenção, onde qualquer operação no repositório era completamente proibida. Uma espécie de modo hardcore para retirar o storage de operação, onde apenas o botão Evacuar estava disponível, movendo os backups para outro volume de forma única.

O modo Selado é uma versão “suave”: proibimos a criação de novos backups e removemos gradualmente os antigos de acordo com a retenção escolhida, mas no processo não perdemos a capacidade de restaurar a partir dos pontos armazenados. Uma ferramenta muito útil, quando o tempo de vida do hardware está se esgotando e precisa ser substituído, ou simplesmente precisa ser liberado para algo mais importante, e não há como mudar tudo de uma vez. Ou não é possível deletar.

Portanto, o princípio de operação é bastante simples: é necessário proibir todas as operações de gravação (aparecimento de novos dados), mantendo leitura (restaurações) e exclusão (retenção).

Ambos os modos podem ser usados simultaneamente, mas deve-se considerar que o Modo de Manutenção tem prioridade.

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 à criação de um novo full active no segundo volume disponível. Se nossa retenção é de quatro, quando toda a cadeia no volume selado ultrapassa sua validade, ela é apagada sem remorso.

Existem situações em que a exclusão ocorre mais cedo. Por exemplo, isso acontece com o Forward incremental com fulls periódicos. Se nos primeiros dois dias fizemos backups completos, e na quinta-feira decidimos fechar o repositório, então na sexta-feira, quando um novo full for criado, o arquivo de segunda-feira será excluído, pois não há dependências até esse ponto. E esse ponto não depende de ninguém. Depois disso, aguardamos a criação de quatro pontos no extent disponível e removemos os três restantes, que não podem ser excluídos independentemente uns dos outros.

As coisas são mais simples com o Reverse Incremental. Nele, os pontos mais antigos não dependem de nada e podem ser excluídos sem problemas. Portanto, assim que um novo .vbk é criado em um novo extent, os antigos .vrb são removidos um a um.

A propósito, por que criamos um novo .vbk cada vez: se não 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ão. Assim, foi decidido que assim que o extent é fechado, criamos um backup completo em um extent livre.

As coisas são mais complicadas com o capacity tier.

Primeiro, vamos considerar o modo copy. Suponha que criamos backups ativamente por quatro dias e depois o capacity tier foi fechado. Não excluímos nada, mas pacientemente aguardamos a retenção, após o que excluímos os dados do capacity tier.

Acontece algo semelhante no modo move — aguardamos a retenção, excluímos o antigo no armazenamento local e removemos o que está armazenado no object storage.

Um exemplo interessante é o Forever forward incremental. Definimos a retenção em três pontos e começamos a fazer backups na segunda-feira, que são corretamente copiados para a nuvem. Após o fechamento do armazenamento, os backups continuam a ser criados, mantendo três pontos, mas os dados armazenados no capacity tier permanecem dependentes e não podem ser excluídos. Portanto, aguardamos até quinta-feira, quando nosso .vbk ultrapassa a retenção, e somente então removemos toda a cadeia salva.

E uma pequena ressalva: todos os exemplos aqui foram mostrados com uma única máquina. Se você tiver várias em backup, a retenção delas será diferente dependendo de ter sido feito um Active Full ou não.

É basicamente isso. Então, vamos para o recurso mais hardcore —

Imutabilidade

Assim como nos pontos anteriores, vamos primeiro falar sobre qual problema essa função resolve. Assim que transferimos nossos backups para armazenamento, surge o desejo urgente de garantir sua integridade, ou seja, proibir fisicamente sua exclusão e qualquer modificação durante o período definido de retenção. Isso inclui os administradores, mesmo com suas contas de root. Isso protege os backups contra corrupção acidental ou intencional. Quem trabalha com AWS pode ter encontrado uma função semelhante chamada Object Lock.

Agora vamos considerar o modo de forma geral e depois nos aprofundaremos nos detalhes. No nosso exemplo, a Imutabilidade será ativada para nosso tier de capacidade com uma retenção de quatro dias. E o backup terá o modo Copia ativado.

A Imutabilidade não interage com a retenção geral. Por exemplo, ela não adiciona pontos adicionais ou algo assim. Simplesmente, durante quatro dias, a pessoa não pode excluir os arquivos de backup. Se um backup for feito na segunda-feira, o arquivo só poderá ser excluído na sexta-feira.

Todos os conceitos previamente explicados de desidratação, índices e metadados continuam a funcionar exatamente da mesma forma. Mas com uma condição — o bloqueio é aplicado não apenas aos dados, mas também aos metadados. Isso é feito caso um malicioso atacante decida apagar nossa base de metadados e para evitar que os blocos de dados se tornem uma pilha binária inútil.

E agora chegou o momento perfeito para explicar nossa tecnologia de geração de blocos. Ou block generation. Para isso, vamos considerar a situação que levou ao seu surgimento.

Vamos considerar uma linha do tempo de seis dias e marcar em baixo o tempo esperado para a expiração da immutability. No primeiro dia, criamos um arquivo que consiste no bloco a e seus metadados. Se a immutability estiver definida para três dias, é lógico supor que no quarto dia os dados serão desbloqueados e removidos. No segundo dia, adicionaremos um novo file2, composto pelo bloco b com as mesmas configurações. O bloco a ainda deve ser removido no quarto dia. Mas no terceiro dia acontece algo terrível — é criado um arquivo File3, que consiste em um novo bloco d e uma referência ao antigo bloco a. Isso significa que para o bloco a, seu estado de immutability deve ser redefinido para um novo período, que é estendido até o sexto dia. E aqui surge um problema — em backups reais, tais blocos geram uma quantidade enorme. E para estender o período de immutability, é necessário fazer uma quantidade enorme de solicitações a cada vez. E na prática, isso será um processo quase infinito diário, pois com grande probabilidade a cada cópia encontraremos enormes pilhas de blocos desduplicados. E o que significa uma grande quantidade de solicitações para provedores de armazenamento de objetos? Exatamente! Uma conta enorme no final do mês.

E para não acabar cobrando uma fortuna dos nossos valiosos clientes por motivos triviais, foi inventado um mecanismo de geração de blocos. Este é um período adicional que adicionamos ao período de immutability estabelecido. No exemplo abaixo, esse período é igual a dois dias. Mas isso é apenas um exemplo. Na realidade, é usada uma fórmula própria que fornece cerca de dez dias adicionais em um bloqueio mensal.

Vamos continuar a analisar a mesma situação, mas já com a geração de blocos. No primeiro dia, criamos o file1 a partir do bloco a e dos metadados. A contagem do período de gerações e a imutabilidade significa que a possibilidade de excluir o arquivo será no sexto dia. Se no segundo dia criarmos o File2, que consiste no bloco b e uma referência ao bloco a, a data prevista para a exclusão permanece a mesma. Ela continua marcada para o sexto dia. Assim, estamos tentando economizar dinheiro no número de solicitações. A única situação em que o prazo pode ser alterado é se o período de geração expirar. Ou seja, se no terceiro dia o novo File3 contiver uma referência ao bloco a, a geração 2 será adicionada, pois a Gen1 já expirou. A data esperada para a exclusão do bloco a será antecipada para o oitavo dia. Isso nos permite reduzir drasticamente o número de solicitações para prorrogar a vida útil de blocos deduplicados, economizando muito dinheiro para os clientes.

A própria tecnologia está disponível para os usuários S3 e hardware compatível com S3, cujos fabricantes garantem que sua implementação não difere da da Amazon. Daqui vem a resposta para a pergunta legítima sobre por que o Azure não é suportado — eles têm um recurso semelhante, mas ele funciona no nível de contêineres e não de objetos individuais. A propósito, na própria 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ção do Object Lock, exclua os dados. No caso de compliance, tudo fica absolutamente fixado e os backups não podem ser excluídos por ninguém. Mesmo pelos administradores da Amazon (segundo suas declarações oficiais). Nós suportamos exatamente esse modo.