Backup PostgreSQL e MySQL em Produção: Além do Dump (Cloud Brasileira 2026)

Todo DBA aprende pg_dump e mysqldump no primeiro dia. Depois descobre em produção que dump sozinho é insuficiente: perde-se horas de transação, restore trava lock em tabela gigante, arquivo cresce mais que disco. Este guia mostra o que fazer além do dump pra que seu backup sobreviva a ransomware, disco quebrado ou operador que deletou a tabela errada.

Por que pg_dump/mysqldump sozinho não é backup de produção

pg_dump e mysqldump geram dump lógico: SQL puro com CREATE TABLE + INSERT INTO. Fácil de restaurar, portátil entre versões. Limitações reais:

• RPO alto: dump diário significa perder até 24h de transação se der problema pouco antes do próximo
• Lock leve mas real: em tabelas grandes, dump segura ACCESS SHARE lock por horas — DDL fica travado
• Restore lento: SQL sendo re-executado linha a linha. Base de 500GB pode levar 6-12h pra voltar. Pra ERP em produção, isso é fim de semana perdido
• Sem PITR: você só pode voltar até o momento exato do dump, não pra 14:23 de terça quando alguém rodou o DELETE errado
• Sem verificação: dump que grava OK pode não restaurar por corrupção sutil. Backup nunca testado é apenas esperança

As 3 camadas de backup sério pra Postgres/MySQL

Camada 1 — Snapshot completo periódico

Dump lógico ou físico agendado (diário ou semanal). Serve pra restore total em máquina nova.

• Postgres: pg_basebackup gera cópia binária consistente (mais rápido que pg_dump); pgBackRest automatiza com compressão e paralelismo
• MySQL/MariaDB: Percona XtraBackup gera backup físico hot (sem lock global); MyDumper é dump lógico paralelo

Camada 2 — WAL/binlog archiving contínuo (PITR)

Aqui mora a diferença entre "backup" e "backup de produção":

• Postgres: WAL (Write-Ahead Log) archiving copia cada segmento de log conforme fecha. Junto com pg_basebackup, permite Point-in-Time Recovery: "restaura banco no estado de 14:23:45 de terça". Configuração: archive_mode = on, archive_command apontando pra Object Storage ou disco fora do servidor
• MySQL: binlog em row-based format cumpre função equivalente. Cópia contínua com mysqlbinlog --raw --read-from-remote-server. Restore com mysqlbinlog aplicando eventos até timestamp exato

Sem PITR, sua janela de perda é o intervalo do dump. Com PITR, janela cai pra ~1 minuto (o tempo pro WAL/binlog ser copiado).

Camada 3 — Cópia off-site com Object Lock anti-ransomware

Backup no mesmo servidor de produção não é backup — é conveniência. Backup precisa estar geograficamente separado E imutável durante janela de retenção.

• Off-site: cópia em Object Storage S3-compatível em datacenter diferente. Regra 3-2-1-1-0: 3 cópias, 2 mídias, 1 off-site, 1 offline/imutável, 0 erros na verificação
• Object Lock: modo Compliance ou Governance impede que backup seja deletado — mesmo por admin com credencial vazada — durante retention definido. Isso é o que salva de ransomware
• Sem cobrança de egress: cópia dentro do BR não gera fatura cambial surpresa como no S3 gringo

RTO e RPO real: definir antes de escolher ferramenta

RTO (Recovery Time Objective) = tempo aceitável pra ficar fora do ar. RPO (Recovery Point Objective) = quanto de dado aceitável perder.

Cenário	RTO típico	RPO típico	Estratégia mínima
SaaS 24/7 crítico	< 1h	< 5 min	Réplica streaming quente + PITR + snapshot Object Storage
ERP horário comercial	4-8h	< 15 min	Dump diário + WAL/binlog archiving contínuo
Sistema interno	24h	< 1h	Dump diário + verificação semanal de restore
Dev / staging	72h	1 dia	Dump semanal em Object Storage

Erro comum: contratar backup "premium" pra sistema interno com RTO 24h aceitável. Custo excessivo. Ou o oposto: backup diário simples pra SaaS 24/7. Perda gigantesca no primeiro incidente.

Stack recomendado pra Postgres em produção BR

Combinação testada por Audaks pra cliente B2B brasileiro:

1. pgBackRest como orquestrador — full/differential/incremental automatizado, compressão, paralelismo
2. Repositório em Object Storage S3-compatível BR (bucket dedicado com Object Lock ativado)
3. WAL archiving contínuo pro mesmo repositório (retention 7-30 dias conforme RPO)
4. Réplica streaming em outro servidor pra HA + read-only
5. Verificação automatizada: pgbackrest verify semanal + restore de teste mensal em máquina descartável
6. Alerta ligado a chamado: se WAL archive falha por >10 min, chama engineer

Stack recomendado pra MySQL/MariaDB em produção BR

1. Percona XtraBackup pra backup físico hot (sem lock global de leitura)
2. Binlog contínuo copiado pra Object Storage BR via mysqlbinlog --read-from-remote-server --raw --stop-never em processo daemon
3. Bucket Object Storage BR com Object Lock (governance ou compliance mode)
4. Réplica assíncrona em segundo servidor pra failover manual rápido
5. Verificação mensal: restore em máquina teste, roda queries de validação (COUNT, checksum agregado)

