Backup de banco de dados: o que o dump não salva

"Temos dump diário" é a resposta mais comum quando se pergunta sobre proteção do banco de dados. É melhor que nada — e está muito longe de ser uma estratégia. O dump diário responde bem a uma pergunta ("e se o banco sumir inteiro?") e mal a quase todas as outras que aparecem em um incidente real.

Este texto separa o que cada tipo de backup protege, o que o dump deixa de fora e como chegar a um desenho que resiste ao incidente que você vai ter, não ao que imaginou.

As perguntas que a estratégia precisa responder

Antes de escolher ferramenta, defina os dois números que governam tudo:

• RPO — quanto dado você pode perder. Se o dump é às 3h e o desastre é às 17h, você perde 14 horas. Esse é o seu RPO real, escreva-o.
• RTO — quanto tempo pode ficar fora. Se restaurar 800 GB leva seis horas e o negócio aceita duas, o backup está inadequado mesmo estando íntegro.

Esses dois números não são técnicos, são de negócio. E precisam estar escritos e acordados — não deduzidos por quem configurou o script.

E os cenários que a estratégia precisa cobrir:

A terceira linha é a que mais dói na prática, e é o principal motivo de existir backup contínuo.

Lógico e físico: dois backups, dois propósitos

Backup lógico (dump) exporta o conteúdo: comandos ou dados que recriam objetos e linhas.

• Portável entre versões e, às vezes, entre plataformas.
• Permite restaurar seletivamente uma tabela ou um esquema.
• Legível, verificável, bom para migração.
• Lento para restaurar bases grandes — o banco precisa reprocessar tudo, reconstruir índices, revalidar restrições.
• Impacta a produção durante a extração.

Backup físico copia os arquivos do banco no disco.

• Restauração muito mais rápida: os arquivos voltam para o lugar.
• Permite incremental e recuperação a um ponto no tempo.
• Preso à versão e à arquitetura — não se restaura em versão diferente.
• Restaura o banco inteiro; não dá para escolher uma tabela.

A conclusão prática: não é um ou outro, são os dois. Físico com arquivamento contínuo é a proteção principal, porque atende RTO e RPO. Lógico periódico é o complemento, porque cobre restauração seletiva, migração de versão e verificação de consistência lógica.

O recurso que muda o patamar: recuperação a um ponto no tempo

Backup físico completo mais o arquivamento contínuo dos registros de transação permite restaurar o banco para qualquer instante dentro da janela de retenção — inclusive um segundo antes do comando que apagou os dados.

É a diferença entre perder um dia de trabalho e perder dois minutos. E é o que transforma o incidente mais comum de todos — erro humano em produção — de catástrofe em contratempo.

Todos os bancos relacionais sérios suportam isso, com nomes diferentes: arquivamento de WAL no PostgreSQL, log binário no MySQL e MariaDB, oplog no MongoDB. Existem ferramentas dedicadas que cuidam da parte difícil — backup base incremental, arquivamento, retenção, verificação e restauração assistida até um instante escolhido. Montar isso com scripts próprios é possível e quase nunca compensa.

Se o seu banco tem dump diário e nada mais, esse é o próximo passo de maior retorno.

O que o dump não leva junto

Restaurar o dump não devolve o serviço. Estes itens ficam de fora e precisam de proteção própria:

• Usuários, papéis e permissões — dependendo do comando, ficam fora do dump de uma base específica.
• Configuração do servidor — parâmetros ajustados, regras de acesso por rede, certificados.
• Extensões instaladas e suas versões.
• Tarefas agendadas dentro do banco.
• Configuração de replicação e dos nós secundários.
• Objetos grandes guardados fora das tabelas, conforme a opção usada.
• Arquivos referenciados pelo banco mas armazenados em disco ou em storage de objetos.
• A versão exata do banco e das extensões — restaurar em versão diferente pode falhar ou mudar comportamento.

Por isso a orientação: o backup do banco inclui a configuração do servidor, versionada em repositório. Restaurar dado num servidor configurado diferente do original produz um banco que funciona e se comporta de outro jeito — lento, ou recusando conexões que antes aceitava.

Consistência: o detalhe que invalida backup

Alguns pontos que produzem backup inútil sem aviso:

Cópia de arquivo com o banco ligado, sem o procedimento correto. Copiar o diretório de dados de um banco em execução, sem colocá-lo em modo de backup ou usar a ferramenta apropriada, gera arquivos inconsistentes. Pode restaurar e parecer funcionar, e apresentar corrupção depois.

