Backup e recuperação
RPO, RTO e por que um backup que nunca foi restaurado não conta.
O problema: o dia em que os dados somem
Os dados se perdem de jeitos diferentes, e cada um pede uma defesa diferente:
| O que acontece | Réplica resolve? | Backup resolve? |
|---|---|---|
| O disco do servidor queima | Sim | Sim, mais devagar |
Um DELETE sem WHERE | Não: a réplica apaga junto, em milissegundos | Sim |
| Uma migração corrompe uma coluna | Não | Sim |
| Ransomware criptografa ou apaga o banco | Não | Sim, se o backup estiver fora do alcance do atacante |
| A conta da nuvem é comprometida ou encerrada | Não | Só se o backup estiver em outra conta |
A réplica, como mostra o tópico de replicação, protege contra a falha de uma máquina. Ela copia tudo, inclusive os erros. O backup é uma cópia dos dados num momento, guardada fora do banco, de onde se pode voltar.
RPO e RTO
Duas medidas definem o que o backup precisa garantir:
| Medida | Pergunta | Exemplo |
|---|---|---|
| RPO (recovery point objective) | Quantos dados o negócio aceita perder? | "No máximo 5 minutos de pedidos" |
| RTO (recovery time objective) | Quanto tempo o sistema pode ficar fora? | "No máximo 1 hora" |
Quem define os dois números é o negócio, e eles decidem a técnica. Um backup por noite tem RPO de até 24 horas: uma falha às 23h perde o dia inteiro.
Dump lógico
O dump lógico (pg_dump no PostgreSQL, mysqldump no MySQL) exporta os dados e o esquema como comandos ou num formato próprio. É simples, portátil entre versões, e permite restaurar uma tabela só. Medimos com um banco de 453 MB (200 mil clientes e 5 milhões de pedidos), num PostgreSQL 18 com 4 núcleos:
| Operação | Tempo | Tamanho |
|---|---|---|
pg_dump em formato custom (-Fc), comprimido | 6,0 s | 39 MB |
pg_dump em formato diretório com 4 processos (-Fd -j 4) | 5,5 s | — |
pg_restore com 1 processo | 11,5 s | — |
pg_restore com 4 processos (-j 4) | 9,8 s | — |
A restauração levou o dobro do dump, porque recria os índices e confere as chaves estrangeiras. Esses tempos crescem com o volume: um banco de 500 GB leva horas para restaurar, e esse é o RTO real, que ninguém conhece até medir.
O que o backup esqueceu
Restauramos o dump num servidor PostgreSQL novo, como num desastre de verdade:
| Restauração | Resultado |
|---|---|
| Só o dump do banco | Código de saída 1: role "app" does not exist, duas vezes. Os dados entraram, mas as tabelas ficaram com o dono postgres |
Antes, as definições globais (pg_dumpall --globals-only), depois o dump | Código de saída 0; o usuário app leu os 5 milhões de pedidos |
O pg_dump exporta um banco, e não o servidor: usuários, senhas e permissões ficam de fora. Restaurado sozinho, o banco volta com as tabelas, mas a aplicação, que entra como app, não consegue nem se conectar. É o tipo de problema que só aparece na primeira restauração, e a primeira restauração não pode ser no dia do desastre.
O mesmo vale para o que fica fora do banco: as configurações do servidor, as extensões instaladas, os segredos e as chaves de criptografia. Um backup criptografado com uma chave que se perdeu junto com o servidor não serve para nada.
Cópia física e recuperação num ponto do tempo
A outra forma é a cópia física: os arquivos do banco, copiados com o banco no ar (pg_basebackup no PostgreSQL), mais o arquivamento contínuo do log de transações (WAL), em que cada pedaço do log é copiado para fora assim que fica pronto. Com os dois, o banco pode ser restaurado para qualquer momento depois da cópia: a recuperação num ponto do tempo (point-in-time recovery, PITR).
Testamos o cenário que mais acontece:
- Cópia física do banco com 5 milhões de pedidos, conferida com
pg_verifybackup. - Mais 1.000 pedidos gravados depois da cópia.
- O horário anotado como o último momento bom; dois segundos depois, um
DELETEerrado apaga 4 milhões de pedidos. - Restauração da cópia física, reaplicando o log arquivado até o momento bom (
recovery_target_time).
| Pedidos | |
|---|---|
| Na cópia física | 5.000.000 |
Depois do DELETE errado | 998.001 |
| Depois da recuperação até o momento bom | 5.001.000 |
A recuperação levou 3,4 segundos e parou exatamente antes da transação do DELETE (o log registrou recovery stopping before commit of transaction 818). Os 1.000 pedidos gravados depois da cópia física voltaram, porque estavam no log arquivado. Um dump da noite anterior teria perdido esses pedidos e todos os outros do dia.
O RPO do arquivamento contínuo é o atraso do arquivamento: com o log enviado a cada minuto, perde-se no máximo um minuto.
Por que isso importa quando a IA escreve o código
Um assistente que configura backups costuma entregar o comando, e não a recuperação:
- Um
pg_dumppor noite, sem saber se o RPO de 24 horas é aceitável. - O backup no mesmo servidor, no mesmo disco ou na mesma conta da nuvem que o banco.
- Usuários, permissões e extensões fora do backup.
- Nenhuma restauração de teste, e nenhum RTO medido.
- Réplicas tratadas como backup.
- Backups que nunca expiram, ou que expiram antes do prazo legal de guarda.
O próximo nível compara as técnicas de backup e como organizar retenção, cópias fora do alcance e testes de restauração.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Backup e recuperação em cinco minutos
Explique em no máximo cinco minutos de leitura o essencial sobre backup e recuperação de bancos de dados, para alguém que nunca precisou restaurar um backup. Cubra só o essencial: por que réplicas não substituem backup, RPO e RTO, dump lógico e cópia física com o log arquivado, e por que um backup só vale depois de restaurado. Use o exemplo de um DELETE sem WHERE numa loja online. No final, me faça três perguntas curtas para eu verificar se entendi, e corrija as minhas respostas.
RPO, RTO e as técnicas de backup
Quero entender como RPO e RTO decidem a técnica de backup. Aja como um mentor e vá por etapas, esperando a minha resposta em cada uma: 1. O que são RPO e RTO, com exemplos de negócios diferentes. 2. O RPO e o RTO de um dump lógico diário. 3. Como a cópia física e o arquivamento contínuo do log permitem recuperar até um segundo antes de um erro. 4. Snapshots de disco e o cuidado com a consistência. 5. O que um banco gerenciado oferece e o que continua sendo responsabilidade minha. Em cada etapa, me descreva um negócio e peça que eu escolha a técnica.
As falhas que o backup precisa cobrir
Quero entender contra o que um backup protege e contra o que não protege. Explique, para cada caso, se réplica resolve, se backup resolve e o que mais é preciso: 1. Disco do servidor queimado. 2. DELETE errado ou migração que corrompe dados. 3. Ransomware que criptografa o banco e tenta apagar os backups. 4. Conta da nuvem comprometida. 5. Perda da chave de criptografia dos backups. Depois me descreva um incidente e pergunte o que eu faria, passo a passo.
Por que testar a restauração
Quero entender por que um backup que nunca foi restaurado não conta. Explique, com exemplos reais do que costuma faltar: 1. Usuários, permissões e extensões fora do dump. 2. Arquivos de log faltando no arquivamento. 3. Tempo de restauração muito maior que o esperado. 4. Chaves e senhas necessárias para restaurar. 5. Como montar uma restauração automática com verificação. Depois me peça para listar o que eu conferiria numa restauração de teste do meu sistema.