Copias de seguridad y PITR con pgBackRest

Copias completas / diferenciales / incrementales con pgBackRest, archivado continuo de WAL y recuperación a un punto en el tiempo (PITR). Para un servidor único, streaming replication (primary + standbys) o un cluster de Patroni; el repositorio puede estar en el mismo servidor, en un servidor de copias aparte (SSH) o en object storage compatible con S3. Incluye cifrado, compresión, política de retención, programación con cron/systemd y una restauración de prueba en un directorio aparte; la misma guía genera además el runbook de restauración in situ para un desastre (incluida la reconstrucción de un cluster de Patroni desde la copia). Diferencia con las alternativas: es la herramienta de copia física recomendada para producción; para copias físicas y PITR sin instalar herramientas adicionales se usa la guía de pg_basebackup + archivado de WAL, y para copias lógicas (volcado de tablas/bases de datos, migración entre versiones) la guía de pg_dump / pg_restore.

Topología: 1 servidor, primary + standbys o un cluster de Patroni; servidor de copias opcional

Escenarios

• Instalación de pgBackRest + primera copia + restauración de prueba — pgBackRest aún no está implantado: software, repositorio, archivado de WAL, primera copia, programación y una restauración de prueba.
• Desastre: restauración in situ (al último estado o a un punto en el tiempo) — Devuelva la base de datos, in situ, a un momento cubierto por la copia y el archivo: el último instante, una hora, un xid, un LSN o un restore point. El cluster se detiene; los cambios posteriores al objetivo se pierden.
• Archivos dañados o borrados en el directorio de datos (reparar con delta restore) — El servidor está intacto, pero algunos archivos de datos no se pueden leer o se han borrado: --delta reescribe desde la copia solo los archivos que difieren y avanza hasta el final del archivo de WAL. El cluster se detiene.
• Recuperar una sola base de datos (--db-include) — El cluster sigue en servicio: la base de datos se restaura en una instancia temporal (directorio y puerto aparte), se extrae con pg_dump y se carga en el servidor en producción con un nombre nuevo. Esta tarjeta sirve también para una sola tabla borrada (desde ahí con pg_dump -t).
• Restaurar la copia en otro servidor (clon / pruebas / informes) — No se toca el servidor en producción. La copia se abre en un servidor nuevo; el archivado de WAL se desactiva para que el clon no escriba en el repositorio de producción. Con un repositorio cifrado se necesita la clave.
• El servidor se ha perdido por completo: abrir la copia en un servidor nuevo y sustituirlo — Pérdida de disco o de servidor: el servidor nuevo se abre desde la copia y pasa a ser el nuevo primary; el archivado de WAL y las copias continúan en el mismo stanza. El servidor antiguo debe permanecer apagado sin excepción.
• Crear un nuevo standby desde la copia (--type=standby) — Un nuevo standby sin cargar al primary con la copia de datos: los archivos vienen de la copia y el WAL que falta se completa desde el archivo y por streaming. El primary sigue en servicio.
• ¿Las copias están realmente sanas? (info / check / verify y simulacro de restauración) — Comprobaciones de solo lectura y un simulacro de restauración en un directorio aparte que no toca el servidor en producción. También se configura una tarea mensual de verificación (cron).
• Cambiar el periodo de retención y eliminar copias antiguas (expire) — Cambia los parámetros repo1-retention-full/diff, muestra primero con --dry-run qué se eliminaría y después ejecuta expire. Una copia eliminada no se puede recuperar.

Antes de empezar

• PostgreSQL … está instalado y en ejecución (guía pg-install)…; este servidor es el primary…. Directorio de datos ….
• El cluster de Patroni … está en ejecución (instalación de Patroni): un Leader y los demás réplicas de streaming. En todos los nodos el directorio de datos es …, la configuración de Patroni … y la contraseña de la REST API está en /etc/patroni/patroni.env.
• No hay configurada otra herramienta de archivado/copia (Barman, WAL-G, un archive_command escrito a mano); si la hay, elimínela primero. Si dos herramientas llevan el mismo WAL a sitios distintos, ambas quedan incompletas.… Con Patroni, el valor actual aparece en la salida de patronictl show-config.…
• Se conoce el tamaño de la base de datos. El repositorio necesita aproximadamente (número de fulls + 1) × tamaño comprimido + archivo de WAL (con zst la mayoría de las bases de datos se comprimen a 1/3–1/5).
• El directorio del repositorio … está en un disco/recurso NFS separado de la base de datos y montado de forma persistente (fstab).
• En el servidor de copias hay montado un disco aparte con espacio suficiente para …. El servidor de copias usa la misma familia de sistema operativo que la base de datos.
• Los servidores resuelven los nombres de los demás (…, …) y el puerto 22/tcp (SSH) está abierto entre ellos.
• Los standbys (………, ……) son standbys de streaming que reciben WAL del primary y usan la misma ruta de PGDATA que el primary (…).
• Se ha creado el bucket …; hay preparada una clave de acceso (access key + secret key) con permisos de lectura/escritura/borrado solo en este bucket. El bucket no tiene ninguna regla de lifecycle que borre objetos (la retención la gestiona pgBackRest). El servidor puede acceder al endpoint.
• Los relojes están sincronizados (NTP). La hora objetivo del PITR y las firmas de S3 dependen de una hora correcta.
• Los servidores pueden acceder a los repositorios PGDG y EPEL (o a un mirror interno); la dependencia libssh2 de pgBackRest viene de EPEL.
• Está preparado el lugar donde se guardará la clave de cifrado (gestor de contraseñas / vault). Si la clave no se guarda fuera del servidor, tras la pérdida del servidor las copias no se pueden abrir.

