Copia de seguridad y PITR con pg_basebackup + archivo de WAL (sin pgBackRest)

Copia física con las herramientas propias de PostgreSQL, sin software adicional: archivado continuo de WAL con archive_command, base backup nocturno con pg_basebackup y retención con pg_archivecleanup. Recuperación a un momento / transacción / restore point (recovery.signal, restore_command, recovery_target_*), timelines y un simulacro de restauración periódico; el resultado es un WAL archivado, una copia nocturna y un camino de vuelta probado. Alternativas: si necesita copias incrementales/paralelas/cifradas, S3 y gestión de retención integrada, use la guía de pgBackRest; para trasladar una tabla/base de datos o recuperar una sola tabla, una copia lógica (pg_dump, sin PITR).

Topología: 1 servidor; con streaming o Patroni, el directorio de archivo es compartido por todos los nodos (NFS)

Escenarios

• Configurar el archivado de WAL y el base backup nocturno — Instalación inicial: archivado continuo de WAL con archive_command, script de pg_basebackup, programación en /etc/cron.d, retención y limpieza de WAL. archive_mode requiere un reinicio breve una sola vez.
• Volver a un punto concreto (PITR: tiempo, xid, LSN, restore point) — Se borraron/modificaron datos por error (DROP, DELETE, TRUNCATE) o se perdió el servidor/disco: se restaura el base backup y se aplica el WAL archivado hasta el objetivo. Todo el cluster se detiene y vuelve al objetivo; todo lo posterior al objetivo se pierde.
• Simulacro de restauración (en un directorio separado, sin tocar producción) — Para demostrar que la copia se restaura de verdad (se recomienda una vez al mes): se verifica el último base backup (pg_verifybackup), se extrae en un directorio separado y se arranca con el archivo en un puerto distinto; se mide el tiempo (RTO). No se toca producción.
• Limpiar los base backups antiguos y el archivo de WAL — El disco de archivo o de copias se está llenando, o ha cambiado la retención: se borran los base backups antiguos y pg_archivecleanup elimina el WAL anterior a la copia más antigua (primero en modo dry-run). La base de datos sigue abierta.

Antes de empezar

• PostgreSQL … está instalado y en funcionamiento (pg-install); directorio de datos ….
• … y … están en un disco/recurso NFS separado del disco de datos, montado de forma persistente (fstab)… y en la misma ruta en todos los servidores PostgreSQL (tras un failover el nuevo primary debe escribir en el mismo archivo)…. Espacio: (número de copias conservadas + 1) × tamaño de los datos comprimidos + volumen diario de WAL × días de retención.
• No hay configurada otra herramienta de archivo/copia (pgBackRest, Barman, WAL-G); si dos herramientas llevan el mismo WAL a sitios distintos, ambas quedan incompletas.
• Los relojes están sincronizados con NTP (la hora objetivo del PITR se interpreta según el reloj del servidor).
• Hay una ventana de reinicio breve para el cambio de archive_mode.
• Las aplicaciones están detenidas; se ha aceptado que se perderán todos los cambios posteriores al objetivo.… Los standby/réplicas se reconstruirán después de la restauración.…

Fases de la guía

• Instalación del archivo de WAL y del base backup — Preparar los directorios de archivo y de copias · Escribir el script de archivado de WAL · Hacer ejecutable el script y probarlo · Escribir la configuración de archivado de PostgreSQL · Reiniciar PostgreSQL · Escribir la configuración de archivado en Patroni (edit-config) …
• Simulacro de restauración — Preparar el directorio del simulacro y elegir la última copia · Extraer y verificar la copia (pg_verifybackup) · Iniciar la instancia del simulacro con el archivo · Verificar los datos · Detener y limpiar la instancia del simulacro
• Retención y limpieza de WAL — Copias, tamaño del archivo y WAL más antiguo necesario · Borrar los base backups fuera de la retención · Mostrar primero la limpieza de WAL con un dry run · Limpiar el archivo de WAL · Verificar que el archivado sigue funcionando