pg_dump y pg_restore: cómo hacer y comprobar backups de PostgreSQL
Publicado el 2026-10-26 por frfrand
Copia lógica y restauración en PostgreSQL con comandos seguros
«Tenemos backups» no significa mucho hasta que alguien necesita restaurar uno. Con PostgreSQL, pg_dump permite crear copias lógicas y pg_restore recuperarlas cuando usaste formatos compatibles. Lo importante es verificar el procedimiento.
La idea es resolver un problema de datos o despliegue que aparece en aplicaciones reales. Vamos a ver el concepto sin vueltas, un ejemplo de implementación y qué comprobar antes de llevarlo a producción.
Qué hace pg_dump y pg_restore
Una copia lógica exporta objetos y datos de la base, no todo el estado del servidor PostgreSQL ni necesariamente roles globales o configuraciones externas. Para bases muy grandes o recuperación a un instante concreto pueden hacer falta backups físicos y WAL/PITR.
No alcanza con repetir una receta si no entendés quién lee los datos, desde qué proceso y con qué permisos. En una aplicación con reservas, facturas o usuarios, una condición de carrera o una política de acceso mal hecha puede ser más grave que una API lenta.
Un ejemplo concreto
# Formato custom en un entorno autorizado
pg_dump -h 127.0.0.1 -U app -F c -f /backups/app-20261026.dump app
# Inspeccionar contenido de la copia
pg_restore -l /backups/app-20261026.dump | head
# Restaurar en una base de PRUEBA ya creada
pg_restore -h 127.0.0.1 -U restaurador -d app_pruebas --no-owner /backups/app-20261026.dumpLos nombres, tablas y claves de este ejemplo son ilustrativos. Probalo primero en una base o entorno de ensayo y adaptá permisos, índices y versiones. Cuando haya operaciones de escritura, no ejecutes consultas de muestra sobre datos de clientes sin revisar qué modifican.
Paso a paso
- Elegí destino de almacenamiento con permisos, cifrado y retención adecuados.
- Creá la copia en un formato apropiado y comprobá que la orden terminó sin error.
- Guardá versión del motor y procedimiento de restauración junto al backup.
- Restaurá en una base aislada de prueba y verificá tablas, relaciones y datos clave.
- Programá comprobaciones recurrentes, no sólo la generación nocturna del archivo.
Al final no te quedes con «el SQL no dio error». Comprobá el efecto real desde la API y con pruebas de concurrencia o permisos según corresponda. En bases de datos hay errores que sólo aparecen cuando dos usuarios hacen algo a la vez.
Ejemplo de proyecto de trabajo
Una plataforma de alquileres tiene reservas y entradas pagadas. Antes de una actualización de esquema, hacés una copia coherente, la restaurás en staging y probás que la aplicación puede iniciar con esos datos.
Ese escenario ayuda a distinguir rendimiento de consistencia. Acelerar una consulta no sirve si permite crear dos reservas para una sola plaza, ni una base enorme arregla que el backend permita consultar datos de otro cliente.
El error típico
No restaurés una copia de pruebas sobre producción por accidente. Para bases activas, el tamaño, consistencia y ventana de recuperación pueden requerir una estrategia distinta al volcado completo diario.
También conviene tener un plan de recuperación. Antes de tocar esquema, usuarios o políticas, guardá una copia verificable o migración reversible y comprobá que la aplicación pueda seguir funcionando durante el cambio.
¿Cómo lo resolvería con ArduMaker?
Al gestionar PostgreSQL y VPS desde ArduMaker, documentá dónde se guardan copias, quién accede y cuánto tiempo tardás en recuperar la API. El panel no sustituye el simulacro de restauración.
ArduMaker te permite desplegar servicios desde Git y trabajar con bases y procesos dentro del VPS. El panel no reemplaza la lógica de tu aplicación: transacciones, permisos y validaciones deben quedar correctamente diseñados en el código y la base de datos.
Tres comprobaciones antes de publicar
Integridad: si una petición se repite o falla a mitad de camino, ¿los datos terminan en un estado válido?
Seguridad: ¿un usuario autenticado puede acceder sólo a su información, y la API utiliza una identidad de base con permisos mínimos?
Recuperación: ¿sabés restaurar los datos y revertir la versión de código compatible si una actualización sale mal?
Si podés responder a esas tres preguntas con pruebas, tu backend está bastante mejor preparado que cuando sólo miraste si el endpoint devolvía 200.
Recursos para profundizar
Para cerrar: elegí la solución más simple que permita mantener datos correctos, seguros y recuperables. El rendimiento viene después de medir.