Backup de PostgreSQL e MySQL: Boas Práticas para Empresas

Por que backup de banco de dados exige cuidado especial

Em quase toda empresa, o banco de dados é o ativo mais crítico da operação. É nele que ficam pedidos, notas fiscais, cadastros de clientes, estoque e histórico financeiro. Um servidor de arquivos danificado costuma causar transtorno. Um banco de dados corrompido ou apagado pode parar a empresa inteira. Mesmo assim, é comum encontrar PostgreSQL e MySQL protegidos só por uma cópia da pasta de dados feita pelo backup do sistema operacional, sem nenhuma garantia de que ela possa ser restaurada.

O problema é que um banco em uso está sempre escrevendo. Se você copia os arquivos do diretório de dados enquanto o serviço está ativo, sem usar as ferramentas próprias do banco, a cópia pode sair inconsistente: páginas gravadas pela metade, transações incompletas e índices que não batem com as tabelas. Esse backup parece existir, ocupa espaço e aparece como "concluído" no relatório, mas falha justamente no dia em que precisa funcionar.

Antes de escolher uma ferramenta, defina dois números com a área de negócio. O RPO (Recovery Point Objective) é quanto dado a empresa aceita perder: um dia, uma hora ou poucos segundos. O RTO (Recovery Time Objective) é quanto tempo o sistema pode ficar fora do ar até ser restaurado. São esses números que determinam se um dump noturno basta ou se você precisa de backup físico com recuperação pontual (PITR).

Backup lógico: pg_dump, mysqldump e quando usar

O backup lógico exporta o conteúdo do banco em comandos SQL ou em um formato próprio da ferramenta. No PostgreSQL, o padrão é o pg_dump, que gera uma cópia consistente de um banco mesmo com usuários conectados. O formato custom (-Fc) ou o formato diretório (-Fd, que permite paralelismo com -j) são os mais indicados, porque permitem restaurar tabelas específicas com pg_restore. Para objetos globais, como roles e tablespaces, complemente com pg_dumpall --globals-only. Sem isso, a restauração falha por falta de usuários e permissões.

No MySQL, o mysqldump continua sendo a opção mais conhecida. Em tabelas InnoDB, use sempre --single-transaction para obter uma cópia consistente sem travar a escrita, além de --routines, --triggers e --events para não perder procedures e eventos agendados. Em bases maiores, o MySQL Shell (util.dumpInstance()) e o mydumper fazem a exportação e a importação em paralelo e reduzem bastante o tempo. O antigo mysqlpump foi descontinuado e removido nas versões recentes, então não vale a pena adotá-lo agora.

O backup lógico tem vantagens claras:

• Funciona entre versões diferentes do banco, o que ajuda em migrações e upgrades;
• Permite restaurar só uma tabela ou um schema;
• É fácil de entender, de conferir e de mover entre servidores.

O ponto fraco é a escala. Em bancos de centenas de gigabytes, tanto o dump quanto a restauração podem levar horas, porque os índices precisam ser reconstruídos do zero. Além disso, o dump representa um único momento no tempo: se ele roda à meia-noite e o problema acontece às 17h, tudo o que foi gravado durante o dia se perde. Por isso o backup lógico funciona bem como camada complementar, mas raramente atende sozinho a um RPO exigente.

Backup físico e PITR: recuperando até o segundo exato

O backup físico copia os arquivos de dados do banco de forma coordenada com o próprio motor, garantindo consistência. No PostgreSQL, a ferramenta nativa é o pg_basebackup. Em produção, porém, a maioria das equipes usa soluções mais completas, como pgBackRest, Barman ou WAL-G, que oferecem backups incrementais, compressão, criptografia, política de retenção e envio para armazenamento em objeto (S3 ou compatível).

O grande diferencial do backup físico é a recuperação pontual (PITR — Point-in-Time Recovery). No PostgreSQL, todo o histórico de alterações passa pelo WAL (Write-Ahead Log). Com o arquivamento contínuo dos segmentos de WAL ativo (archive_mode = on e um archive_command ou a ferramenta de backup cuidando disso), você restaura o backup base e reaplica os logs até um instante específico, definido em recovery_target_time. Na prática, se alguém rodou um DELETE sem WHERE às 14h32, dá para voltar o banco para 14h31.

No MySQL, a lógica é a mesma, só que com peças diferentes. O backup físico a quente é feito com Percona XtraBackup (gratuito) ou com o MySQL Enterprise Backup. O papel do WAL fica com o binary log (binlog), que precisa estar habilitado e retido por tempo suficiente. Para o PITR, você restaura o backup físico e reaplica os binlogs com mysqlbinlog, parando na posição ou no horário anterior ao incidente (--stop-datetime ou --stop-position).

