The latest articles on DEV Community by FRANCO TEDDY MANGO PUMA (@franco_teddymangopuma_e). https://dev.to/franco_teddymangopuma_e https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4189674%2Fde49df43-0531-4c3f-bbeb-28febdfd15b0.png https://dev.to/franco_teddymangopuma_e en FRANCO TEDDY MANGO PUMA Sat, 17 Oct 2026 00:55:39 +0000 https://dev.to/franco_teddymangopuma_e/automatizacion-y-recuperacion-de-respaldos-postgresql-mediante-github-actions-1m45 https://dev.to/franco_teddymangopuma_e/automatizacion-y-recuperacion-de-respaldos-postgresql-mediante-github-actions-1m45 <p>Autor: Franco Mango Puma<br> Curso: Base de Datos II<br> Universidad: Universidad Privada de Tacna</p> <ol> <li>Introducción</li> </ol> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <ol> <li>Objetivo del proyecto</li> </ol> <p>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.</p> <p>Esta propuesta busca reducir la dependencia de procedimientos manuales y comprobar que un respaldo puede utilizarse realmente para recuperar la información.</p> <p>La solución integra varias tecnologías con responsabilidades específicas.</p> <p>Tecnología</p> <p>Función dentro del proyecto</p> <p>Python y FastAPI</p> <p>Desarrollo de la aplicación y sus funcionalidades</p> <p>PostgreSQL 18</p> <p>Almacenamiento de los registros</p> <p>Neon</p> <p>Alojamiento de la base de datos en la nube</p> <p>GitHub</p> <p>Repositorio público del código fuente</p> <p>GitHub Actions</p> <p>Automatización de respaldos, pruebas y despliegue</p> <p>Docker</p> <p>Entorno de ejecución con herramientas PostgreSQL</p> <p>Render</p> <p>Publicación de la aplicación web</p> <p>OpenSSL</p> <p>Cifrado de los archivos de respaldo</p> <p>La combinación de estas herramientas permite demostrar un proceso que abarca desde el almacenamiento de datos hasta su protección y recuperación.</p> <ol> <li>Arquitectura de la solución</li> </ol> <p>La arquitectura de BackupManager integra una aplicación web, una base de datos administrada y dos procesos automatizados en GitHub Actions.</p> <p>Los usuarios acceden a la aplicación desplegada en Render, mientras que los registros se almacenan en PostgreSQL mediante Neon.</p> <p>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.</p> <p>Esta separación resulta importante porque permite probar la recuperación de información sin modificar directamente la base de datos de producción.</p> <p>Figura 1. Arquitectura general de BackupManager.</p> <p>Insertar aquí la imagen de arquitectura o una captura del proyecto.</p> <ol> <li>Implementación del respaldo automatizado</li> </ol> <p>Uno de los componentes principales del proyecto es el archivo postgres-backup.yml, ubicado en .github/workflows.</p> <p>Este archivo define un flujo de trabajo de GitHub Actions que puede ejecutarse manualmente o mediante una programación diaria.</p> <p>La programación utiliza la expresión 0 7 * * *, correspondiente a una ejecución prevista todos los días a las 07:00 UTC.</p> <p>El proceso de respaldo se desarrolla mediante las siguientes etapas:</p> <p>Validación de configuración: verifica la existencia de los secretos necesarios y comprueba que se utiliza una conexión directa a PostgreSQL.</p> <p>Generación del respaldo: ejecuta pg_dump con formato personalizado para obtener una copia de la estructura y los datos.</p> <p>Prueba de restauración: utiliza pg_restore para recuperar el contenido en una instancia temporal e independiente de PostgreSQL.</p> <p>Comprobación de datos: consulta la tabla records restaurada para verificar que el proceso terminó correctamente.</p> <p>Cifrado del archivo: protege el respaldo mediante OpenSSL antes de almacenarlo como artefacto.</p> <p>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.</p> <p>La automatización permite repetir el procedimiento sin necesidad de ejecutar manualmente cada comando desde una computadora personal.</p> <p>Figura 2. Configuración del workflow de respaldo.</p> <p>Insertar la captura del archivo postgres-backup.yml.</p> <ol> <li>Generación de respaldos con pg_dump</li> </ol> <p>PostgreSQL dispone de la herramienta pg_dump, utilizada para generar copias de seguridad lógicas de una base de datos.</p> <p>En BackupManager se emplea el formato personalizado, conocido como custom, que permite trabajar posteriormente con pg_restore.</p> <p>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.</p> <p>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.</p> <p>El sistema también permitió comprobar la integridad del archivo mediante SHA-256 y revisar su estructura utilizando las herramientas de PostgreSQL.</p> <p>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.</p> <p>Figura 3. Respaldo PostgreSQL generado y verificado.</p> <p>Insertar la captura del archivo .dump creado en BackupManager.</p> <ol> <li>Verificación de recuperación con pg_restore</li> </ol> <p>Una de las decisiones más importantes del proyecto fue incluir una restauración de prueba dentro de la automatización.</p> <p>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.</p> <p>Para reducir ese riesgo, el workflow utiliza un contenedor con PostgreSQL 18 que funciona como destino temporal.</p> <p>En este entorno se ejecuta pg_restore, sin restaurar directamente sobre la base original alojada en Neon.</p> <p>Después se realiza una consulta SQL para comprobar que la tabla records está disponible y que puede recuperarse su número de registros.</p> <p>La ejecución de GitHub Actions finalizó correctamente, mostrando el estado Success en las etapas de creación, restauración y cifrado del respaldo.</p> <p>Esta evidencia demuestra que el proyecto no solamente genera copias, sino que también comprueba su recuperación mediante una ejecución real.</p> <p>Figura 4. Prueba exitosa de restauración en GitHub Actions.</p> <p>Insertar la captura del workflow con los pasos pg_dump, pg_restore y cifrado finalizados correctamente.</p> <ol> <li>Protección del respaldo mediante cifrado</li> </ol> <p>La seguridad de los archivos generados constituye otro aspecto importante de la solución.</p> <p>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.</p> <p>BackupManager utiliza OpenSSL con AES-256-CBC y derivación de clave PBKDF2, configurada con 250 000 iteraciones.</p> <p>La contraseña utilizada para el cifrado se almacena como un secreto de GitHub Actions denominado BACKUP_ENCRYPTION_PASSWORD.</p> <p>Adicionalmente, se genera una suma SHA-256 del archivo cifrado para detectar posibles modificaciones.</p> <p>La contraseña no se incorpora al repositorio ni se publica junto con el respaldo.</p> <p>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.</p> <p>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.</p> <ol> <li>Despliegue automatizado mediante GitHub Actions y Render</li> </ol> <p>Además de automatizar respaldos, el proyecto incorpora un segundo workflow orientado a las pruebas del software y su despliegue.</p> <p>Este flujo está definido en el archivo ci-deploy.yml.</p> <p>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.</p> <p>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.</p> <p>La dirección del deploy hook se almacena como secreto del repositorio, evitando publicarla dentro del código fuente.</p> <p>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.</p> <p>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.</p> <p>Figura 5. Workflow de pruebas y despliegue exitoso.</p> <p>Insertar la captura de GitHub Actions con el estado Success.</p> <p>Figura 6. Aplicación publicada en Render.</p> <p>Insertar la captura del despliegue exitoso y los registros de ejecución.</p> <ol> <li>Resultados obtenidos</li> </ol> <p>La implementación permitió comprobar el funcionamiento conjunto de las herramientas utilizadas.</p> <p>Prueba realizada</p> <p>Resultado observado</p> <p>Conexión a Neon PostgreSQL 18</p> <p>Correcta</p> <p>Almacenamiento de ocho registros de prueba</p> <p>Correcto</p> <p>Generación de respaldo .dump</p> <p>Correcta</p> <p>Verificación de integridad y estructura</p> <p>Correcta</p> <p>Restauración en PostgreSQL temporal</p> <p>Exitosa</p> <p>Cifrado del archivo</p> <p>Exitoso</p> <p>Almacenamiento temporal en GitHub Actions</p> <p>Correcto</p> <p>Pruebas automatizadas de FastAPI</p> <p>Exitosas</p> <p>Solicitud automatizada de despliegue</p> <p>Exitosa</p> <p>Aplicación disponible en Render</p> <p>Verificada</p> <p>Estos resultados permiten demostrar una estrategia de respaldo que incluye generación, verificación, recuperación y protección de archivos.</p> <p>También evidencian la utilidad de automatizar tareas repetitivas mediante herramientas de integración continua.</p> <ol> <li>Limitaciones y oportunidades de mejora</li> </ol> <p>Aunque BackupManager cumple los objetivos de la práctica, su implementación tiene algunas limitaciones que deben considerarse.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <ol> <li>Conclusiones</li> </ol> <p>El desarrollo de BackupManager permitió demostrar que la automatización de respaldos es una parte importante de la administración de bases de datos.</p> <p>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.</p> <p>Asimismo, el uso de Neon y Render permitió desplegar la solución y comprobar su funcionamiento en servicios de nube.</p> <p>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.</p> <p>BackupManager constituye una implementación educativa funcional que puede ampliarse con mecanismos de almacenamiento permanente y controles adicionales de seguridad.</p> <ol> <li>Enlaces del proyecto</li> </ol> <p>Repositorio público de GitHub:<br> <a href="https://github.com/JuanCalderon1218/BackupManager" rel="noopener noreferrer">https://github.com/JuanCalderon1218/BackupManager</a></p> <p>Aplicación web desplegada en Render:<br> <a href="https://backupmanager.onrender.com" rel="noopener noreferrer">https://backupmanager.onrender.com</a></p> <p>Ejecución exitosa del respaldo automatizado:<br> <a href="https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982198297" rel="noopener noreferrer">https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982198297</a></p> <p>Ejecución exitosa de pruebas y despliegue:<br> <a href="https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982525820" rel="noopener noreferrer">https://github.com/JuanCalderon1218/BackupManager/actions/runs/38982525820</a></p> <p>Video de demostración:<br> Agregar el enlace público de YouTube cuando esté publicado.</p> <ol> <li>Referencias técnicas</li> </ol> <p>PostgreSQL Global Development Group. (s. f.). pg_dump. <a href="https://www.postgresql.org/docs/current/app-pgdump.html" rel="noopener noreferrer">https://www.postgresql.org/docs/current/app-pgdump.html</a></p> <p>PostgreSQL Global Development Group. (s. f.). pg_restore. <a href="https://www.postgresql.org/docs/current/app-pgrestore.html" rel="noopener noreferrer">https://www.postgresql.org/docs/current/app-pgrestore.html</a></p> <p>GitHub. (s. f.). GitHub Actions documentation. <a href="https://docs.github.com/en/actions" rel="noopener noreferrer">https://docs.github.com/en/actions</a></p> <p>Neon. (s. f.). Neon documentation. <a href="https://neon.com/docs" rel="noopener noreferrer">https://neon.com/docs</a></p> <p>Render. (s. f.). Render documentation. <a href="https://render.com/docs" rel="noopener noreferrer">https://render.com/docs</a></p> automation cloud database