DBAtlas · Atlas de operações de banco de dados

Backups automatizados (pgBackRest/Barman/Xtrabackup/cron)

Sintoma

Objetivo: automatizar os backups do banco; montar uma cadeia de recuperação confiável com full + incremental + arquivamento de WAL/binlog agendados, retenção, verificação e uma cópia offsite.

1. Escolha a ferramenta de backup certa

Escolha uma ferramenta para o seu engine: pgBackRest ou Barman para PostgreSQL (backup físico + arquivo de WAL + PITR); Percona XtraBackup (backup físico online) para MySQL/MariaDB, ou mysqldump/mydumper (lógico) para conjuntos de dados pequenos. Ferramentas físicas dão backups rápidos e consistentes + recuperação point-in-time em bancos grandes; dumps lógicos são portáveis, mas lentos com muitos dados.

PostgreSQL

# pgBackRest or Barman

MySQL

# physical: xtrabackup
# logical: mysqldump / mydumper

2. Monte a cadeia full + incremental + arquivamento contínuo

Configure a recuperação point-in-time com backups full semanais/diários, backups incrementais/diferenciais entre eles e arquivamento contínuo de WAL (PostgreSQL) ou binlog (MySQL). O pgBackRest gerencia os tipos de backup full/diff/incremental e o arquivo de WAL; no PostgreSQL você aponta o archive_command para o pgBackRest. Backups incrementais + arquivo permitem voltar a qualquer ponto no tempo.

PostgreSQL

# postgresql.conf
archive_mode = on
archive_command = 'pgbackrest --stanza=appdb archive-push %p'

# full backup
pgbackrest --stanza=appdb --type=full backup
# incremental
pgbackrest --stanza=appdb --type=incr backup

MySQL

# full
xtrabackup --backup --target-dir=/backup/full
# incremental
xtrabackup --backup --target-dir=/backup/incr1 \
  --incremental-basedir=/backup/full

3. Agende os backups com cron/timer

Execute os comandos de backup regularmente com cron ou um timer do systemd: por exemplo, um backup full na noite de domingo e incrementais nas outras noites. Agende fora do horário comercial e garanta que os jobs full e incr não se sobreponham. Grave os logs de saída em algum lugar e gere um alerta em caso de falha.

PostgreSQL

# crontab
0 1 * * 0 pgbackrest --stanza=appdb --type=full backup
0 1 * * 1-6 pgbackrest --stanza=appdb --type=incr backup

4. Defina uma política de retenção

Não acumule backups para sempre; defina quantos backups full e quantos dias de arquivos manter, e deixe a ferramenta expirar os antigos automaticamente. No pgBackRest isso é gerenciado com repo1-retention-full e as configurações de retenção de arquivo; no Barman, com retention_policy. A retenção precisa estar de acordo com seus objetivos de recuperação (quantos dias para trás você precisa voltar).

PostgreSQL

# pgbackrest.conf
[global]
repo1-retention-full=4
repo1-retention-archive=8

MySQL

# purge old backups with cron (example)
find /backup -type d -mtime +14 -exec rm -rf {} +

5. Copie os backups para fora (offsite) / para o S3

Os backups não devem ficar na mesma máquina/região que o banco; copie-os para outro local ou object storage (S3, GCS). O pgBackRest pode gravar direto em armazenamento compatível com S3; caso contrário, sincronize com um destino offsite usando rsync/rclone. Em um desastre (perda do disco/região local), só a cópia offsite vai salvar você.

PostgreSQL

# pgbackrest.conf S3 repository
[global]
repo1-type=s3
repo1-s3-bucket=company-backup
repo1-s3-region=eu-central-1
repo1-s3-endpoint=s3.eu-central-1.amazonaws.com

6. Verifique o backup

Um backup existir não significa que ele possa ser restaurado; verifique a integridade regularmente. No pgBackRest, o comando 'verify' e as verificações de consistência do arquivo, e no XtraBackup uma etapa de prepare (--prepare) bem-sucedida, mostram que o backup está íntegro. Execute a verificação automaticamente após cada backup e gere um alarme em caso de falha.

PostgreSQL

pgbackrest --stanza=appdb verify

MySQL

# make the backup consistent (verification)
xtrabackup --prepare --target-dir=/backup/full

7. Faça exercícios de restore regulares

A etapa mais crítica: periodicamente, restaure DE VERDADE o backup em um servidor separado e verifique se o banco abre e se os dados estão consistentes. Esse exercício permite medir seu tempo de recuperação (RTO) e encontrar falhas no procedimento fora de um incidente. Backup não testado não é backup.

PostgreSQL

# restore + PITR on a separate server
pgbackrest --stanza=appdb \
  --type=time --target="2026-07-01 03:00:00" restore

MySQL

# copy the prepared backup back to the data directory
xtrabackup --copy-back --target-dir=/backup/full
Abrir no DBAtlas →