Backup sem arquivamento de logs é uma fotografia. Backup com WAL ou binlog arquivado é um filme: você escolhe o quadro exato para onde quer voltar.

Um cuidado importante: os logs arquivados valem tanto quanto o backup base. Se um único segmento de WAL ou arquivo de binlog se perder no meio da cadeia, a recuperação para naquele ponto. Monitore o arquivamento: falhas silenciosas no archive_command também enchem o disco do servidor e podem derrubar o banco.

Replicação não é backup

Muitas empresas acreditam estar protegidas porque têm uma réplica do banco em outro servidor. A replicação, seja streaming replication no PostgreSQL ou replicação por binlog/GTID no MySQL, é excelente para alta disponibilidade: se o servidor principal cair, a réplica assume em minutos. Mas ela copia tudo, inclusive os erros.

Um DROP TABLE acidental, um bug de aplicação que sobrescreve registros ou um ransomware que cifra os dados chega à réplica em milissegundos. Nesses casos, ter dois servidores significa apenas ter duas cópias do mesmo problema. Réplicas com atraso proposital (recovery_min_apply_delay no PostgreSQL, SOURCE_DELAY no MySQL) dão uma janela para reagir, mas continuam não substituindo um backup com retenção e histórico.

A estratégia madura combina as camadas:

• Replicação para continuidade e failover rápido;
• Backup físico com PITR para recuperar de erros humanos e corrupção com perda mínima;
• Backup lógico periódico para restaurações seletivas, migrações e uma cópia independente do formato físico;
• Cópia fora do ambiente principal, preferencialmente imutável, contra ransomware e desastres no data center.

Boas práticas de armazenamento, segurança e teste de recuperação

Onde o backup fica guardado importa tanto quanto a forma de gerá-lo. A regra 3-2-1 continua sendo a referência: três cópias dos dados, em duas mídias diferentes, com uma delas fora do local principal. Hoje se fala também em 3-2-1-1-0: uma cópia imutável ou offline e zero erros na verificação. Ataques de ransomware procuram ativamente os repositórios de backup, então guardá-los no mesmo servidor ou com as mesmas credenciais do banco é um risco sério.

Checklist de boas práticas para bancos de produção:

1. Criptografe os backups em repouso e em trânsito. Um dump esquecido em um bucket público é um vazamento de dados, com impacto direto na LGPD.
2. Restrinja o acesso: use um usuário de backup dedicado, com privilégios mínimos, e credenciais separadas para o repositório.
3. Defina retenção alinhada ao negócio e a exigências legais e fiscais, com expurgo automático.
4. Monitore e alerte: backup que falhou sem avisar ninguém é o cenário mais comum de desastre.
5. Documente o procedimento de restauração passo a passo, para que qualquer técnico da equipe consiga executá-lo sob pressão.
6. Teste a recuperação regularmente, em ambiente isolado, e meça o tempo real.

O último item é o mais negligenciado e o mais importante. Um backup só existe de verdade depois de ter sido restaurado com sucesso. Automatize testes periódicos: suba o backup em uma VM ou container temporário, execute consultas de validação (contagem de registros nas tabelas críticas, checagem com pg_amcheck no PostgreSQL ou CHECK TABLE no MySQL) e compare o tempo gasto com o RTO definido. Se a restauração leva seis horas e o negócio tolera duas, o problema precisa ser resolvido agora, não durante um incidente.

A pergunta certa não é "temos backup?", e sim "quando foi a última vez que restauramos esse backup e quanto tempo levou?".

Como a Duk pode ajudar a proteger seus bancos de dados

Montar uma estratégia de backup confiável para PostgreSQL e MySQL envolve escolher ferramentas, configurar o arquivamento de logs, dimensionar armazenamento, criptografar, monitorar e, principalmente, testar a recuperação com disciplina. Para muitas empresas, manter esse ciclo funcionando no dia a dia, ao lado de todas as outras demandas de TI, é o maior desafio.

A Duk Informática & Cloud atua há mais de 18 anos como parceira de TI de mais de 550 empresas, com data center próprio em Alphaville e certificação Microsoft Gold Partner. Nossa equipe desenha a política de backup a partir do RPO e do RTO do seu negócio, implementa backup físico com PITR e cópias lógicas complementares, mantém cópias externas e imutáveis contra ransomware e realiza testes periódicos de restauração com relatório de resultado.

Se você não tem certeza de que conseguiria recuperar seu banco de dados hoje, com pouca perda e dentro do prazo que a operação exige, esse é o momento de revisar sua estratégia. Fale com a Duk e descubra como proteger os dados mais importantes da sua empresa com monitoramento contínuo e suporte especializado.