DEV Community

SAUL JOSE ALVARADO URBANO
SAUL JOSE ALVARADO URBANO

Posted on

Respaldo y recuperación de PostgreSQL con despliegue automatizado en la nube

#automation #cloud #database #postgres

UNIVERSIDAD PRIVADA DE TACNA

FACULTAD DE INGENIERÍA

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

Artículo Técnico para el curso: BASE DE DATOS II

Estudiante: Alvarado Urbano, Saul José (2023078332)

Estudiante: Esteban Ramos, Ana Cecilia (2023078688)

Docente: Ing. Patrick Josue Cuadros Quiroga

TACNA - PERÚ | 2026

Introducción

La utilidad real de un respaldo se comprueba cuando la información puede recuperarse después de una falla. Por ello, una estrategia de protección de datos no debe limitarse a generar archivos: también debe considerar la frecuencia de las copias, su conservación, la restauración y la comprobación de que el contenido recuperado es utilizable.
Este artículo presenta mi análisis individual del proyecto Database Backup Strategies, desarrollado junto con Ana Esteban. La solución evita Microsoft SQL Server y utiliza PostgreSQL, Django, GitHub y Render. Mi enfoque se centra principalmente en la recuperabilidad de la información y en la continuidad operativa del sistema.
El proyecto combina una aplicación pública en Django, una base de datos PostgreSQL, respaldos lógicos mediante pg_dump, recuperación mediante pg_restore, un repositorio público de GitHub y un flujo de despliegue automático hacia Render.

1. Contexto y arquitectura de la solución

La solución separa la ejecución de la aplicación, la persistencia de los datos, la generación de respaldos y el despliegue en la nube. Django atiende las solicitudes del usuario; PostgreSQL conserva la información; pg_dump crea respaldos lógicos; y pg_restore permite reconstruir la base de datos a partir de una copia compatible.

  • Django: framework de la aplicación web.
  • PostgreSQL: motor de base de datos en producción.
  • pg_dump: para crear archivos de respaldo lógico.
  • pg_restore: para recuperar respaldos en formato personalizado.
  • GitHub: repositorio público y plataforma de colaboración.
  • Render: servicio de nube pública con Auto-Deploy. 
Usuario
   │
   ▼
Aplicación Django
   │
   ▼
PostgreSQL
   │
   ├── pg_dump ────► Respaldo
   │
   └── pg_restore ──► Base de datos recuperada
Enter fullscreen mode Exit fullscreen mode

2. Repositorio público y trabajo colaborativo

El proyecto se mantiene en un repositorio público de GitHub que contiene el código fuente, la configuración de PostgreSQL, el script de respaldo, el archivo render.yaml y la documentación. El uso de Git permite conservar el historial de cambios y evidenciar el trabajo realizado por cada integrante.

  • Repositorio público: https://github.com/anaesteban1/database-backup-strategies Como parte de mi contribución, documenté el proceso de restauración de respaldos. Este cambio quedó registrado como commit en el repositorio y posteriormente activó un nuevo despliegue automático en Render, demostrando tanto la colaboración del equipo como el funcionamiento del flujo de integración.

3. Estrategia de respaldo con PostgreSQL

3.1 Respaldo lógico mediante pg_dump

PostgreSQL incorpora pg_dump para exportar de forma lógica la información de una base de datos. En el proyecto se emplea el formato personalizado porque puede ser restaurado posteriormente con pg_restore y facilita la administración del archivo de recuperación.

pg_dump --dbname=$env:DATABASE_URL --format=custom --file=postgres_backup.dump
Enter fullscreen mode Exit fullscreen mode

Para conservar diferentes puntos de recuperación se utiliza una marca de fecha y hora en el nombre de cada archivo, evitando que una ejecución posterior sobrescriba el respaldo anterior.

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"
$backupFile = "postgres_backup_$timestamp.dump"
Enter fullscreen mode Exit fullscreen mode

3.2 Automatización del proceso

El repositorio contiene el script scripts/backup_postgres.ps1. Este script valida la variable DATABASE_URL, ejecuta pg_dump, genera el archivo correspondiente y comprueba el resultado del comando. De esta manera, el mismo procedimiento puede repetirse sin escribir manualmente todos los parámetros en cada ocasión.
En un entorno real, este script puede programarse mediante el Programador de tareas de Windows, un flujo de CI/CD o un servicio de automatización. El propósito es disminuir la dependencia de una ejecución manual y mantener una frecuencia de respaldo definida.

3.3 Retención y puntos de recuperación

