Backup que sobrevive ao desastre
Uma cópia só vira estratégia de recuperação quando está fora do mesmo domínio de falha, preserva versões e passa por restaurações verificadas.
Cópia local resolve pouco
Duplicar arquivos em outra pasta pode ajudar numa exclusão acidental, mas não protege contra falha do disco, comprometimento da máquina ou erro automatizado que alcance os dois locais. O primeiro passo é identificar quais eventos a cópia precisa suportar.
Domínio de falha é tudo o que pode ser perdido pelo mesmo incidente. Duas cópias no mesmo volume compartilham o disco. Duas máquinas no mesmo ambiente podem compartilhar energia, rede, credenciais administrativas ou uma rotina defeituosa. Sem mapear essas dependências, a contagem de cópias sugere mais proteção do que existe.
O conjunto de recuperação é maior que a pasta pública
Restaurar uma aplicação exige mais do que código e imagens. Dados persistentes, arquivos enviados, configurações, chaves, tarefas agendadas e instruções operacionais podem ser necessários para recompor o serviço. O inventário precisa dizer o que é essencial, onde está e com que frequência muda.
Também é necessário manter consistência. Copiar arquivos enquanto dados relacionados mudam pode produzir um conjunto que nunca existiu de verdade. O mecanismo escolhido deve criar um ponto recuperável ou registrar a ordem necessária para reconstruí-lo.
Retenção responde a falhas descobertas tarde
Uma única cópia sempre substituída protege apenas contra problemas percebidos imediatamente. Corrupção silenciosa, exclusão indevida ou alteração maliciosa podem ser notadas dias depois. Quando isso acontece, o estado mais recente já pode carregar o mesmo defeito.
Uma política de retenção mantém pontos de recuperação com granularidade diferente: mais versões recentes e menos versões antigas, conforme o risco e o volume. O prazo não deve nascer de um número genérico. Ele precisa considerar quanto tempo um problema pode permanecer oculto e quais obrigações exigem preservar ou eliminar dados.
Isolamento inclui identidade e permissão
Enviar a cópia para outro local não basta se a mesma credencial usada na produção pode apagá-la. Separar contas, limitar permissões e registrar operações reduz a chance de um incidente alcançar origem e backup ao mesmo tempo.
Imutabilidade ou bloqueio de exclusão pode aumentar a resistência, desde que retenção e descarte também sejam planejados. Cifra protege dados armazenados e em trânsito, mas as chaves precisam estar disponíveis durante a recuperação. Uma cópia indecifrável no momento crítico continua indisponível.
RPO e RTO transformam expectativa em decisão
O objetivo de ponto de recuperação, RPO, expressa quanto dado pode ser perdido entre a última cópia válida e o incidente. O objetivo de tempo de recuperação, RTO, expressa quanto tempo o serviço pode levar para retornar. Eles orientam frequência, automação, capacidade e ordem de restauração.
Metas menores custam mais e exigem mecanismos mais sofisticados. Por isso, devem ser escolhidas com base no impacto para o negócio. Backup diário não atende automaticamente a uma operação que não pode perder um dia de dados.
O teste de restauração encerra o ciclo
Registro de execução bem-sucedida confirma que a rotina gravou algo. Completude, integridade e utilidade só aparecem ao restaurar em ambiente separado, iniciar os componentes necessários e conferir dados e funções essenciais.
Exercícios periódicos revelam dependências esquecidas, permissões vencidas, documentação incompleta e tempos irreais. O resultado atualiza o roteiro de recuperação. Backup é o ciclo de copiar, proteger, restaurar e aprender; o arquivo gerado de madrugada é a primeira etapa dele.