BackupManager: Sistema de Gestión y Recuperación de Respaldos en PostgreSQL

Juan Carlos Calderón Rodríguez — Sat, 17 Oct 2026 00:19:18 +0000

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.

6.2. Demostración audiovisual de BackupManager

Como evidencia complementaria del proyecto, se elaboró un video de demostración donde se presenta la arquitectura, el desarrollo y el funcionamiento de BackupManager.

En la presentación se explica la integración de FastAPI con PostgreSQL en Neon, la generación de respaldos, la verificación de integridad, las pruebas de restauración, la automatización mediante GitHub Actions y el despliegue en Render.

La exposición fue desarrollada por Juan Carlos Calderón Rodríguez y Franco Mango Puma, integrantes del proyecto del curso de Base de Datos II.

Enlace al video: Demostración de BackupManager en YouTube

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

DEV Community: Juan Carlos Calderón Rodríguez