pgBackRest

Automatización de copias de seguridad físicas y PITR para clústeres PostgreSQL 18.4 autohospedados: configuración de stanza, archivado de WAL, simulacros de restauración e integración con Patroni.

Receta

Tarjeta de referencia rápida para la receta: lista para copiar y pegar.

# /etc/pgbackrest/pgbackrest.conf
[global]
repo1-type=s3
repo1-s3-bucket=pg-backups-prod
repo1-s3-region=us-east-1
repo1-retention-full=4
repo1-cipher-type=aes-256-cbc
 
[main]
pg1-path=/var/lib/postgresql/18/main
pg1-port=5432

pgbackrest --stanza=main stanza-create
pgbackrest --stanza=main backup --type=full
pgbackrest --stanza=main check

Cuándo usar esto:

• Postgres autohospedado en VMs o bare metal que necesita copias de seguridad cifradas en S3
• Requisitos de PITR con runbooks de restauración probados
• Clústeres Patroni donde las API de instantáneas administradas son insuficientes

Ejemplo de trabajo

Paso 1: Habilitar el archivado en PostgreSQL

ALTER SYSTEM SET archive_mode = on;
ALTER SYSTEM SET archive_command = 'pgbackrest --stanza=main archive-push %p';
SELECT pg_reload_conf();

# Verificar el flujo de archivo WAL
pgbackrest --stanza=main check

Paso 2: Cronograma de copia de seguridad programada

# /etc/cron.d/pgbackrest
0 2 * * 0 postgres pgbackrest --stanza=main backup --type=full
0 2 * * 1-6 postgres pgbackrest --stanza=main backup --type=diff

Paso 3: Simulacro de restauración en un host aislado

# En el sandbox de restauración (directorio de datos vacío)
pgbackrest --stanza=main --delta restore
pg_ctl -D /var/lib/postgresql/18/main start
psql -c "SELECT pg_is_in_recovery(), now();"

Lo que esto demuestra:

• Envío continuo de WAL archive-push para PITR
• check valida el conjunto de copias de seguridad y la continuidad del archivo antes de que los necesite
• --delta restore evita la descarga completa al ensayar mensualmente

Análisis en profundidad

Tipos de copia de seguridad

Notas de Patroni

[main]
backup-standby=y
pg2-host=replica.internal
pg2-path=/var/lib/postgresql/18/main

• Ejecute copias de seguridad desde una réplica para reducir la E/S principal durante el horario comercial
• Asegúrese de que la réplica tenga hot_standby = on y no esté retrasada durante la ventana de copia de seguridad

Verificar la integridad de la copia de seguridad

pgbackrest --stanza=main info
pgbackrest --stanza=main verify

-- Después del simulacro de restauración
SELECT count(*) FROM pg_database;
SELECT max(created_at) FROM app.orders;  -- Fila de prueba específica de la aplicación

Errores comunes

• Dos herramientas de copia de seguridad: pg_basebackup cron más pgBackRest en el mismo clúster causa riesgo de corrupción y costo duplicado de S3. Solución: un solo agente.
• Fallo silencioso de archive_command: WAL se acumula en el disco principal si el envío falla. Solución: monitorizar pg_stat_archiver, alertar sobre failed_count.
• Restaurar sobre el directorio de datos en ejecución: destruye la producción. Solución: los simulacros de restauración utilizan un host sandbox dedicado o una instancia detenida únicamente.
• pg1-path incorrecto: la stanza apunta a la ruta de Debian pero RHEL usa una estructura diferente. Solución: coincidir exactamente con SHOW data_directory;.
• Credenciales de S3 en el host de la base de datos: rol IAM amplio en el principal. Solución: usuario IAM dedicado para copias de seguridad; claves repo1-s3-* de mínimo privilegio.

Alternativas

Preguntas frecuentes

Relacionados

• Conceptos básicos de herramientas - manifiesto del conjunto de herramientas
• Conceptos básicos de PITR - objetivos de recuperación
• Modo de archivo y archive_command - archivado de WAL
• Patroni y etcd/Consul - topología de alta disponibilidad
• Mejores prácticas de herramientas esenciales - automatizar check

Versiones de la pila: Esta página se escribió para PostgreSQL 18.4, pgBackRest 2.55+ y Patroni 4.x en clústeres autohospedados.