Backup profesional con WAL-G y pgBackRest

Un backup que no se ha probado restaurando es un backup que no existe. Esta lección va más allá de pg_dump y pg_basebackup para presentar las herramientas profesionales que usan equipos serios: WAL-G y pgBackRest, ambas open source y maduras.

Limitaciones de pg_dump y pg_basebackup

Las herramientas básicas tienen su lugar pero se quedan cortas en producción real:

• pg_dump: produce un dump lógico, válido para migraciones entre versiones distintas. Lento y no permite PITR. No copia tablespaces ni WAL.
• pg_basebackup: copia física del cluster. Útil para inicializar réplicas. No comprime ni divide en chunks, no gestiona retención automáticamente, no verifica integridad.

Para entornos con bases de datos de cientos de GB o varios TB, las limitaciones se vuelven inaceptables: backups que tardan horas, falta de paralelismo, almacenamiento sin organizar.

WAL-G: backups eficientes a S3

WAL-G es la herramienta más popular para backup de PostgreSQL a almacenamiento de objetos. Soporta S3, GCS, Azure Blob, Swift y filesystem local. Características clave:

• Compresión paralela con LZ4, Brotli, ZSTD.
• Backups delta (solo los bloques cambiados desde el último full).
• Verificación con wal-verify.
• Soporte de encriptación libsodium.
• Funciona también con MySQL, FoundationDB y otros.

Configuración mediante variables de entorno:

export WALG_S3_PREFIX="s3://mi-bucket/postgres/cluster-prod"
export AWS_REGION="eu-west-1"
export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."
export WALG_COMPRESSION_METHOD="zstd"
export WALG_DELTA_MAX_STEPS="6"

En postgresql.conf:

archive_mode = on
archive_command = 'wal-g wal-push %p'
restore_command = 'wal-g wal-fetch %f %p'

Los comandos básicos:

# Backup base completo (puede ser delta si hay full reciente)
wal-g backup-push /var/lib/postgresql/data

# Listar backups disponibles
wal-g backup-list

# Eliminar backups antiguos (mantener los 7 ultimos)
wal-g delete retain 7 --confirm

# Verificar integridad de los WAL archivados
wal-g wal-verify integrity

WAL-G es ideal para deployments cloud-native donde el almacenamiento de objetos es nativo del proveedor. La configuración es mínima y la integración con S3 funciona sin sobresaltos.

pgBackRest: el ecosistema completo

pgBackRest es una solución más completa, con archivo de configuración estructurado, múltiples stanzas (clusters), políticas de retención sofisticadas y dashboards de estado. Es la opción típica en entornos on-premise o cuando se necesita más control.

Configuración en /etc/pgbackrest/pgbackrest.conf:

[global]
repo1-path=/var/lib/pgbackrest
repo1-retention-full=2
repo1-retention-diff=14
repo1-cipher-type=aes-256-cbc
repo1-cipher-pass=<clave_simetrica>
repo1-s3-bucket=mi-bucket
repo1-s3-endpoint=s3.eu-west-1.amazonaws.com
repo1-s3-region=eu-west-1
repo1-s3-key=<aws_access_key>
repo1-s3-key-secret=<aws_secret_key>
repo1-type=s3
process-max=4
compress-type=zst
compress-level=3

[produccion]
pg1-path=/var/lib/postgresql/data
pg1-port=5432
pg1-user=postgres

En postgresql.conf:

archive_mode = on
archive_command = 'pgbackrest --stanza=produccion archive-push %p'

Crear el stanza, hacer backup full y luego diferenciales:

# Crear el stanza por primera vez
sudo -u postgres pgbackrest --stanza=produccion stanza-create

# Backup full (semanal)
sudo -u postgres pgbackrest --stanza=produccion --type=full backup

# Backup diferencial (diario)
sudo -u postgres pgbackrest --stanza=produccion --type=diff backup

# Backup incremental (cada hora)
sudo -u postgres pgbackrest --stanza=produccion --type=incr backup

# Listar backups
sudo -u postgres pgbackrest --stanza=produccion info

# Verificar integridad
sudo -u postgres pgbackrest --stanza=produccion verify

pgBackRest combina paralelismo, encriptación y backups incrementales reales por bloque en un binario muy estable. Es la elección de la mayoría de DBAs senior por su robustez.

Restauración estándar

Restaurar un backup a un nuevo servidor con WAL-G:

# Apagar PostgreSQL en el destino
systemctl stop postgresql