Mantener únicamente la copia más reciente puede ser insuficiente, porque un error o una modificación no deseada también podría estar presente en ese archivo. Una política de retención conserva varios respaldos para poder elegir un punto de recuperación anterior que se considere válido.
Una política sencilla podría conservar siete copias diarias, cuatro semanales y doce mensuales. La cantidad exacta dependerá del objetivo de recuperación, del espacio disponible y de la importancia de la información. Los nombres con fecha y hora utilizados en el proyecto permiten implementar posteriormente este tipo de rotación.

4. Restauración y validación de la recuperación

Una estrategia de respaldo está incompleta si no existe un procedimiento de restauración. Los archivos creados por pg_dump en formato personalizado pueden recuperarse mediante pg_restore sobre una base de datos PostgreSQL.

pg_restore --dbname=DATABASE_URL postgres_backup.dump
Enter fullscreen mode Exit fullscreen mode

La restauración debe probarse de forma periódica en un entorno controlado. Esta prueba permite comprobar que el archivo se puede leer, que los objetos de la base de datos se reconstruyen y que la información recuperada es correcta. Por ello, validar la recuperación es tan importante como generar el respaldo.

5. Despliegue automatizado con GitHub y Render

El despliegue de la aplicación funciona de manera independiente del respaldo de la base de datos. El repositorio público se encuentra conectado a Render y la rama main utiliza Auto-Deploy. Cada vez que se publica un nuevo commit, Render detecta el cambio, reconstruye la aplicación y publica automáticamente una nueva versión.

git add .
git commit -m "Documenta proceso de restauracion de respaldos"
git push origin main
Enter fullscreen mode Exit fullscreen mode

Mi commit de documentación del proceso de restauración produjo un nuevo despliegue automático. Esta evidencia confirma que los cambios realizados por distintos colaboradores pasan por el mismo flujo de entrega sin necesidad de ejecutar un despliegue manual desde Render.

Colaborador
   │
   ▼ (git push origin main)
GitHub
   │
   ▼
Auto-Deploy de Render
   │
   ▼
Aplicación publicada
Enter fullscreen mode Exit fullscreen mode

6. Publicación en nube pública

La aplicación Django se encuentra publicada en Render y utiliza PostgreSQL como base de datos. El sitio permite registrar información de prueba, lo que facilita demostrar el tipo de datos que deben protegerse mediante una estrategia de respaldo y recuperación.

  • Aplicación pública: https://database-backup-strategies.onrender.com La interfaz indica que la aplicación está activa, que el despliegue automático desde GitHub se encuentra habilitado y que el motor utilizado es PostgreSQL. De esta forma se cumple el requisito de publicar la aplicación en un proveedor público sin utilizar Microsoft SQL Server.

7. Buenas prácticas operativas

En un entorno de producción, los respaldos importantes deberían almacenarse también fuera del servidor principal. Mantener la base de datos y todas sus copias en una misma infraestructura crea un único punto de falla. También es recomendable cifrar los respaldos cuando contengan información sensible y supervisar las ejecuciones programadas.
Las credenciales de producción tampoco deben almacenarse en el repositorio público. El proyecto utiliza variables de entorno como DATABASE_URL, SECRET_KEY y DEBUG para separar los datos sensibles del código fuente y evitar su exposición en GitHub.
Además, una estrategia madura debe establecer objetivos de recuperación y realizar pruebas periódicas de restauración. No basta con confirmar que un archivo existe; es necesario comprobar que puede utilizarse para recuperar la información dentro del tiempo esperado.

8. Demostración en video

Se publicará un video de acceso público de no más de cinco minutos. En él se mostrará el repositorio, la estrategia de respaldo y restauración de PostgreSQL, el commit que activa el Auto-Deploy, el historial de despliegues de Render y la aplicación funcionando públicamente.

Conclusiones

El proyecto demuestra que una estrategia efectiva de respaldo debe enfocarse en la posibilidad real de recuperar la información. PostgreSQL proporciona pg_dump para generar respaldos lógicos y pg_restore para restaurarlos, mientras que la identificación por fecha y hora facilita mantener distintos puntos de recuperación.
También se comprobó que el respaldo de datos y la entrega del software son procesos diferentes. GitHub y Render automatizan la publicación de los cambios de la aplicación, mientras el script de respaldo y el procedimiento de restauración protegen la información almacenada en PostgreSQL.
La combinación de repositorio público, respaldo y restauración, despliegue automatizado y alojamiento en la nube permite cumplir los requisitos del trabajo y proporciona una base que puede ampliarse con políticas de retención, almacenamiento externo y pruebas periódicas de recuperación.

Enlaces del proyecto

Referencias

Top comments (0)