Hoje vamos falar sobre retenção de backup, uma daquelas configurações que muita gente define no primeiro job e nunca mais revisita. Quanto tempo guardar? Uma semana, um mês, cinco anos? E principalmente, como guardar por mais tempo sem encher o repositório em poucos meses?

No Veeam Backup & Replication, a retenção configurada no job é a chamada retenção de curto prazo, definida no campo Retention Policy em número de restore points ou em dias. Ela é perfeita para a recuperação do dia a dia: o arquivo apagado ontem, a VM que quebrou depois de uma atualização, o banco que alguém corrompeu na sexta-feira a tarde. O problema começa quando aparece o pedido de um arquivo de seis meses atrás. Manter 180 dias de restore points diários deixa a cadeia enorme e consome muito espaço, ou seja, não é o caminho (se quiser relembrar como a cadeia é formada, escrevi sobre os modos de backup no Veeam Backup & Replication).

E é exatamente aí que entra o GFS (Grandfather-Father-Son), a retenção de longo prazo. Segundo a documentação da Veeam, o GFS não cria arquivos novos. Ele marca alguns dos backups full do job com flags semanal (W), mensal (M) ou anual (Y), e enquanto a flag estiver válida aquele full não pode ser apagado nem modificado pela retenção de curto prazo. A configuração fica na etapa Storage do job, na opção Keep certain full backups longer for archival purposes. Por exemplo: 14 dias de curto prazo, 4 semanais, 12 mensais e 5 anuais. Lembrando que o GFS não funciona com reverse incremental, e que no forever forward incremental é preciso garantir fulls periódicos.

E o espaço? Cada ponto GFS é um full, mas isso não significa que cada um ocupa o tamanho inteiro da origem. Em repositórios com ReFS 3.1 (ou posterior) ou XFS, o Fast Clone referencia os blocos que já existem em vez de copiá-los de novo, desta forma os synthetic fulls ocupam bem menos espaço. Para retenções longas, também vale pensar em object storage com imutabilidade como segunda camada, assunto que comentei no post sobre criptografia e imutabilidade no Veeam Backup & Replication.

Agora a minha opinião, de quem ve isso em muitos ambientes: a retenção não deveria ser decidida pelo espaço que sobrou no storage. O que eu mais vejo é o contrário, alguém compra o repositório e depois descobre quantos dias cabem nele. Quem precisa responder quanto tempo guardar é o negócio e o jurídico, porque são eles que conhecem as exigências legais, fiscais e de auditoria de cada tipo de dado. E vale para os dois lados: guardar menos do que a lei exige é um problema, e guardar dados pessoais muito além do necessário também é. A TI entra depois, para dimensionar o armazenamento a partir dessa resposta e mostrar quanto custa.

De forma bem simples, o curto prazo e GFS se completam: um para a recuperação rápida, o outro para a auditoria e o histórico. O importante é que a retenção seja uma decisão documentada e revisada de tempos em tempos, e não um número que ficou no job desde a instalação.

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