Backup Não é Disaster Recovery: A Diferença Custa Horas ou Dias

Quase todas as organizações têm backups. Muito poucas conseguem dizer, com um número, em quanto tempo voltam a operar depois de uma falha grave. Essa distância, entre ter cópias dos dados e conseguir recuperar a operação, é onde vive o disaster recovery. E é onde muitas empresas descobrem, tarde demais, que não estavam preparadas.

A confusão é comum e cara. Backup e disaster recovery resolvem problemas diferentes, e tratar um pelo outro deixa a operação exposta precisamente no momento em que menos o pode pagar.

Backup responde a uma pergunta. Disaster recovery responde a outra.

Um backup guarda uma cópia dos dados num determinado momento. Serve para recuperar de um apagamento acidental, de uma corrupção ou de um ataque. É necessário, mas responde a uma única pergunta: "temos os dados algures?".

O disaster recovery responde a uma pergunta diferente e mais exigente: "em quanto tempo é que a operação volta a funcionar, e quanto trabalho se perde pelo caminho?". Aqui entram duas medidas concretas:

• RTO (Recovery Time Objective): o tempo máximo aceitável até o sistema voltar a estar operacional.
• RPO (Recovery Point Objective): a quantidade máxima de dados que se pode perder, medida em tempo.

Um backup sem estes dois números definidos não é um plano de recuperação. É uma suposição.

A diferença tem preço, e conta-se ao minuto

Enquanto um sistema crítico está em baixo, o custo corre.

Em serviços financeiros, o número é ainda mais duro.

A esta escala, recuperar em minutos em vez de dias não é um detalhe técnico. É a diferença entre um incidente controlado e uma crise de negócio, com clientes, reputação e reguladores no meio.

Os quatro enganos que transformam um backup numa falsa segurança

1. O backup nunca foi restaurado. Restaurar não é o mesmo que ter. Muitos backups só falham no dia em que são precisos, por estarem incompletos, corrompidos ou dependentes de um sistema que já não existe.
2. Não há RTO nem RPO definidos. Sem estes números, ninguém sabe o que é "recuperado a tempo". O plano é uma intenção, não um compromisso.
3. O plano vive no papel. Documentos de continuidade que nunca foram ensaiados assumem acessos, dependências e passos que, na prática, falham sob pressão.
4. A recuperação depende de uma só pessoa. Quando o conhecimento do processo está na cabeça de um indivíduo, o plano vai de férias, adoece e sai com essa pessoa.

O que é um plano de disaster recovery a sério

Um plano de recuperação que merece o nome tem quatro características:

• RTO e RPO definidos por sistema, alinhados com a criticidade para o negócio, não com o que é tecnicamente conveniente.
• Replicação estável e alta disponibilidade testada, para que a base de dados crítica não seja o ponto cego da operação.
• Failover ensaiado, com testes regulares que provam que a recuperação acontece dentro do RTO e do RPO prometidos.
• Operação com dono: on-call com rotação, runbooks testados e post-mortems sem culpados, para que a resposta não dependa de improviso.

O efeito, quando isto é bem feito, é mensurável.

O teste que separa quem está preparado

Há uma forma simples de saber onde uma operação está. Escolhe-se um sistema crítico, marca-se o cronómetro e restaura-se do zero, como se fosse uma falha real. Em sessenta minutos, esse ensaio revela o que nenhum documento mostra: se o RTO e o RPO são reais ou aspiracionais, onde estão os bloqueios, e se os backups são de facto recuperáveis.

Um teste de disaster recovery não serve para provar que está tudo bem. Serve para encontrar o que está mal enquanto ainda é barato encontrá-lo.

Conclusão

Ter backups é o primeiro passo, não o último. A pergunta que importa não é "temos cópias?", mas "quando foi a última vez que a recuperação foi cronometrada, do início ao fim?". A resposta a essa pergunta, medida em RTO e RPO reais, é o que separa uma operação resiliente de uma que está a contar com a sorte.

Para saber em quanto tempo a operação volta a estar de pé, e o que é preciso para lá chegar, a xGrowth começa por uma reunião breve, sem compromisso, sobre fiabilidade e bases de dados críticas: Agendar Sessão de Esclarecimento.