Quase toda empresa tem backup. Pouquíssimas sabem, com precisão, quanto tempo levaria para voltar a operar depois de um incidente sério — e essa é a pergunta que realmente importa. Backup não é um fim em si; é um meio para a recuperação. Se a restauração não foi testada, o backup é uma esperança, não um plano.

Este artigo cobre os dois números que definem uma estratégia de backup (RPO e RTO), a regra prática de onde guardar as cópias, o teste de restauração e os erros mais comuns.

RPO — quanto de dado você aceita perder

RPO (Recovery Point Objective) é a quantidade de dados que a empresa aceita perder em um incidente, medida em tempo. Um RPO de 1 hora significa que, no pior caso, você perde a última hora de trabalho — e portanto o backup precisa rodar pelo menos de hora em hora.

Sistemas transacionais, com pedidos e pagamentos, costumam exigir RPO de minutos, o que leva a técnicas de replicação contínua. Um site institucional pode tolerar um RPO de 24 horas. Definir o RPO é uma decisão de negócio: quanto custa recriar o que foi perdido versus quanto custa a infraestrutura para reduzir a janela.

RTO — quanto tempo você aceita ficar fora do ar

RTO (Recovery Time Objective) é o tempo máximo aceitável entre o incidente e a volta à operação. Um RTO de 4 horas significa que, do momento em que o sistema cai até estar de volta, não podem passar mais de 4 horas.

O RTO define o quão pronta a restauração precisa estar. Um RTO curto exige ambientes de espera, automação de restauração e procedimentos ensaiados. Um RTO longo permite processos mais manuais. Assim como o RPO, é uma decisão de negócio baseada no custo de cada hora parado.

A regra 3-2-1

Uma diretriz consagrada para onde guardar backups:

  • 3 cópias dos dados — a original e pelo menos duas de backup.
  • 2 mídias ou tecnologias diferentes — para não depender de um único tipo de falha.
  • 1 cópia fora do local — em outra região, outro provedor ou fisicamente separada, para sobreviver a um desastre que afete o site principal.

Uma extensão moderna acrescenta o “1 imutável” — uma cópia que não pode ser alterada nem apagada por um período, para resistir a ransomware, que hoje ataca justamente os backups.

O teste de restauração: o que realmente importa

Um backup só conta como válido depois de ter sido restaurado com sucesso em um ambiente limpo. O teste consiste em pegar o backup, restaurá-lo do zero em um ambiente separado, verificar que os dados estão íntegros e completos, e cronometrar quanto tempo levou.

É nesse teste que se descobre o que estava errado o tempo todo:

  • Faltava um arquivo de configuração que não entrava no backup.
  • A senha do banco no procedimento de restauração estava desatualizada.
  • O backup estava sendo feito, mas de uma pasta errada, e parte dos dados nunca foi copiada.
  • A restauração levava o dobro do RTO combinado.
  • O backup estava corrompido e ninguém sabia, porque nunca tinha sido aberto.

O teste deve ser periódico — trimestral é uma frequência razoável para a maioria dos casos — e documentado, com o tempo medido e comparado ao RTO.

Backup não é versionamento, nem arquivamento

Três conceitos que costumam ser confundidos: backup serve para recuperar de uma falha recente (dias ou semanas). Arquivamento serve para guardar dados por obrigação legal ou histórica (anos), com acesso raro. Versionamento de código é outra coisa ainda. Cada um tem uma política e uma ferramenta própria; usar backup como arquivo, ou vice-versa, costuma sair caro e não atender bem a nenhum dos dois.

Retenção: por quanto tempo guardar

A retenção deve cobrir o tempo até um problema ser percebido. Se um dado corrompido só é notado depois de um mês, um backup de sete dias não ajuda. Uma política comum combina granularidades: backups diários dos últimos 30 dias, semanais dos últimos 3 meses, mensais do último ano. Ajuste conforme o custo e o risco do seu caso.

