Autor: Franco Mango Puma
Curso: Base de Datos II
Universidad: Universidad Privada de Tacna
- Introducción
La información almacenada en una base de datos representa uno de los recursos más importantes de cualquier sistema informático. Una eliminación accidental, una falla del servidor o una modificación incorrecta pueden ocasionar pérdidas de información que afectan directamente la continuidad de una aplicación.
Ante esta problemática, una estrategia de respaldo no debe limitarse a generar archivos de seguridad. También debe permitir verificar su integridad, comprobar que los datos pueden restaurarse y conservar las copias en un entorno adecuado.
En este artículo se presenta la automatización de respaldos implementada en BackupManager, un sistema web desarrollado con Python y FastAPI que utiliza PostgreSQL como motor de base de datos.
El proyecto incorpora GitHub Actions para ejecutar respaldos automáticos, verificar su recuperación en una base temporal, cifrar los archivos generados y mantener un historial de ejecuciones. Además, utiliza Neon para alojar PostgreSQL y Render para publicar la aplicación en la nube.
- Objetivo del proyecto
El objetivo principal es implementar y demostrar una estrategia automatizada de respaldo y recuperación de PostgreSQL mediante herramientas de desarrollo y servicios en la nube.
Esta propuesta busca reducir la dependencia de procedimientos manuales y comprobar que un respaldo puede utilizarse realmente para recuperar la información.
La solución integra varias tecnologías con responsabilidades específicas.
Tecnología
Función dentro del proyecto
Python y FastAPI
Desarrollo de la aplicación y sus funcionalidades
PostgreSQL 18
Almacenamiento de los registros
Neon
Alojamiento de la base de datos en la nube
GitHub
Repositorio público del código fuente
GitHub Actions
Automatización de respaldos, pruebas y despliegue
Docker
Entorno de ejecución con herramientas PostgreSQL
Render
Publicación de la aplicación web
OpenSSL
Cifrado de los archivos de respaldo
La combinación de estas herramientas permite demostrar un proceso que abarca desde el almacenamiento de datos hasta su protección y recuperación.
- Arquitectura de la solución
La arquitectura de BackupManager integra una aplicación web, una base de datos administrada y dos procesos automatizados en GitHub Actions.
Los usuarios acceden a la aplicación desplegada en Render, mientras que los registros se almacenan en PostgreSQL mediante Neon.
De manera independiente, GitHub Actions se conecta a la base de datos utilizando credenciales almacenadas como secretos del repositorio. Desde este entorno se ejecuta la creación de respaldos y la verificación de restauración.
Esta separación resulta importante porque permite probar la recuperación de información sin modificar directamente la base de datos de producción.
Figura 1. Arquitectura general de BackupManager.
Insertar aquí la imagen de arquitectura o una captura del proyecto.
- Implementación del respaldo automatizado
Uno de los componentes principales del proyecto es el archivo postgres-backup.yml, ubicado en .github/workflows.
Este archivo define un flujo de trabajo de GitHub Actions que puede ejecutarse manualmente o mediante una programación diaria.
La programación utiliza la expresión 0 7 * * *, correspondiente a una ejecución prevista todos los días a las 07:00 UTC.
El proceso de respaldo se desarrolla mediante las siguientes etapas:
Validación de configuración: verifica la existencia de los secretos necesarios y comprueba que se utiliza una conexión directa a PostgreSQL.
Generación del respaldo: ejecuta pg_dump con formato personalizado para obtener una copia de la estructura y los datos.
Prueba de restauración: utiliza pg_restore para recuperar el contenido en una instancia temporal e independiente de PostgreSQL.
Comprobación de datos: consulta la tabla records restaurada para verificar que el proceso terminó correctamente.
Cifrado del archivo: protege el respaldo mediante OpenSSL antes de almacenarlo como artefacto.
Conservación temporal: publica el archivo cifrado y su comprobación SHA-256 como artefactos de GitHub Actions, con una retención configurada de siete días.
La automatización permite repetir el procedimiento sin necesidad de ejecutar manualmente cada comando desde una computadora personal.
Figura 2. Configuración del workflow de respaldo.
Insertar la captura del archivo postgres-backup.yml.
- Generación de respaldos con pg_dump
PostgreSQL dispone de la herramienta pg_dump, utilizada para generar copias de seguridad lógicas de una base de datos.
En BackupManager se emplea el formato personalizado, conocido como custom, que permite trabajar posteriormente con pg_restore.
Este procedimiento tiene una ventaja importante: el respaldo no se limita a exportar una tabla específica, sino que puede incluir la estructura y los datos de la base seleccionada.
Durante las pruebas del proyecto se generó desde la aplicación un archivo .dump de aproximadamente 6,2 KB, correspondiente a los datos utilizados en la demostración.
El sistema también permitió comprobar la integridad del archivo mediante SHA-256 y revisar su estructura utilizando las herramientas de PostgreSQL.
Es importante distinguir que verificar un archivo con SHA-256 y comprobar su estructura no equivale a restaurarlo. Por este motivo, el proyecto incorpora una prueba de recuperación independiente.
Figura 3. Respaldo PostgreSQL generado y verificado.
Insertar la captura del archivo .dump creado en BackupManager.
- Verificación de recuperación con pg_restore
Una de las decisiones más importantes del proyecto fue incluir una restauración de prueba dentro de la automatización.
Generar un archivo de respaldo no garantiza por sí solo que pueda utilizarse para recuperar información. Un archivo incompleto, una incompatibilidad de herramientas o un problema de restauración podrían detectarse demasiado tarde.
Para reducir ese riesgo, el workflow utiliza un contenedor con PostgreSQL 18 que funciona como destino temporal.
En este entorno se ejecuta pg_restore, sin restaurar directamente sobre la base original alojada en Neon.
Después se realiza una consulta SQL para comprobar que la tabla records está disponible y que puede recuperarse su número de registros.
La ejecución de GitHub Actions finalizó correctamente, mostrando el estado Success en las etapas de creación, restauración y cifrado del respaldo.
Esta evidencia demuestra que el proyecto no solamente genera copias, sino que también comprueba su recuperación mediante una ejecución real.
Figura 4. Prueba exitosa de restauración en GitHub Actions.
Insertar la captura del workflow con los pasos pg_dump, pg_restore y cifrado finalizados correctamente.
- Protección del respaldo mediante cifrado
La seguridad de los archivos generados constituye otro aspecto importante de la solución.
Una copia de seguridad puede contener información que no debería quedar expuesta. Por ello, el workflow cifra el archivo antes de conservarlo como artefacto.
BackupManager utiliza OpenSSL con AES-256-CBC y derivación de clave PBKDF2, configurada con 250 000 iteraciones.
La contraseña utilizada para el cifrado se almacena como un secreto de GitHub Actions denominado BACKUP_ENCRYPTION_PASSWORD.
Adicionalmente, se genera una suma SHA-256 del archivo cifrado para detectar posibles modificaciones.
La contraseña no se incorpora al repositorio ni se publica junto con el respaldo.
Es importante señalar que el cifrado protege la confidencialidad del archivo, mientras que el mecanismo SHA-256 permite realizar una comprobación de integridad. Ambas funciones responden a necesidades distintas.
En esta implementación educativa, los artefactos se conservan durante siete días. Para una solución de producción sería necesario incorporar políticas de retención más amplias y almacenamiento externo persistente.
- Despliegue automatizado mediante GitHub Actions y Render
Además de automatizar respaldos, el proyecto incorpora un segundo workflow orientado a las pruebas del software y su despliegue.
Este flujo está definido en el archivo ci-deploy.yml.
Cuando se ejecuta, GitHub Actions prepara un entorno con Python 3.12, instala las dependencias del proyecto y ejecuta las pruebas automatizadas de FastAPI mediante pytest.
Si las pruebas terminan correctamente, y la ejecución corresponde a un evento permitido para desplegar, el workflow solicita un nuevo despliegue en Render utilizando un deploy hook.
La dirección del deploy hook se almacena como secreto del repositorio, evitando publicarla dentro del código fuente.
Durante las pruebas se obtuvo una ejecución exitosa de GitHub Actions. También se verificó que la aplicación estaba desplegada y respondía correctamente desde Render.
Esta automatización permite establecer un proceso básico de integración y despliegue continuo, donde las pruebas se ejecutan antes de solicitar la publicación de cambios.
Figura 5. Workflow de pruebas y despliegue exitoso.
Insertar la captura de GitHub Actions con el estado Success.
Figura 6. Aplicación publicada en Render.
Insertar la captura del despliegue exitoso y los registros de ejecución.
- Resultados obtenidos
La implementación permitió comprobar el funcionamiento conjunto de las herramientas utilizadas.
Prueba realizada
Resultado observado
Conexión a Neon PostgreSQL 18
Correcta
Almacenamiento de ocho registros de prueba
Correcto
Generación de respaldo .dump
Correcta
Verificación de integridad y estructura
Correcta
Restauración en PostgreSQL temporal
Exitosa
Cifrado del archivo
Exitoso
Almacenamiento temporal en GitHub Actions
Correcto
Pruebas automatizadas de FastAPI
Exitosas
Solicitud automatizada de despliegue
Exitosa
Aplicación disponible en Render
Verificada
Estos resultados permiten demostrar una estrategia de respaldo que incluye generación, verificación, recuperación y protección de archivos.
También evidencian la utilidad de automatizar tareas repetitivas mediante herramientas de integración continua.
- Limitaciones y oportunidades de mejora
Aunque BackupManager cumple los objetivos de la práctica, su implementación tiene algunas limitaciones que deben considerarse.
La versión gratuita de Render utiliza almacenamiento efímero. Por esta razón, los respaldos generados dentro del servidor web deben descargarse para evitar perderlos durante reinicios o nuevas implementaciones.
Asimismo, GitHub Actions conserva los respaldos cifrados durante siete días, por lo que estos artefactos no constituyen una estrategia definitiva de almacenamiento histórico.
Como mejoras futuras, sería conveniente incorporar un servicio de almacenamiento externo persistente, notificaciones de fallos, políticas de retención configurables y pruebas periódicas de recuperación.
También podrían evaluarse estrategias como respaldos incrementales y recuperación a un punto en el tiempo, que no forman parte de la implementación actual.
- Conclusiones
El desarrollo de BackupManager permitió demostrar que la automatización de respaldos es una parte importante de la administración de bases de datos.
La integración de PostgreSQL, GitHub Actions y OpenSSL hizo posible establecer un procedimiento que genera una copia, comprueba su restauración y protege el archivo antes de almacenarlo temporalmente.
Asimismo, el uso de Neon y Render permitió desplegar la solución y comprobar su funcionamiento en servicios de nube.
El principal aprendizaje es que un respaldo no debe considerarse confiable únicamente por existir: también debe verificarse su integridad y probarse su recuperación.
BackupManager constituye una implementación educativa funcional que puede ampliarse con mecanismos de almacenamiento permanente y controles adicionales de seguridad.
- Enlaces del proyecto
Repositorio público de GitHub:
https://github.com/JuanCalderon1218/BackupManager
Aplicación web desplegada en Render:
https://backupmanager.onrender.com
Ejecución exitosa del respaldo automatizado:
https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982198297
Ejecución exitosa de pruebas y despliegue:
https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982525820
Video de demostración:
Agregar el enlace público de YouTube cuando esté publicado.
- Referencias técnicas
PostgreSQL Global Development Group. (s. f.). pg_dump. https://www.postgresql.org/docs/current/app-pgdump.html
PostgreSQL Global Development Group. (s. f.). pg_restore. https://www.postgresql.org/docs/current/app-pgrestore.html
GitHub. (s. f.). GitHub Actions documentation. https://docs.github.com/en/actions
Neon. (s. f.). Neon documentation. https://neon.com/docs
Render. (s. f.). Render documentation. https://render.com/docs
Top comments (0)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.