Fases de la guía

• Instalación del software pgBackRest — Añadir el repositorio PGDG (servidor de copias) · Añadir el repositorio PGDG (servidor de copias) · Habilitar el repositorio EPEL · Instalar pgBackRest · Crear el usuario pgbackrest · Eliminar el archivo de configuración antiguo
• Preparación del repositorio — Crear el directorio del repositorio · Crear el directorio del repositorio · Generar una clave SSH (servidor de copias) · Generar una clave SSH (servidores de base de datos) · Autorizar la clave del servidor de copias · Autorizar las claves de los servidores de base de datos …
• Configuración de pgBackRest — Escribir el archivo de configuración · Escribir el archivo de configuración (servidor de copias) · Escribir el archivo de configuración (servidores de base de datos) · Introducir las claves de acceso de S3 · Generar la clave de cifrado · Escribir la clave de cifrado en el servidor … …
• Stanza y primera copia — Crear el stanza · Crear el stanza · Verificar la configuración (check) · Hacer la primera copia full · Hacer la primera copia full · Mostrar el estado del repositorio (info) …
• Programación de copias — Verificar la ruta del comando pgbackrest · Escribir el script de copia · Ajustar la propiedad y los permisos del script · Crear el servicio y los timers de systemd · Probar la programación (ejecución manual) · Preparar el servicio cron …
• Verificación y prueba de recuperación — Comprobar que el archivado de WAL funciona · Escribir datos de prueba y registrar la hora objetivo · Preparar el directorio de la restauración de prueba · Restaurar en un directorio aparte hasta la hora objetivo · Arrancar el cluster de prueba en un puerto aparte · Verificar los datos recuperados …
• Monitorización y mantenimiento — Verificar la integridad del repositorio (verify) · Verificar la integridad del repositorio (verify) · Vigilar la antigüedad de la última copia · Vigilar la antigüedad de la última copia · Segunda copia y custodia de claves
• Diagnóstico: ¿archivo dañado o que falta? — Localizar en el log el error y el archivo afectado · Identificar el objeto dañado · Verificar que existen una copia y un archivo sanos
• Comprobaciones previas a la restauración — Listar las copias · Comprobar las conexiones de las aplicaciones · Detener los standbys · Detener PostgreSQL · Copiar el directorio de datos actual (si hay espacio)
• Restauración in situ — Restaurar (--delta) · Arrancar PostgreSQL y esperar a que termine el recovery · Comprobar los datos en el objetivo (pause) · Terminar el recovery y hacer promote
• Verificación — Limpiar los parámetros de restauración · Comprobar el estado del cluster · Comprobar los datos de la aplicación · Verificar que la corrupción ha desaparecido (amcheck) · Verificar que el archivado continúa · Hacer una copia full nueva …
• Antes de la restauración: detener el cluster de Patroni — Listar las copias · Guardar el estado del cluster y la configuración dinámica · Detener las aplicaciones · Detener Patroni en las réplicas · Detener Patroni en el leader · Copiar el directorio de datos actual (si hay espacio)
• Verificación y limpieza (Patroni) — Verificar que el archivado continúa · Hacer una copia full nueva · Comprobar el cluster y el acceso de las aplicaciones · Borrar los directorios de datos apartados
• Patroni: reconstruir el nodo dañado (reinit) — Localizar en qué nodo está la corrupción · Si el nodo dañado es el leader, ceder el liderazgo · Reconstruir la réplica dañada (reinit)
• Verificación de copias y simulacro de restauración — Estado de las copias y antigüedad de la última copia (info) · Verificar que el archivado funciona ahora mismo (check) · Verificar la integridad del repositorio (verify) · Preparar el directorio del simulacro · Restaurar la última copia en el directorio del simulacro · Arrancar la instancia del simulacro y esperar al recovery …
• Programación de la verificación mensual — Escribir el script de verificación mensual · Ajustar los permisos del script y probarlo con el entorno de cron · Escribir la tarea mensual de cron · Ajustar los permisos del archivo de cron
• Cambiar la política de retención — Parámetro de retención actual y copias · Cambiar el parámetro de retención · Mostrar qué se eliminaría (dry-run) · Eliminar las copias antiguas (expire) · Comprobar la ocupación del repositorio y la programación