Backup 3-2-1 na prática, com verificação que realmente funciona

Existe uma verdade desconfortável sobre backup: quase toda empresa acha que tem, e uma parte grande descobre que não tinha exatamente no dia em que precisou. O problema quase nunca é ausência de backup. É backup que não cobria o que importava, ou que estava no lugar errado, ou que nunca foi testado.

A regra 3-2-1 resolve os três de uma vez, e cabe em uma frase.

O que é a regra 3-2-1

• 3 cópias dos dados: a original mais dois backups.
• 2 mídias diferentes: não adianta as duas cópias no mesmo disco que pode falhar junto.
• 1 cópia fora do local: protege contra incêndio, roubo, e contra o ataque que alcança tudo que está na mesma rede.

A parte do “fora do local” é a que mais protege contra o cenário moderno. Ransomware bem-feito procura os backups antes de cifrar, e uma cópia acessível pela mesma rede é apenas mais um alvo, como tratei em Ransomware, as primeiras 24 horas de resposta.

Traduzindo para uma empresa pequena

Não é preciso comprar solução cara. Um arranjo que cumpre a regra:

O ponto crítico é que a cópia de nuvem ou o disco externo não fique montado permanentemente na rede. Backup sempre conectado é backup ao alcance de quem comprometeu a rede.

A propriedade que falta na maioria: imutabilidade

Cópia que pode ser sobrescrita pode ser destruída. Backup imutável não pode ser alterado nem apagado por um período definido, nem por quem tem a senha de administrador.

Muitos serviços de nuvem oferecem isso sem custo adicional, com um nome como retenção ou bloqueio de objeto. Ativar essa opção é a diferença entre um backup que resiste a um ataque e um que é apagado junto com o resto.

O que incluir, e o que quase todo mundo esquece

Backup de arquivos é o óbvio. O que costuma faltar, e derruba a recuperação:

• Bancos de dados, exportados de forma consistente, não copiados a quente enquanto a aplicação escreve.
• Configuração de servidores, para reconstruir o ambiente, e não só os dados.
• Chaves e certificados, sem os quais o dado restaurado não abre.
• Caixas de e-mail, se estão em serviço de nuvem, porque a responsabilidade de backup nem sempre é do provedor.

Para banco de dados, exporte com a ferramenta própria dele em vez de copiar o arquivo em uso:

# exemplo com PostgreSQL, gera copia consistente
pg_dump -Fc -f /backup/app_$(date +%F).dump app_producao
sha256sum /backup/app_$(date +%F).dump >> /backup/hashes.txt

A parte que ninguém faz: testar a restauração

Backup nunca restaurado é fé, não é controle. E o dia do incidente é o pior momento para descobrir que o arquivo está corrompido, que faltava um pedaço, ou que ninguém sabe o procedimento.

Estabeleça um teste trimestral simples:

1. Escolha um backup ao acaso, não o mais recente.
2. Restaure em ambiente isolado, nunca por cima da produção.
3. Abra o dado e confirme que está íntegro e utilizável.
4. Cronometre. O tempo medido é o dado que a diretoria vai querer no dia do desastre.

Confira a integridade pelo hash gerado no momento do backup:

sha256sum -c /backup/hashes.txt

Quanto tempo você aguenta perder

Duas perguntas definem a política, e ambas são decisão de negócio, não de TI.

Quanto dado você aguenta perder? Se o backup é diário, um incidente ao fim do dia custa um dia inteiro de trabalho. Se isso é inaceitável para algum sistema, esse sistema precisa de backup mais frequente.

Quanto tempo você aguenta ficar parado? É o tempo de restauração que você cronometrou. Se ele é maior do que a empresa suporta, o problema não é o backup, é a velocidade de recuperação, e a solução é diferente.

O erro mais comum de todos

É configurar o backup uma vez e nunca mais olhar. Trabalho novo entra e não é incluído, o disco de destino enche e o backup passa a falhar em silêncio, alguém desativa a rotina para liberar espaço e esquece de religar.

Backup é processo, não projeto. Uma verificação mensal de que as rotinas rodaram e um teste trimestral de restauração custam pouco tempo e são a diferença entre ter backup e ter tido backup um dia.