Autor: Milton H. Flores Chino
Proyecto grupal de Base de Datos II, desarrollado junto con Yerry Maycol Tarqui Collatupa.
Una estrategia de respaldo debe permitir recuperar información y ejecutarse con regularidad. En nuestro proyecto trabajamos ese ciclo con PostgreSQL: preparación de datos, generación de copias, restauración en otra base y automatización de respaldos de una instancia en la nube.
En este artículo presento el recorrido del proyecto y mi análisis de las decisiones que tomamos. Utilizamos PostgreSQL, Docker, PowerShell, FastAPI, Render y GitHub Actions.
Enlaces del proyecto
- Repositorio público con el código y la documentación.
- Aplicación pública y documentación Swagger en Render.
- Video de construcción y demostración.
Preparar un entorno reproducible
Comenzamos configurando PostgreSQL en Docker Compose. Separamos las credenciales del código mediante variables de entorno; el repositorio incluye una plantilla .env.example para facilitar la preparación de otra instalación.
Después creamos las tablas y cargamos datos de prueba con un script SQL. Estos datos nos dieron una referencia para comprobar que la aplicación podía consultar PostgreSQL y que una restauración recuperaba la información esperada.
Docker nos permitió organizar la base de datos y la aplicación en servicios. Para levantar el entorno del proyecto se utiliza:
docker compose up -d --build
Generar el respaldo y comprobar la recuperación
Implementamos un script de PowerShell para producir respaldos locales con pg_dump. Luego configuramos el Programador de tareas de Windows para ejecutar el script de forma periódica. La automatización local depende de que el equipo esté disponible en el horario previsto.
PostgreSQL permite generar un respaldo lógico en formato personalizado con -Fc y recuperarlo mediante pg_restore. Estos comandos ilustran el procedimiento; las variables de conexión deben configurarse para cada entorno:
pg_dump --dbname="$DATABASE_URL" -Fc --no-owner --no-privileges -f backup.dump
pg_restore --dbname="$RESTORE_DATABASE_URL" --no-owner --no-privileges backup.dump
La base de destino debe existir y ser independiente de la base de trabajo. Así se puede evaluar la recuperación sin sobrescribir los datos originales. En el desarrollo documentamos la selección del respaldo, su copia al contenedor, la creación de la base de destino y la restauración.
Según la documentación de PostgreSQL, un archivo de formato personalizado se restaura con pg_restore. Además, pg_dump respalda una base individual; los roles y otros objetos globales requieren un tratamiento adicional.
Mi principal conclusión de esta etapa es que guardar un archivo es solo una parte del proceso. La prueba de recuperación debe comprobar las tablas, los registros y las consultas que necesita la aplicación.
Consultar los datos desde FastAPI
Creamos una API con FastAPI para consultar los datos. Durante el desarrollo local comprobamos el estado del servicio, la conexión con PostgreSQL, el listado de productos y la documentación interactiva.
Los endpoints del proyecto son:
| Endpoint | Propósito |
|---|---|
/ |
Consultar el estado general de la API |
/health |
Comprobar la conexión con PostgreSQL |
/productos |
Consultar los productos almacenados |
/docs |
Explorar la documentación Swagger |
La API ayuda a evaluar el sistema desde el punto de vista de quien consume los datos. Tras una recuperación, verificar consultas representativas permite detectar problemas que el tamaño del archivo de respaldo no revela.
Publicar en la nube y automatizar el despliegue
Publicamos el código en GitHub y desplegamos PostgreSQL y FastAPI en Render. La entrega incluye la dirección pública de Swagger para que se puedan revisar los endpoints.
También configuramos el despliegue automático: Render toma los cambios de la rama main del repositorio y genera un nuevo despliegue cuando se envían commits. En el informe registramos la modificación de la aplicación, el envío de los cambios y la verificación del proceso.
Este flujo permite mantener una relación clara entre la versión del código y la aplicación publicada. La automatización del despliegue y la automatización del respaldo resuelven necesidades distintas: una actualiza el servicio y la otra conserva una copia de los datos.
Respaldar PostgreSQL en Render con GitHub Actions
Para la instancia en la nube implementamos un workflow de GitHub Actions y un repositorio privado dedicado a los respaldos. De esta manera, la ejecución programada puede realizarse aunque nuestra computadora esté apagada.
El flujo genera una copia con pg_dump, comprueba que el archivo tenga contenido, lo cifra mediante OpenSSL y almacena el resultado con extensión .dump.enc. Las credenciales de conexión y la frase de cifrado se gestionan mediante GitHub Secrets.
La programación documentada utiliza 17 10 * * *: corresponde a las 10:17 UTC, es decir, a las 5:17 a. m. en Perú. El workflow también permite una ejecución manual para verificar su funcionamiento. El informe incluye evidencias de la ejecución manual, de una ejecución programada y de los archivos cifrados generados.
En el repositorio público puede consultarse una versión de ejemplo del workflow. Las copias reales permanecen en el repositorio privado destinado a respaldos.
Qué mejoraría en una siguiente versión
Para ampliar esta solución propondría definir una política de retención, alertas de fallo y pruebas periódicas de restauración. También mediría el tiempo necesario para recuperar el servicio y la cantidad de información que se podría perder entre dos respaldos.
Estas son mejoras propuestas, no funcionalidades que doy por implementadas en esta entrega. La comprobación de que un archivo existe y tiene contenido ayuda a detectar errores básicos, pero debe complementarse con una recuperación real. Asimismo, conviene conservar la clave de descifrado por separado y mantener copias en más de un destino.
Aprendizaje del proyecto
Este trabajo nos permitió conectar la administración de PostgreSQL con una aplicación desplegada y con procesos automáticos. Desde mi perspectiva, el valor de una estrategia de respaldo está en poder repetir la recuperación y demostrar que los datos vuelven a ser utilizables.
El código público, la aplicación en Render y el video enlazados al inicio reúnen los recursos de esta implementación. El desarrollo técnico es grupal y esta explicación corresponde a mi artículo individual sobre el proyecto.
Top comments (0)