Erros comuns

  • Nunca ter restaurado o backup.
  • Guardar todas as cópias no mesmo lugar da produção.
  • Não incluir configurações, segredos e infraestrutura no backup — só o banco.
  • Retenção curta demais para o tempo de detecção de problemas.
  • Backup sem monitoramento — ninguém é avisado quando ele falha.
  • Não proteger os backups contra exclusão, deixando-os vulneráveis a ransomware.
  • Documentação do procedimento de restauração desatualizada ou inexistente.

Ransomware mudou as regras

Ataques de ransomware hoje procuram e criptografam os backups antes de acionar o resgate, justamente porque um backup íntegro elimina o poder de barganha do atacante. Isso tornou obrigatório o que antes era recomendação: pelo menos uma cópia imutável (que não pode ser alterada nem apagada por um período definido) e, idealmente, uma cópia isolada, em outra conta ou provedor, com credenciais separadas.

Também vale ter um plano de recuperação que assuma o pior cenário — não “um disco falhou”, mas “toda a infraestrutura foi comprometida” — e saber quanto tempo levaria para reconstruir a partir de uma cópia isolada.

O que entra no backup além do banco de dados

Um erro comum é fazer backup apenas do banco de dados e descobrir, na restauração, que falta metade do necessário para o sistema funcionar. O escopo completo costuma incluir:

  • O banco de dados.
  • Arquivos enviados por usuários (documentos, imagens, anexos).
  • Arquivos de configuração e variáveis de ambiente.
  • Segredos e credenciais (guardados de forma segura).
  • A definição da infraestrutura, se ela é gerida como código.
  • Certificados e chaves.

Automação e monitoramento do backup

Backup manual é backup que uma hora não acontece. A rotina precisa ser automática, e precisa haver um monitoramento que avise quando ela falha — o que é mais comum do que parece: um disco cheio, uma credencial expirada, uma mudança de estrutura que quebrou o script. Um backup que falha silenciosamente por semanas é pior do que não ter backup, porque gera uma falsa sensação de segurança.

Backup de serviços gerenciados: não terceirize a responsabilidade

Ao usar um banco de dados gerenciado na cloud, é fácil assumir que “o provedor faz backup”. Ele faz — dentro dos limites do plano contratado, com uma janela de retenção que pode ser curta, e sujeito a você não apagar o recurso por engano (o que costuma apagar os backups junto). Vale conhecer exatamente a política do provedor e complementar com uma exportação periódica para um local sob seu controle, especialmente para os dados mais críticos.

Restauração parcial e granular

Nem todo incidente exige restaurar tudo. Um caso comum é alguém apagar ou corromper um conjunto específico de dados — uma tabela, os registros de um cliente, um período. Um bom desenho de backup permite restaurar só o que foi afetado, para um ambiente separado, extrair o necessário e reinserir na produção, sem derrubar o sistema inteiro nem reverter o trabalho de todos os outros usuários daquele dia.

Documentar e ensaiar o plano de recuperação

O procedimento de restauração precisa estar escrito, passo a passo, e guardado em um lugar acessível mesmo se o sistema principal estiver fora — não adianta o manual de recuperação estar hospedado no servidor que caiu. Além de escrito, precisa ser ensaiado: a primeira vez que alguém executa o procedimento não pode ser no dia do desastre, sob pressão, descobrindo os erros na hora.

Um checklist mínimo

  1. RPO e RTO definidos e acordados com o negócio.
  2. Backup automático na frequência que atende o RPO.
  3. Cópias seguindo a regra 3-2-1, com pelo menos uma imutável.
  4. Configurações, segredos, arquivos de usuário e definição de infraestrutura incluídos, não só o banco.
  5. Monitoramento que alerta quando um backup falha.
  6. Teste de restauração periódico, cronometrado e documentado.
  7. Procedimento de restauração escrito e acessível fora do sistema principal.
  8. Retenção que cobre o tempo de detecção de problemas.
  9. Uma cópia isolada, resistente a um comprometimento total da infraestrutura.

Como a Jumps trata

A Jumps inclui backup testado no escopo de sustentação e evolução: RPO e RTO definidos com o cliente, cópias em locais separados, monitoramento das rotinas e teste de restauração periódico com o tempo medido. Backup que nunca foi restaurado não é considerado backup.

Se você não sabe quanto tempo levaria para recuperar o seu sistema depois de um incidente, fale com a Jumps.