Backups automatizados (pgBackRest/Barman/Xtrabackup/cron)

Síntoma

Objetivo: automatizar los backups de la base de datos; construir una cadena de recuperación fiable con archivado programado completo+incremental+WAL/binlog, retención, verificación y una copia fuera del sitio.

1. Elija la herramienta de backup adecuada

Elija una herramienta para su motor: pgBackRest o Barman para PostgreSQL (backup físico + archivo de WAL + PITR); Percona XtraBackup (backup físico en línea) para MySQL/MariaDB, o mysqldump/mydumper (lógico) para conjuntos de datos pequeños. Las herramientas físicas ofrecen backups rápidos y consistentes + recuperación a un punto en el tiempo en bases de datos grandes; los dumps lógicos son portables pero lentos con datos grandes.

PostgreSQL

# pgBackRest or Barman

MySQL

# physical: xtrabackup
# logical: mysqldump / mydumper

2. Construya la cadena completo + incremental + archivado continuo

Configure la recuperación a un punto en el tiempo con backups completos semanales/diarios, backups incrementales/diferenciales entre ellos y archivado continuo de WAL (PostgreSQL) o binlog (MySQL). pgBackRest gestiona los tipos de backup full/diff/incremental y el archivo de WAL; en PostgreSQL se apunta archive_command a pgBackRest. Los backups incrementales + el archivo permiten volver a cualquier punto en el tiempo.

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. Programe los backups con cron/timer

Ejecute los comandos de backup con regularidad mediante cron o un timer de systemd: por ejemplo, un backup completo el domingo por la noche e incrementales las demás noches. Prográmelos fuera del horario laboral y asegúrese de que los jobs full e incr no se solapen. Escriba los logs de salida en algún lugar y genere una alerta en caso de fallo.

PostgreSQL

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

4. Defina una política de retención

No acumule backups indefinidamente; defina cuántos backups completos y cuántos días de archivos conservar, y deje que la herramienta expire automáticamente los antiguos. En pgBackRest se gestiona con repo1-retention-full y la configuración de retención del archivo; en Barman con retention_policy. La retención debe ajustarse a sus objetivos de recuperación (cuántos días atrás necesita poder volver).

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 los backups fuera del sitio / a S3

Los backups no deben quedarse en la misma máquina/región que la base de datos; cópielos a otra ubicación o a un almacenamiento de objetos (S3, GCS). pgBackRest puede escribir directamente en almacenamiento compatible con S3; de lo contrario, sincronice con un destino fuera del sitio mediante rsync/rclone. Ante un desastre (pérdida del disco local/de la región), solo la copia fuera del sitio lo salvará.

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 el backup

Que exista un backup no significa que pueda restaurarse; verifique la integridad con regularidad. En pgBackRest, el comando 'verify' y las comprobaciones de consistencia del archivo, y en XtraBackup un paso prepare (--prepare) exitoso, demuestran que el backup es válido. Ejecute la verificación automáticamente después de cada backup y genere una alarma en caso de fallo.

PostgreSQL

pgbackrest --stanza=appdb verify

MySQL

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

7. Realice simulacros de restauración periódicos

El paso más crítico: restaure REALMENTE el backup de forma periódica en un servidor aparte y verifique que la base de datos abre y que los datos son consistentes. Este simulacro le permite medir su tiempo de recuperación (RTO) y detectar fallas en el procedimiento fuera de un incidente. Un backup no probado no es un 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 en DBAtlas →