Síntomas comunes

  • pg_restore arroja "ERROR: could not find file for relation with OID" o errores de tipo desconocido
  • pg_dump terminó sin error aparente pero el archivo está incompleto o su tamaño es anormalmente pequeño
  • PITR no alcanza el momento deseado porque faltan archivos WAL intermedios
  • pg_basebackup terminó pero hay errores al iniciar PostgreSQL sobre los datos copiados
  • El proceso de restore lleva horas y falla en medio de la importación de una tabla grande
  • La base restaurada arranca, pero hay tablas vacías o sin datos recientes

Riesgos para el negocio

  • Descubrir que el backup no funciona durante un incidente real es el peor momento posible
  • Si no hay backup válido, una corrupción o error humano puede ser irreversible
  • El RTO (tiempo de recuperación) medido puede ser mucho mayor que el RTO que el negocio aprobó
  • Backups sin prueba no cumplen requisitos de auditoría ni marcos regulatorios como SOC 2, ISO 27001 o regulaciones financieras

Checklist técnico detallado

  • 1. Verificar el formato del backup (custom vs texto plano) El formato texto plano (-Fp) no es recomendado para producción: no permite restauración selectiva ni compresión eficiente. El formato custom (-Fc) o directorio (-Fd) son los correctos.
  • 2. Incluir los roles y configuraciones globales pg_dump no exporta usuarios, roles ni configuraciones globales. Se necesita pg_dumpall --globals-only.
  • 3. Verificar extensiones disponibles en el servidor destino Si el origen usa extensiones como postgis, pg_trgm o uuid-ossp, deben estar instaladas en el destino antes de restaurar.
  • 4. Verificar tablespaces y sus rutas Si la base usa tablespaces personalizados, las rutas deben existir en el servidor destino. Usa --tablespace-map en pg_restore si las rutas difieren.
  • 5. Hacer una restauración de prueba en servidor aislado Esta es la única prueba real. Debe hacerse al menos mensualmente.
  • 6. Validar conteo de registros en tablas críticas Compara los conteos entre producción y la base restaurada para detectar datos faltantes.
  • 7. Para PITR: verificar continuidad de archivos WAL No deben faltar segmentos WAL entre el backup base y el punto objetivo de recuperación.
  • 8. Verificar que data_checksums estaba habilitado en el origen Los checksums de página permiten detectar corrupción silenciosa. Si no estaban habilitados, el backup puede contener páginas corruptas sin saberlo.
  • 9. Medir el tiempo real de restauración Documenta cuánto tarda la restauración completa. Si supera tu RTO aprobado, debes ajustar la estrategia (PITR, réplica en espera, etc.).
  • 10. Automatizar la verificación del backup Un backup sin verificación automática de integridad no es confiable.

Cuándo escalar el incidente a un DBA especialista

  • No existe ningún backup válido y verificado de la base de producción
  • El último backup válido es más antiguo que el RPO aprobado por el negocio
  • Hay corrupción de datos o páginas en el servidor de producción sin backup confiable
  • Los archivos WAL para PITR están incompletos o el archive_command ha estado fallando silenciosamente
  • El tiempo de restauración medido supera significativamente el RTO del negocio

Preguntas frecuentes

¿Cada cuánto debo probar la restauración de los backups?

Como mínimo una vez al mes para sistemas críticos. La prueba debe hacerse en un servidor aislado y verificar: tiempo total de restauración, integridad de los objetos (tablas, funciones, índices), datos de las últimas transacciones, y que la aplicación funcione correctamente contra la base restaurada. Un backup no probado no es un backup confiable; solo es una esperanza.

¿Qué diferencia hay entre pg_dump y pg_basebackup?

pg_dump es un backup lógico: exporta el esquema y los datos como SQL o en formato binario. Es portátil entre versiones mayores de PostgreSQL y permite restauraciones selectivas por tabla o esquema. pg_basebackup es un backup físico: copia los archivos del cluster directamente a nivel de bloque. Es más rápido para bases de datos grandes, permite PITR y es la base para configurar réplicas de streaming, pero no es portátil entre versiones mayores.

¿Por qué el backup parece correcto pero falla al restaurar?

Las causas más comunes son: el dump fue interrumpido y el archivo está incompleto pero el script no verificó el exit code de pg_dump; extensiones del servidor origen no están instaladas en el destino; tablespaces apuntan a rutas que no existen; objetos que dependen de funciones o tipos creados en extensiones no instaladas; o diferencias en la versión de PostgreSQL que hacen incompatible alguna opción de almacenamiento o tipo de dato.

¿Qué es PITR y cuándo lo necesito?

PITR (Point-in-Time Recovery) permite restaurar PostgreSQL al estado exacto que tenía en un momento específico del pasado, combinando un backup físico base con los archivos WAL subsiguientes. Lo necesitas principalmente cuando un error humano (DELETE o DROP TABLE accidental) o un proceso fallido modifica datos incorrectamente y necesitas recuperar el estado de la base justo antes del error, con precisión de segundos. Requiere archive_mode = on y un archive_command funcional.

Recursos relacionados