Backup imutável anti-ransomware: como funciona Object Lock

Ransomware moderno alveja backup antes de criptografar produção. Backup deletado = pagou resgate. Object Lock resolve:

• Modo Governance: só usuário com permissão especial pode remover antes da data. Bom pra maioria dos casos
• Modo Compliance: NINGUÉM (nem root, nem provedor) pode remover antes da data. Máxima segurança pra compliance regulado (Bacen, CFM)
• Retention: define até quando é imutável (ex: 30 dias). Backup mais antigo que retention pode ser removido normalmente

Compatível com Veeam, Restic, Rclone, pgBackRest, XtraBackup e ferramentas com integração S3. Ativar no bucket via API padrão S3.

5 erros comuns em backup de banco em produção

1. Nunca testar restore. Backup que gravou OK pode não voltar. Verificação semanal + drill mensal de restore em máquina descartável são obrigatórios.
2. Backup no mesmo storage da produção. Ransomware ou disco físico morto elimina ambos. Sempre off-site em Object Storage separado.
3. Sem WAL/binlog archiving. Dump diário = janela de perda de até 24h. Inviável pra maioria dos casos B2B.
4. Retention curto demais. Ransomware pode ficar dormente semanas. Retention de 7 dias descobre invasor após backup infectado ter sobrescrito o limpo. Mínimo recomendado: 30 dias com Object Lock.
5. Sem alerta em falha. Backup que falha silenciosamente por dias vira surpresa no dia do incidente. Alerta ligado a canal ativo (Slack, PagerDuty, chamado interno) é obrigatório.

Compliance: LGPD, Bacen, CFM — o que backup precisa provar

• LGPD (art. 46): medidas técnicas de segurança adequadas — backup criptografado, controle de acesso, log de operação, DPA no contrato
• Bacen (Resolução 4.893/2021): continuidade de negócio comprovada por drill periódico, RPO/RTO documentado, teste de restore anual mínimo
• CFM (Resolução 2.314/2022): prontuário eletrônico exige backup imutável com retention mínimo 20 anos pra registros médicos. Object Lock em Object Storage BR resolve nativo

Por que fazer backup em cloud brasileira em vez de S3 gringo

• Sem IOF nem câmbio: fatura em Real, dedutível como despesa operacional
• Latência baixa: cópia pra bucket em SP roda 10x mais rápido que pra us-east-1 quando produção também é BR
• Sem cobrança de egress interno: restore não gera fatura surpresa como no S3 gringo
• LGPD direta: dado permanece no BR sob ANPD, sem cláusula de transferência internacional
• Suporte em português: chamado durante incidente responde em português com engineer real

FAQ Backup PostgreSQL/MySQL produção

pgBackRest ou Barman: qual escolher pra Postgres?

Ambos maduros. pgBackRest tende a ser mais rápido em bases >500GB por compressão nativa + paralelismo agressivo. Barman tem gestão de múltiplos servidores centralizado. Regra: cluster único ou 2-3 servidores → pgBackRest; parque com 10+ Postgres → Barman.

Backup fica junto do banco na mesma VM. Basta?

Não. Serve como cópia de conveniência pra restore rápido de tabela apagada por engano, mas não protege de disco morto, VM comprometida ou ransomware. Sempre precisa cópia em Object Storage separado com Object Lock.

Retention 7 dias é suficiente?

Não pra ransomware. Invasor moderno pode ficar dormente 2-4 semanas antes de disparar. Se retention é 7 dias, backups limpos já foram sobrescritos pelos infectados. Mínimo recomendado: 30 dias com Object Lock. Ideal: 90 dias pra bases críticas.

Preciso replicar backup em outra região?

Depende do RTO. Pra ERP com RTO 8h aceitável, backup em SP com Object Lock geralmente basta. Pra SaaS 24/7 com RTO <1h, réplica sincronizada em segunda região BR é indicado. Audaks configura DR entre duas regiões BR sob demanda.

Quanto custa backup de banco de 200GB em cloud BR?

Object Storage BR sério cobra por GB armazenado ao mês. Faixa de mercado: R$ 0,10-0,30 por GB/mês. Base 200GB com retention 30 dias e Object Lock ficaria na casa de R$ 40-80/mês em Object Storage. Somando ferramenta (pgBackRest é gratuito) e transferência (interna BR sem custo), o TCO fica bem abaixo do equivalente AWS quando incluído câmbio + IOF.

Como testar restore sem afetar produção?

Provisione VM descartável, restaure backup lá, rode queries de validação (COUNT em tabelas críticas, checksum de tabelas de referência, teste de aplicação read-only). Automatize via script mensal — resultado vai pra log e alerta se falhar.

Backup gerenciado ou eu opero?

Se equipe tem DBA ou SRE sênior, self-hosted funciona bem (pgBackRest ou XtraBackup + Object Storage BR). Se equipe não tem, backup gerenciado por provedor BR sério vale a pena — engineer configura, monitora, alerta e faz drill mensal. Custo típico é 20-40% acima do self-service, mas remove risco operacional.

Próximos passos

• Backup em nuvem empresa BR: como escolher provedor sério
• Disaster Recovery em cloud brasileira: 3-2-1-1-0 implementado
• Backup em Nuvem Audaks — pgBackRest, XtraBackup, Veeam, Acronis compatíveis
• Object Storage S3 Audaks — Object Lock anti-ransomware nativo