Introducción
En el curso de Base de Datos II desarrollé BackupManager, una aplicación web orientada a la gestión de respaldos y recuperación de información almacenada en PostgreSQL.
El objetivo de este trabajo fue implementar una solución que permitiera realizar respaldos reales de una base de datos, verificar la integridad de los archivos generados y comprobar que la información pudiera recuperarse correctamente.
Para desarrollar el sistema utilicé Python con FastAPI, PostgreSQL y diferentes servicios en la nube. Además, incorporé herramientas de automatización para que los procesos de respaldo y despliegue pudieran ejecutarse sin depender únicamente de una operación manual.
Durante el desarrollo pude comprobar el funcionamiento de la aplicación tanto en un entorno local como desde Internet, utilizando una base de datos alojada en Neon y un servicio web publicado en Render.
1. Tecnologías utilizadas
Para la implementación de BackupManager seleccioné herramientas que permitieran desarrollar una aplicación web, conectar una base de datos PostgreSQL en la nube y automatizar las operaciones de respaldo.
Tabla 1. Tecnologías utilizadas en BackupManager
| Tecnología | Función en el proyecto |
|---|---|
| Python | Lenguaje de programación utilizado en el backend |
| FastAPI | Desarrollo de la API y lógica del sistema |
| PostgreSQL 18 | Almacenamiento y gestión de la información |
| SQLAlchemy | Comunicación entre Python y PostgreSQL |
| Neon | Alojamiento de PostgreSQL en la nube |
| Render | Despliegue público de la aplicación web |
| Docker | Preparación del entorno de ejecución |
| GitHub | Repositorio público del código fuente |
| GitHub Actions | Automatización de respaldos, pruebas y despliegues |
La arquitectura utilizada permite separar la aplicación de la base de datos. Mientras Render ejecuta el backend y la interfaz web, Neon se encarga de almacenar la información de manera independiente.
Esta separación permite acceder al sistema desde Internet sin necesidad de mantener encendida la computadora utilizada durante el desarrollo.
El código fuente y la aplicación se encuentran disponibles en los siguientes enlaces:
Repositorio GitHub: BackupManager - Código fuente
Aplicación desplegada: BackupManager - Aplicación web
2. Funcionamiento general del sistema
BackupManager cuenta con una interfaz web organizada en cuatro apartados principales: Resumen, Registros, Respaldos e Historial.
Cada apartado permite acceder a las diferentes funcionalidades implementadas para administrar información y realizar operaciones de respaldo.
En la sección Resumen se presenta el estado general de la aplicación, incluyendo el motor de base de datos utilizado, la cantidad de registros existentes y los respaldos completos que han sido generados.
Figura 1. Panel principal y estado general de BackupManager.
En la Figura 1 se observa el panel principal del sistema, donde se presenta información sobre su funcionamiento. La interfaz muestra la conexión activa con PostgreSQL, ocho registros almacenados y un respaldo completo generado. También se encuentran disponibles las opciones para crear nuevas copias de seguridad y consultar el historial de operaciones.
2.1. Gestión de registros
En el módulo de registros se pueden agregar, consultar, modificar y eliminar datos. Estas operaciones permiten trabajar con información almacenada directamente en PostgreSQL.
Para comprobar la conexión con la base de datos, ingresé ocho registros de prueba desde BackupManager. Posteriormente, accedí al panel de Neon y consulté la tabla records para verificar que la información se hubiera almacenado correctamente.
Los datos registrados contenían información relacionada con servidores, estaciones de trabajo y dispositivos de red.
Figura 2. Registros almacenados en PostgreSQL mediante Neon.
En la Figura 2 se visualiza la información almacenada en la tabla records de PostgreSQL. Se pueden observar los identificadores de cada registro, sus nombres, categorías, cantidades y fechas de creación. Esta comprobación permitió confirmar que los datos ingresados desde BackupManager se encontraban almacenados correctamente en la base de datos alojada en Neon.
2.2. Estructura de la base de datos
La aplicación utiliza diferentes tablas para administrar los registros y mantener información relacionada con las operaciones realizadas.
Tabla 2. Tablas principales de BackupManager
| Tabla | Descripción |
|---|---|
records | Almacena los registros administrados desde la aplicación |
audit_events | Registra información relacionada con las operaciones realizadas |
full_backups | Almacena los metadatos de los respaldos completos generados |
Estas tablas permiten separar los datos principales del sistema de la información relacionada con su administración y los respaldos.
3. Estrategias de respaldo de bases de datos
Un respaldo o backup consiste en conservar una copia de la información para que pueda recuperarse ante una eliminación accidental, un fallo del sistema o cualquier situación que comprometa la disponibilidad de los datos.
Contar con una estrategia de respaldo es importante porque permite reducir el impacto de estos incidentes y facilita la recuperación de la información.
Existen diferentes tipos de respaldos, entre los cuales destacan los completos, incrementales y diferenciales.
Tabla 3. Comparación de estrategias de respaldo
| Estrategia | Características | Estado en BackupManager |
|---|---|---|
| Completo | Conserva el esquema y los datos de la base de datos | Implementado con pg_dump |
| Parcial | Conserva información específica de una tabla | Implementado mediante JSON |
| Incremental | Respalda los cambios posteriores a una copia anterior | No implementado |
| Diferencial | Respalda los cambios desde el último respaldo completo | No implementado |
En esta versión de BackupManager se implementaron dos modalidades: la exportación parcial de registros en JSON y el respaldo lógico completo de PostgreSQL.
3.1. Respaldo parcial en formato JSON
Esta función permite exportar la información de la tabla records y conservarla en un archivo JSON.
Su principal utilidad es recuperar un conjunto específico de registros sin necesidad de restaurar todas las tablas de la base de datos.
La aplicación permite generar y descargar estos archivos. También incorpora una operación de restauración parcial, mediante la cual se puede recuperar el contenido de la tabla respaldada.
Esta modalidad es adecuada para trabajar con conjuntos pequeños de información, aunque no reemplaza un respaldo completo de PostgreSQL.
3.2. Respaldo completo de PostgreSQL
Para implementar los respaldos completos se utilizó pg_dump, una herramienta de PostgreSQL que permite realizar exportaciones lógicas del esquema y los datos de una base de datos.
El comando básico utilizado sigue la siguiente estructura:
pg_dump --format=custom --no-owner --no-acl --file=respaldo.dump La opción --format=custom genera un archivo de respaldo en formato personalizado, que posteriormente puede procesarse mediante pg_restore.
Durante la prueba de recuperación se utilizaron las opciones --no-owner y --no-acl de pg_restore para evitar restablecer los propietarios y privilegios originales. Esto facilitó la restauración del respaldo en una base de datos temporal e independiente.
En BackupManager, los parámetros de conexión se obtienen mediante variables de entorno privadas para evitar almacenar las credenciales directamente en el código fuente.
Durante las pruebas ejecuté la generación de un respaldo desde la aplicación y obtuve un archivo .dump de aproximadamente 6.2 KB.
El archivo se generó correctamente y pudo descargarse desde la interfaz web.
Figura 3. Generación y registro de un respaldo completo de PostgreSQL.
En la Figura 3 se observa el módulo de respaldos de BackupManager, donde se encuentra registrado el archivo generado mediante pg_dump. El sistema muestra información sobre el identificador del respaldo, su fecha de creación y su tamaño. Además, permite descargar el archivo y verificar su integridad mediante las funciones disponibles en la interfaz.
3.3. Verificación de integridad
Después de generar el respaldo, utilicé la opción Verificar, implementada en BackupManager.
Esta función realiza dos comprobaciones principales.
La primera consiste en calcular el valor SHA-256 del archivo y compararlo con el registrado cuando se creó el respaldo. Esto permite detectar si su contenido ha cambiado.
La segunda comprobación utiliza pg_restore --list para verificar que PostgreSQL pueda reconocer la estructura interna del archivo.
Durante las pruebas, ambas comprobaciones finalizaron correctamente.
Sin embargo, la verificación de integridad no garantiza por sí sola que los datos puedan recuperarse. Por esta razón, también fue necesario implementar una prueba de restauración.
4. Automatización de respaldos con GitHub Actions
Una de las funcionalidades principales de BackupManager es la automatización de los respaldos mediante GitHub Actions.
Para implementar este procedimiento configuré un archivo YAML dentro de la carpeta .github/workflows del repositorio.
El workflow permite ejecutar respaldos manualmente y también dispone de una programación diaria.
El proceso está organizado en diferentes etapas, desde la conexión con la base de datos hasta el almacenamiento del archivo cifrado.
Tabla 4. Etapas del proceso automatizado de respaldo
| Etapa | Operación realizada |
|---|---|
| 1. Conexión | Acceso a PostgreSQL alojado en Neon |
| 2. Exportación | Generación del respaldo mediante pg_dump |
| 3. Restauración | Recuperación del respaldo utilizando pg_restore |
| 4. Comprobación | Consulta de la tabla restaurada |
| 5. Cifrado | Protección del archivo mediante AES-256 |
| 6. Almacenamiento | Conservación del artefacto cifrado durante siete días |
4.1. Prueba de restauración
Para comprobar la recuperación de la información, el workflow utiliza una base PostgreSQL temporal e independiente.
En este entorno se ejecuta pg_restore, lo que permite reconstruir el contenido del respaldo sin modificar los datos de la base de producción.
Después de realizar la restauración, el proceso consulta la tabla records para verificar que está disponible y que puede obtenerse su cantidad de registros.
La ejecución finalizó correctamente, lo que permitió comprobar que el archivo generado pudo restaurarse en el entorno de prueba.
Figura 4. Ejecución satisfactoria del respaldo automatizado y la prueba de restauración.
En la Figura 4 se muestra el resultado de la ejecución del workflow configurado en GitHub Actions. El proceso finalizó con estado Success, después de completar las operaciones de generación del respaldo, restauración en PostgreSQL y cifrado del archivo. Esta evidencia confirma que el procedimiento de recuperación pudo ejecutarse correctamente en un entorno independiente.
Evidencia del proceso:
Ver ejecución del respaldo y restauración en GitHub Actions
4.2. Cifrado de los archivos de respaldo
Después de realizar la restauración de prueba, el workflow cifra el archivo generado utilizando AES-256-CBC con derivación de clave mediante PBKDF2.
Esta operación agrega una medida de protección para evitar que el contenido del respaldo quede almacenado directamente como un archivo sin cifrar.
Posteriormente, el archivo cifrado se conserva como artefacto en GitHub Actions durante siete días.
Aunque este procedimiento permite demostrar el almacenamiento temporal de respaldos, en un entorno de producción sería necesario utilizar un servicio de almacenamiento externo con políticas de seguridad y conservación más completas.
5. Despliegue de BackupManager en la nube
Para publicar BackupManager utilicé Render, conectándolo con el repositorio público del proyecto en GitHub.
Previamente configuré una base PostgreSQL en Neon y comprobé su conexión desde la aplicación ejecutada localmente.
Una vez verificado el funcionamiento, preparé el despliegue mediante Docker y configuré las variables de entorno necesarias para conectar la aplicación con PostgreSQL.
Durante el procedimiento fue necesario actualizar las herramientas cliente de PostgreSQL a la versión 18, debido a que inicialmente algunos archivos estaban configurados para una versión anterior.
Después de completar la configuración, BackupManager quedó disponible desde una dirección pública.
5.1. Automatización del despliegue
Además del respaldo automático, configuré un segundo workflow en GitHub Actions para ejecutar las pruebas del backend y solicitar nuevos despliegues en Render.
El procedimiento comienza cuando se envían cambios a la rama principal del repositorio o cuando se ejecuta manualmente.
Primero se instalan las dependencias y se realizan las pruebas automatizadas de la aplicación.
Si estas pruebas finalizan correctamente, GitHub Actions utiliza un deploy hook para solicitar la actualización del servicio en Render.
De esta manera, los cambios enviados al repositorio pueden pasar por un proceso de comprobación antes de solicitar su publicación.
Figura 5. Ejecución correcta del proceso automatizado de pruebas y despliegue.
En la Figura 5 se observa el resultado del workflow encargado de ejecutar las pruebas del backend y solicitar el despliegue de BackupManager en Render. El proceso finalizó correctamente, lo que permitió comprobar la integración entre el repositorio de GitHub, las pruebas automatizadas y el mecanismo de despliegue configurado para la aplicación.
Evidencia del proceso:
Ver ejecución de CI y despliegue en GitHub Actions
6. Pruebas y resultados obtenidos
Después de completar el desarrollo y la configuración de los servicios, realicé diferentes pruebas para comprobar el funcionamiento de BackupManager.
Estas incluyeron la conexión con PostgreSQL, el almacenamiento de registros, la generación de respaldos, la verificación de integridad y la recuperación automatizada.
Tabla 5. Resultados de las pruebas funcionales
| Prueba realizada | Resultado |
|---|---|
| Conexión de FastAPI con PostgreSQL en Neon | Correcto |
| Registro de información desde BackupManager | Correcto |
| Comprobación de ocho registros en Neon | Correcto |
Generación de respaldo completo .dump | Correcto |
| Descarga del archivo de respaldo | Correcto |
| Verificación de integridad SHA-256 | Correcto |
| Restauración en una base PostgreSQL temporal | Correcto |
| Ejecución automatizada del respaldo | Correcto |
| Pruebas automatizadas del backend | Correcto |
| Solicitud de despliegue mediante GitHub Actions | Correcto |
| Publicación de BackupManager en Render | Correcto |
Los resultados permitieron comprobar que la aplicación trabaja con una base de datos PostgreSQL real y que las operaciones de respaldo y recuperación pueden ejecutarse satisfactoriamente.
Una de las pruebas más importantes fue la restauración automatizada, debido a que permitió verificar el contenido del respaldo en una base temporal sin afectar la información original.
6.1. Limitaciones identificadas
Aunque el sistema cumple con las funcionalidades principales de esta práctica, existen algunos aspectos que podrían mejorarse.
Uno de ellos es el almacenamiento de los respaldos. En el plan gratuito de Render, los archivos guardados localmente no tienen persistencia garantizada después de reinicios o nuevos despliegues.
Por esta razón, los respaldos deben conservarse fuera del servidor. En esta implementación se utilizó GitHub Actions para almacenar temporalmente copias cifradas.
Para una implementación de mayor alcance sería conveniente incorporar almacenamiento externo permanente, políticas de retención, monitoreo de errores y mecanismos de recuperación a un punto específico en el tiempo.
7. Conclusiones
El desarrollo de BackupManager me permitió aplicar conceptos relacionados con la protección y recuperación de bases de datos mediante el uso de PostgreSQL.
Durante el trabajo pude comprobar que generar una copia de seguridad no es suficiente para garantizar la recuperación de información. También resulta necesario verificar la integridad de los archivos y realizar pruebas de restauración.
Otro aspecto importante fue la automatización. Mediante GitHub Actions fue posible ejecutar procesos de respaldo y comprobación de manera programada, reduciendo la necesidad de intervención manual.
Además, la integración de FastAPI, Neon y Render permitió publicar una aplicación funcional que trabaja con una base de datos PostgreSQL alojada en la nube.
Finalmente, BackupManager constituye una implementación práctica de respaldo, verificación y recuperación de datos. Aunque todavía puede ampliarse con otras estrategias y mecanismos de almacenamiento, permitió comprobar el funcionamiento de herramientas reales utilizadas en la administración de bases de datos.
Referencias
- PostgreSQL Global Development Group. pg_dump — PostgreSQL 18. https://www.postgresql.org/docs/18/app-pgdump.html
- PostgreSQL Global Development Group. pg_restore — PostgreSQL 18. https://www.postgresql.org/docs/18/app-pgrestore.html
- GitHub. GitHub Actions Documentation. https://docs.github.com/en/actions
- Neon. Neon Documentation. https://neon.com/docs
- Render. Render Documentation. https://render.com/docs
