PostgreSQL
Backups, restauración y PITR
Backups lógicos y físicos, restauración, archivado de WAL y Point-in-Time Recovery con pruebas periódicas y objetivos RPO/RTO.
- Última actualización
- Actualizada
- Nivel
- Profundización
PostgreSQL
Backups lógicos y físicos, restauración, archivado de WAL y Point-in-Time Recovery con pruebas periódicas y objetivos RPO/RTO.
Define primero:
RPO → cuánto dato reciente puede perderse
RTO → cuánto tiempo puede tardar la recuperaciónDespués eliges mecanismos.
pg_dump exporta objetos y datos en formato SQL/custom/directory.
pg_dump --format=custom --file=app.dump appdb
pg_restore --dbname=restore_test app.dumpVentajas:
Costes:
Copia coherente del cluster, normalmente con pg_basebackup o tooling administrado. Incluye archivos y necesita WAL para consistencia.
Ventajas: rápido para clusters grandes y PITR. Costes: menos selectivo, dependiente de compatibilidad binaria/configuración.
pg_dumpall --globals-only conserva roles y tablespaces en escenarios lógicos. Un dump por database no incluye automáticamente todos los roles ni configuración externa.
base backup
+ WAL archivado continuo
→ restaurar a timestamp/LSN/transaction objetivoRequisitos:
archive_mode.PITR no permite “deshacer una tabla” directamente; reconstruye un cluster a un punto y luego puedes extraer datos.
pg_dump usa un snapshot coherente. Para varias databases no existe una única transacción cross-database; coordina según requisito.
Backups de filesystem sin protocolo físico correcto pueden quedar inconsistentes.
Protege backups:
Un backup contiene todos los datos sensibles, a menudo más accesibles que producción.
Ejemplo:
7 diarios + 4 semanales + 12 mensuales
+ WAL para 7 días de PITRLa política depende de RPO, regulación, coste y amenazas. Evita que un atacante con acceso a producción pueda borrar también todos los backups.
Automatiza:
Orden y dependencias importan. pg_restore --jobs puede paralelizar formatos compatibles. Revisa:
--no-owner.Puede ser:
Detenerse demasiado pronto o tarde cambia pérdida. Crea restore points antes de cambios riesgosos:
SELECT pg_create_restore_point('before_bulk_migration');Solo ayuda si WAL está archivado y existe base backup compatible.
Una réplica aplica errores lógicos, deletes y corrupción propagada. Aporta disponibilidad, no retención histórica independiente.
Necesitas copias inmutables/offline, credenciales separadas y pruebas de restauración sin depender de producción comprometida.
Verifica archivos y catálogos, pero un checksum correcto no demuestra que el backup incluya todo ni que la app funcione. El restore es la prueba final.
Debe incluir:
Replicación física y lógica distingue copiar el estado del cluster de publicar cambios de tablas.