Política de Retenção de Backup: Guia para Definir

O que é política de retenção de backup e por que ela existe

Política de retenção de backup é o conjunto de regras que define por quanto tempo cada cópia de segurança permanece armazenada antes de ser sobrescrita ou descartada. Parece um detalhe operacional, mas é uma das decisões mais estratégicas da infraestrutura de TI: ela determina até que ponto no passado sua empresa consegue voltar quando algo dá errado. Uma retenção curta demais transforma um incidente recuperável em perda definitiva de dados; uma retenção longa demais multiplica o custo de armazenamento sem entregar proteção proporcional.

O erro mais comum nas empresas brasileiras é tratar retenção como sinônimo de "espaço em disco". A pergunta certa não é "quanto cabe no meu storage", e sim "qual é o período de exposição que meu negócio consegue absorver". Ransomware moderno, por exemplo, costuma permanecer dormente na rede por semanas antes de disparar a criptografia. Se sua retenção é de sete dias, todos os pontos de restauração disponíveis já estarão contaminados quando o ataque for percebido. Empresas que sobreviveram a incidentes desse tipo quase sempre tinham cópias mensais ou trimestrais guardadas.

Há ainda o cenário silencioso da corrupção lógica: uma migração mal feita, um script que apagou registros errados, um usuário que excluiu uma pasta compartilhada em janeiro e só percebeu em abril. Nenhum desses casos gera alarme imediato. A retenção é o que separa "restauramos em vinte minutos" de "essa informação não existe mais".

O esquema GFS: avô, pai e filho explicado na prática

GFS é a sigla de Grandfather-Father-Son (avô, pai, filho), o modelo de rotação de backups mais consolidado do mercado. A lógica é simples e elegante: em vez de guardar tudo com a mesma granularidade, você mantém muitos pontos recentes e poucos pontos antigos. Isso oferece precisão para incidentes recentes e alcance histórico para descobertas tardias, sem explodir o volume armazenado.

Na prática, o esquema se organiza em três camadas:

• Filho (diário) — backups executados todos os dias úteis, retidos por 7 a 14 dias. Resolvem 90% dos chamados reais: arquivo apagado, e-mail perdido, tabela sobrescrita.
• Pai (semanal) — uma cópia consolidada por semana, retida por 4 a 8 semanas. Cobre incidentes percebidos dentro do mês.
• Avô (mensal e anual) — o último backup de cada mês, retido por 12 meses, e o de fechamento de exercício, retido por 5 anos ou mais. É a camada de conformidade e auditoria.

Um exemplo concreto de política GFS equilibrada para uma empresa de médio porte: 14 pontos diários, 8 semanais, 12 mensais e 5 anuais. Isso soma 39 pontos de restauração cobrindo cinco anos de histórico — muito diferente dos 39 dias que você teria se guardasse apenas cópias diárias no mesmo número de slots. A eficiência do GFS vem justamente dessa curva decrescente de granularidade.

Vale destacar que backups incrementais e sintéticos mudam bastante a matemática de espaço. Com deduplicação e incrementais eternos (forever incremental), reter 12 meses pode custar menos do que muitos gestores imaginam, porque apenas os blocos alterados ocupam espaço novo. O cálculo precisa considerar a taxa de mudança diária dos dados, normalmente entre 2% e 5% em ambientes corporativos típicos.

Exigências legais brasileiras: o que a lei realmente obriga

No Brasil, não existe uma norma única que diga "guarde backups por X anos". O que existe é um conjunto de obrigações de guarda documental que, por consequência, define pisos mínimos de retenção para os sistemas que armazenam esses dados. Conhecer esses prazos evita tanto a exposição jurídica quanto o excesso de armazenamento por precaução mal calibrada.

Os prazos mais relevantes para a maioria das empresas:

1. Documentos fiscais e escrituração contábil — 5 anos, contados do primeiro dia do exercício seguinte, conforme o prazo decadencial do Código Tributário Nacional. Vale para NF-e, SPED, livros contábeis e comprovantes.
2. Registros trabalhistas e FGTS — a prescrição trabalhista alcança 5 anos durante o contrato e 2 anos após o término; documentos previdenciários e de FGTS costumam ser mantidos por prazos mais longos, e muitas empresas adotam 30 anos por segurança.
3. Registros de conexão e acesso a aplicações — o Marco Civil da Internet exige guarda de 1 ano para registros de conexão e 6 meses para registros de acesso a aplicações, aplicável a quem provê esses serviços.
4. Dados pessoais sob a LGPD — aqui a lógica se inverte: a Lei Geral de Proteção de Dados exige eliminação do dado após o fim de sua finalidade. Reter indefinidamente não é conservadorismo, é infração.

A LGPD transforma retenção excessiva em risco. Guardar um backup com dados pessoais além do necessário sem base legal expõe a empresa à mesma fiscalização que a perda desses dados. Política de retenção madura define tanto o mínimo quanto o máximo.

