Durante muito tempo o repositório de backup padrão era um servidor Windows ou Linux cheio de discos, as vezes com uma fita no fim da cadeia para tirar uma cópia do site. Hoje, quando converso sobre arquitetura de backup, a pergunta já não é se vai ter object storage, e sim onde ele vai ficar. O intuito deste post é falar um pouco sobre por que o object storage (Veeam Vault, Amazon S3, Azure Blob e compatíveis) virou o destino preferido para backup e quais cuidados vale ter antes de mandar tudo para lá.

Basicamente, o object storage resolve de uma vez só alguns problemas que sempre deram trabalho nos repositórios tradicionais:

• Escala: o bucket cresce conforme a necessidade, sem pensar em LUN, volume ou extensão de filesystem
• Custo: na nuvem você paga pelo que usa e on-premises existem várias soluções S3 compatíveis rodando em hardware comum
• Imutabilidade nativa: o S3 Object Lock trabalha no modelo WORM e segundo a AWS, no modo compliance nem o usuário root da conta consegue apagar o objeto antes do prazo
• Integração com a nuvem: o mesmo protocolo funciona no datacenter e no provedor, o que facilita bastante a cópia fora do site da regra 3-2-1

No Veeam Backup & Replication isso veio em etapas. Primeiro o object storage entrou como capacity tier do Scale-Out Backup Repository (SOBR) e na v10 a Veeam adicionou o copy mode e a imutabilidade com Object Lock, ou seja, o backup era copiado para o bucket logo que era criado e ficava protegido contra exclusão pelo período definido (documentação). Depois, na v12, chegou o backup direto para object storage: segundo a Veeam, os dados podem ser gravados no object storage sem precisar de um repositório em bloco antes. Já falei um pouco sobre imutabilidade em Criptografia e Imutabilidade no Veeam Backup & Replication.

Honestamente são poucos os casos que não faz sentido desenhar um ambiente novo sem object storage. Mas não tem mágica: a latência é maior que a de um disco local e um restore grande a partir de um bucket na nuvem depende diretamente do link. Cada bloco do backup vira um objeto, então o número de requisições é alto e o custo de API entra na conta, assim como o egress, que só aparece no dia em que você precisa restaurar tudo (a não ser que você use Veeam Vault, ai não precisa se preocupar com isso). O que eu já vi dar errado é quase sempre a mesma coisa: storage S3 compatível subdimensionado que não aguenta a quantidade de requisições, período de imutabilidade muito maior que o necessário fazendo a conta crescer, e ninguém nunca testou um restore a partir do bucket. Antes de escolher a solução, vale verificar se ela faz parte do programa Veeam Ready na categoria de object storage com imutabilidade.

O importante é que o object storage virou padrão porque junta escala, custo e imutabilidade em um lugar só e o Veeam Backup & Replication aproveita bem isso, seja como capacity tier no SOBR ou como repositório direto. Claro que é fundamental dimensionar, calcular os custos que não aparecem no primeiro mês e testar o restore.

É isso aí, pessoal. Até a próxima!