# Vaciar el directorio de datos
rm -rf /var/lib/postgresql/data/*

# Descargar el ultimo backup
wal-g backup-fetch /var/lib/postgresql/data LATEST

# Configurar recovery (PostgreSQL 12+)
touch /var/lib/postgresql/data/recovery.signal
echo "restore_command = 'wal-g wal-fetch %f %p'" >> /var/lib/postgresql/data/postgresql.auto.conf

# Arrancar PostgreSQL
systemctl start postgresql

Lo mismo con pgBackRest:

sudo -u postgres pgbackrest --stanza=produccion --delta restore

La opción --delta solo copia los bloques que han cambiado, acelerando enormemente la recuperación si el destino ya tiene una copia parcial.

Point-in-Time Recovery (PITR)

PITR permite restaurar a un instante específico, útil tras un borrado lógico. El procedimiento:

• 1. Backup base reciente disponible.
• 2. WAL archivado continuamente desde la fecha del backup hasta el momento del incidente.
• 3. Restaurar el backup base y aplicar WAL hasta el punto deseado.

Con WAL-G:

# Restaurar el backup mas reciente anterior a un timestamp
wal-g backup-fetch /var/lib/postgresql/data LATEST

# Configurar PITR
cat <<EOF >> /var/lib/postgresql/data/postgresql.auto.conf
restore_command = 'wal-g wal-fetch %f %p'
recovery_target_time = '2026-04-15 14:32:00 UTC'
recovery_target_action = 'promote'
EOF

touch /var/lib/postgresql/data/recovery.signal
systemctl start postgresql

Con pgBackRest:

sudo -u postgres pgbackrest --stanza=produccion \
    --type=time --target="2026-04-15 14:32:00+00" \
    --target-action=promote \
    restore

PostgreSQL aplica WAL incrementalmente hasta llegar al recovery_target_time y entonces se promueve. Verificar con:

SELECT pg_last_wal_replay_lsn(), pg_is_in_recovery();
SELECT * FROM tabla_critica WHERE id = 42;

Verificación periódica de backups

La parte que más se descuida. Probar la restauración mensualmente es lo que separa un sistema operacional sólido de uno que descubre que sus backups están corruptos el día que los necesita.

Un job típico en CI o cron:

#!/bin/bash
# verify_backup.sh - Restauracion de prueba en servidor temporal

set -e
TEMP_DIR=$(mktemp -d)
wal-g backup-fetch "$TEMP_DIR" LATEST
pg_ctl -D "$TEMP_DIR" start -o "-p 15432"

# Validar tablas criticas
psql -p 15432 -d produccion -c \
    "SELECT COUNT(*) AS clientes FROM clientes;"

pg_ctl -D "$TEMP_DIR" stop
rm -rf "$TEMP_DIR"
echo "Backup verificado correctamente"

Si esta verificación se incluye en la pipeline de CI semanal, los problemas se descubren con tiempo para corregirlos antes de necesitar la restauración real.

Comparativa rápida

| Aspecto | WAL-G | pgBackRest | |---------|-------|------------| | Setup | Variables de entorno | Fichero conf estructurado | | Storage | S3, GCS, Azure, FS | S3, Azure, GCS, FS, SFTP | | Backup incremental | Delta (bloques) | Diff y incr | | Encriptación | libsodium | AES-256 | | Multi-stanza | Por proceso | Nativo | | Verificación | wal-verify | verify completo | | Madurez | Alta | Muy alta | | Mejor para | Cloud-native | On-prem y mixto |

Estrategia 3-2-1

La regla operacional clásica de backups, que ambas herramientas facilitan:

• 3 copias de los datos (producción + 2 backups).
• 2 medios distintos (disco local + S3, por ejemplo).
• 1 copia fuera del sitio principal (otra región, otro proveedor).

flowchart LR
    A[PostgreSQL primario] --> B[WAL continuo]
    A --> C[Backup base diario]
    B --> D[(S3 region principal)]
    C --> D
    D --> E[(S3 region DR<br/>replicada)]
    F[Verify mensual] --> G[Restauracion en sandbox]
    G --> H{Tablas criticas OK?}
    H -->|No| I[Alarma]
    H -->|Si| J[Reporte verde]

Cualquier estrategia profesional de backup combina automatización, verificación periódica y almacenamiento geográficamente distribuido. WAL-G y pgBackRest cubren todos los aspectos técnicos; la operación sigue siendo responsabilidad del equipo.