Snapshot de VM como backup de banco. Snapshot captura o disco naquele instante; o que estava em memória ainda não gravado se perde. Para um banco, isso significa restaurar e depender do mecanismo de recuperação dele. Funciona na maioria das vezes — e "na maioria das vezes" não é um plano. Se for usar snapshot de VM, use o agente de convidado para congelar o sistema de arquivos, e mantenha o dump lógico além disso.

Múltiplos bancos com dependência entre si. Se o pedido está num banco e o pagamento em outro, backups tirados em momentos diferentes produzem um estado que nunca existiu. É preciso coordenar, ou aceitar e documentar a inconsistência possível.

Onde o backup mora

A regra 3-2-1 vale integralmente: três cópias, em dois meios, uma fora do local.

E um item que deixou de ser opcional: cópia imutável. Ransomware moderno procura e destrói backup antes de cifrar, e credencial de backup é alvo prioritário. Uma cópia com bloqueio de exclusão por período — em storage de objetos com essa capacidade, ou em mídia desconectada — é o que garante que exista algo para restaurar.

Complementos que importam:

• Cifragem em repouso e em trânsito. Backup de banco é a cópia mais concentrada de dado sensível que a empresa tem.
• Credencial de backup separada, com permissão apenas de escrita no destino. Se o servidor for comprometido, o atacante não deve conseguir apagar o histórico.
• Retenção escalonada: diários por semanas, semanais por meses, mensais por mais tempo. É o que cobre corrupção descoberta tarde.

O teste que transforma hipótese em garantia

Backup nunca restaurado é uma pasta com nome bonito. O teste precisa ser real e periódico:

1. Restaure em servidor limpo, não no original.
2. Cronometre. Esse número é o seu RTO real — e costuma surpreender.
3. Valide o dado, não só a conclusão do comando: contagem de linhas nas tabelas principais, últimas transações presentes, aplicação subindo contra o banco restaurado.
4. Teste a recuperação a um ponto no tempo escolhendo um instante arbitrário, não só o último backup.
5. Documente o procedimento com comandos exatos, para que não dependa de quem montou.
6. Repita a cada trimestre e depois de toda mudança relevante de versão ou volume.

O passo 2 é o que mais gera decisão. Muito time descobre que restaurar leva oito horas quando o acordo interno dizia duas — e a correção não é mudar o backup, é mudar a arquitetura ou o acordo.

O checklist

1. RPO e RTO escritos e acordados com o negócio.
2. Backup físico com arquivamento contínuo, permitindo ponto no tempo.
3. Dump lógico periódico para restauração seletiva e migração.
4. Configuração do servidor versionada em repositório.
5. Usuários e permissões incluídos.
6. Cópia fora do local, cifrada.
7. Cópia imutável, protegida contra exclusão.
8. Credencial de backup com permissão mínima, separada da do banco.
9. Retenção escalonada cobrindo corrupção descoberta tarde.
10. Verificação automática de integridade.
11. Restauração testada, cronometrada e documentada.
12. Alerta quando o backup falha — e quando ele não roda, que é a falha silenciosa mais comum.

O item 12 merece nota: monitorar falha de backup é fácil; monitorar ausência de backup exige verificar que existe cópia recente. Job que parou de ser agendado não gera erro nenhum.

Erros comuns

• Dump diário como única proteção.
• RPO e RTO nunca escritos.
• Backup no mesmo servidor ou no mesmo storage do banco.
• Nenhuma cópia imutável, vulnerável a ransomware.
• Copiar arquivos do banco em execução sem o procedimento correto.
• Contar com snapshot de VM sem agente de convidado nem dump lógico.
• Esquecer usuários, permissões e configuração do servidor.
• Retenção curta demais para corrupção descoberta semanas depois.
• Nunca ter restaurado, e não saber quanto tempo leva.
• Credencial de backup com permissão de exclusão no destino.
• Alertar só quando o backup falha, e não quando ele deixa de rodar.
• Procedimento na cabeça de uma pessoa só.

Onde a Solvefy/Cloud entra

Backup de banco é uma das primeiras coisas que revisamos em consultoria — e a mais frequente fonte de surpresa desagradável. Implantamos o desenho completo: backup físico com recuperação a ponto no tempo, dump lógico complementar, configuração versionada, cópia externa cifrada e imutável, credencial com permissão mínima, retenção escalonada, verificação automática e alerta de ausência. E executamos o teste de restauração com você, cronometrado, para que o RTO deixe de ser estimativa. PostgreSQL, MariaDB, MongoDB e Redis.

Você sabe quanto tempo leva para voltar o seu banco? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.