Esse ponto merece atenção especial porque cria uma tensão real de arquitetura. Se um titular exerce o direito de eliminação, o dado precisa sair também dos backups — o que é tecnicamente inviável em mídias imutáveis. A prática aceita pelo mercado é documentar formalmente que o dado permanece congelado em cópias de segurança até o vencimento natural da retenção, sem qualquer tratamento ativo, e que será eliminado no ciclo seguinte. Essa justificativa precisa estar registrada no inventário de tratamento, não improvisada durante uma fiscalização.

Equilibrando custo, risco e capacidade de restauração

Definir retenção é um exercício de trade-off entre três variáveis: custo de armazenamento, janela de risco aceitável e velocidade de recuperação. Aumentar a retenção reduz risco e aumenta custo — mas não de forma linear, e é aí que a maioria das empresas erra o dimensionamento.

O caminho mais eficiente é o tiering por temperatura de dado. Backups diários ficam em storage rápido, local, com restauração em minutos. Backups mensais e anuais migram para armazenamento de baixo custo — object storage em nuvem, fita LTO ou repositórios de arquivamento — onde o custo por terabyte cai drasticamente e a latência de restauração de horas é perfeitamente aceitável, já que ninguém restaura um backup de dois anos atrás com urgência de produção.

Alguns critérios práticos para dimensionar corretamente:

• Classifique os dados antes de definir prazos. Sistema ERP, base de clientes e servidor de arquivos raramente merecem a mesma política. Aplicar retenção máxima a tudo é desperdício garantido.
• Aplique a regra 3-2-1-1-0 — três cópias, em duas mídias diferentes, uma fora do site, uma imutável ou offline, e zero erros de verificação. A camada imutável é hoje a defesa mais eficaz contra ransomware que ataca o próprio repositório de backup.
• Meça RPO e RTO por sistema. RPO define quanto dado você aceita perder (frequência do backup); RTO define quanto tempo aceita ficar parado (arquitetura da restauração). Retenção é uma terceira dimensão, independente das duas.
• Teste restaurações periodicamente. Backup não testado é hipótese, não proteção. Restauração de amostra mensal e simulação completa semestral deveriam ser rotina auditada.

Um detalhe frequentemente ignorado: o custo de saída de dados. Repositórios em nuvem de baixo custo costumam cobrar por egresso, e uma restauração completa de vários terabytes pode gerar uma fatura inesperada exatamente no pior momento. Esse custo precisa entrar na conta durante o desenho da política, não durante o desastre.

Como documentar e revisar sua política de retenção

Uma política de retenção que existe apenas na configuração da ferramenta de backup não é uma política — é um parâmetro. A documentação formal é o que garante continuidade quando há troca de fornecedor, saída de um profissional-chave ou questionamento em auditoria. E ela precisa ser curta o suficiente para ser lida.

O documento mínimo viável contém: escopo dos sistemas cobertos, prazos de retenção por camada (diária, semanal, mensal, anual), justificativa legal ou de negócio para cada prazo, responsável pela execução e pela verificação, procedimento de restauração com tempos esperados, e política de descarte seguro das mídias vencidas. Esse último item é rotineiramente esquecido: descartar backup antigo sem destruição criptográfica ou física adequada é vazamento de dados em potencial.

A revisão deve ser anual, ou imediata sempre que houver mudança relevante — novo sistema crítico entrando em produção, alteração de obrigação regulatória, crescimento acentuado do volume de dados ou incidente de segurança. Após qualquer restauração real, vale registrar o que funcionou e o que faltou; esse retorno prático é a melhor fonte de ajuste da política.

Como a Duk estrutura retenção para ambientes corporativos

Na Duk Informática & Cloud, retenção de backup é tratada como projeto de arquitetura, não como configuração isolada. Ao longo de 18 anos atendendo mais de 550 empresas, consolidamos um método que parte do mapeamento de criticidade de cada sistema, cruza com as obrigações legais aplicáveis ao segmento do cliente e só então define o esquema GFS e o tiering de armazenamento adequados — evitando tanto a exposição de janelas curtas quanto o desperdício de reter tudo por cinco anos.

Como Microsoft Gold Partner, integramos proteção de ambientes Microsoft 365, servidores físicos e virtuais e cargas em nuvem sob uma política unificada, com camada imutável contra ransomware e repositório em nosso data center próprio em Alphaville. Os testes de restauração são executados e documentados periodicamente, com relatório de verificação — porque a única métrica que importa em backup é a taxa de sucesso na hora de recuperar.

Se sua empresa opera hoje com uma política herdada, indefinida ou nunca testada, vale iniciar por um diagnóstico: quais sistemas estão cobertos, qual o ponto mais antigo realmente restaurável e quanto tempo levaria para voltar ao ar. A partir desse retrato, ajustar prazos e arquitetura é um trabalho objetivo — e quase sempre mais barato do que o gestor imagina.