Estrategias de respaldo de bases de datos con PostgreSQL, Django y despliegue automatizado en la nube

*Introducción
* Las bases de datos constituyen uno de los componentes más importantes de un sistema de información, debido a que almacenan información que puede ser difícil o incluso imposible de reconstruir después de una eliminación accidental, un error de la aplicación, una falla de infraestructura o una operación incorrecta.
Por esta razón, no es suficiente con almacenar información: también es necesario definir una estrategia que permita respaldarla, conservarla y restaurarla cuando ocurra un incidente.
En este proyecto se desarrolló una aplicación web utilizando Python, Django y PostgreSQL, evitando Microsoft SQL Server según lo solicitado. Además, se utilizó GitHub como repositorio público y Render como plataforma de nube para publicar la aplicación mediante un proceso de despliegue automatizado.
El proyecto fue desarrollado de manera grupal por Ana Esteban y Saúl Alvarado. En este artículo presento mi explicación individual de la solución implementada y de las estrategias de respaldo utilizadas.
Arquitectura y tecnologías utilizadas
La solución separa la aplicación web, la base de datos, el proceso de respaldo y el proceso de despliegue.
Las principales tecnologías utilizadas fueron:

• Python como lenguaje de programación.
• Django para desarrollar la aplicación web.
• PostgreSQL como sistema gestor de base de datos.
• pg_dump para generar respaldos lógicos.
• pg_restore para restaurar los respaldos.
• Git y GitHub para el control de versiones.
• Render para publicar la aplicación en la nube.
• Auto-Deploy de Render para automatizar los despliegues. La arquitectura general puede representarse de la siguiente manera: Usuario | v Aplicación Django | v PostgreSQL | +-----------> pg_dump | v Archivo de respaldo | v pg_restore | v Base de datos restaurada

De manera paralela, el código sigue este flujo:
Desarrollador
|
v
git push
|
v
GitHub
|
v
Render Auto-Deploy
|
v
Aplicación pública

Repositorio público del proyecto
Uno de los requisitos del trabajo consiste en disponer de un repositorio público para la aplicación.
El código fuente del proyecto se encuentra disponible públicamente en GitHub:
Repositorio público:
database-backup-strategies en GitHub
El repositorio contiene los archivos del proyecto Django, la aplicación encargada de administrar los registros, los scripts relacionados con los respaldos, la configuración para PostgreSQL y el archivo render.yaml utilizado para el despliegue.
Git también permite mantener un historial de cambios y registrar las contribuciones realizadas por los integrantes del equipo.
Estrategias de respaldo de la base de datos
Una estrategia de respaldo debe definir cómo se generan las copias, con qué frecuencia pueden ejecutarse, cómo se identifican y cómo podrían recuperarse posteriormente.
En este proyecto se consideraron tres conceptos principales.

1. Respaldo lógico completo PostgreSQL proporciona la herramienta pg_dump, que permite realizar respaldos lógicos de una base de datos. En PowerShell se puede generar un respaldo utilizando: pg_dump --dbname=$env:DATABASE_URL --format=custom --file=postgres_backup.dump

La opción:
--format=custom

genera un archivo en formato personalizado de PostgreSQL, adecuado para trabajar posteriormente con pg_restore.
De esta forma se obtiene un archivo como:
postgres_backup.dump

que contiene la información necesaria para reconstruir los objetos y datos incluidos en el respaldo.
Uso de fecha y hora en los respaldos
Guardar siempre el respaldo con el mismo nombre provocaría que una nueva copia pudiera reemplazar a la anterior.
Para evitarlo se puede incorporar una marca de fecha y hora:
$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"

$backupFile = "postgres_backup_$timestamp.dump"

El resultado podría ser:
postgres_backup_2026-10-03_18-30-15.dump
postgres_backup_2026-10-04_10-15-32.dump

Esta técnica permite conservar diferentes versiones del respaldo y facilita identificar cuándo fue creada cada copia.

1. Automatización de los respaldos Realizar respaldos únicamente de manera manual representa un riesgo, debido a que una persona puede olvidar ejecutar el procedimiento. Por ello, dentro del proyecto se creó el script: scripts/backup_postgres.ps1

Este script realiza un flujo similar al siguiente:
Inicio
|
v
Leer DATABASE_URL
|
v
Comprobar pg_dump
|
v
Generar fecha y hora
|
v
Ejecutar pg_dump
|
v
Crear archivo de respaldo
|
v
Comprobar resultado

El script puede ejecutarse manualmente o integrarse posteriormente con un mecanismo de programación de tareas.
Esto permite convertir el respaldo en un proceso repetible y reduce la dependencia de la intervención humana.

1. Retención de respaldos Una buena estrategia de respaldo no consiste únicamente en crear una copia. También debe determinar cuánto tiempo se conservarán los respaldos. Por ejemplo, una política de retención podría definirse de la siguiente manera: Respaldos diarios -> 7 días Respaldos semanales -> 4 semanas Respaldos mensuales -> 12 meses

Este ejemplo representa una posible política y no significa que esos períodos hayan sido implementados automáticamente en el proyecto.
En nuestra aplicación se utiliza la fecha y hora en el nombre del archivo como base para poder mantener distintas versiones.
En un entorno real, la organización debería establecer los períodos de retención dependiendo de sus necesidades de recuperación, capacidad de almacenamiento y políticas internas.
Restauración de la base de datos
Un respaldo tiene valor solamente si puede utilizarse para recuperar la información.
Para los archivos generados mediante pg_dump en formato personalizado, PostgreSQL dispone de pg_restore.
En PowerShell se puede utilizar:
pg_restore --dbname=$env:DATABASE_URL postgres_backup.dump

El flujo de recuperación es:
PostgreSQL
|
v
pg_dump
|
v
Archivo de respaldo
|
v
pg_restore
|
v
Base de datos recuperada

También es recomendable realizar pruebas periódicas de restauración.
No basta con comprobar que existe un archivo de respaldo. Es necesario asegurarse de que dicho archivo pueda utilizarse correctamente cuando realmente ocurra una pérdida de información.
Despliegue automatizado mediante GitHub y Render
Otro de los requisitos del proyecto consistía en realizar el despliegue mediante automatización.
Para conseguirlo, el repositorio de GitHub fue conectado con Render.
Cuando se realiza un cambio en el proyecto y se ejecutan comandos como:
git add .
git commit -m "Verifica despliegue automatico desde GitHub"
git push origin main

el nuevo commit queda disponible en GitHub.
Render detecta los cambios realizados sobre la rama vinculada y puede iniciar automáticamente una nueva construcción y despliegue de la aplicación.
El proceso puede representarse como:
Proyecto local
|
v
git push origin main
|
v
Repositorio GitHub
|
v
Render detecta el commit
|
v
Build
|
v
Deploy
|
v
Aplicación Live

Durante el desarrollo se comprobó este funcionamiento mediante el commit:
Verifica despliegue automatico desde GitHub

Posteriormente, un commit realizado por Saúl Alvarado para documentar el proceso de restauración también generó un nuevo Auto-Deploy.
De esta manera se obtuvo evidencia de que la actualización de la aplicación podía ejecutarse automáticamente a partir de cambios realizados en GitHub.
Publicación en nube pública
La aplicación Django fue publicada en Render, utilizando PostgreSQL como base de datos del entorno desplegado.
Actualmente la aplicación puede visualizarse públicamente aquí:
Abrir aplicación Database Backup Strategies
La interfaz permite registrar información de prueba que es almacenada mediante la aplicación.
Además, actualmente la aplicación identifica el motor utilizado como:
POSTGRESQL

Por lo tanto, la solución cumple con la condición de evitar Microsoft SQL Server.
Uso de variables de entorno
Debido a que el repositorio es público, no es recomendable almacenar directamente contraseñas o claves privadas dentro del código fuente.
La aplicación utiliza variables de entorno como:
DATABASE_URL
SECRET_KEY
DEBUG

DATABASE_URL permite proporcionar la dirección de conexión de PostgreSQL sin escribir las credenciales directamente en los archivos que se publican en GitHub.
Esta separación entre código y configuración sensible es importante cuando se trabaja con repositorios públicos.
Diferencia entre respaldo y despliegue automatizado
Uno de los conceptos importantes obtenidos durante el desarrollo es que el respaldo de una base de datos y el despliegue de una aplicación son procesos distintos.
El despliegue automatizado permite pasar de:
Nuevo código
|
v
GitHub
|
v
Render
|
v
Nueva versión de la aplicación

Mientras que el respaldo protege:
Información almacenada
|
v
PostgreSQL
|
v
pg_dump
|
v
Archivo recuperable

El Auto-Deploy facilita la publicación de nuevas versiones del software, mientras que los respaldos permiten proteger la información almacenada.
Por lo tanto, disponer de despliegue automatizado no reemplaza una estrategia de respaldo de base de datos.
Demostración en video
Como parte del proyecto se publicará un video de acceso público, con una duración máxima de cinco minutos.
En el video se mostrará:

• El repositorio público en GitHub.
• La estructura de la aplicación.
• PostgreSQL como motor de base de datos.
• La estrategia de respaldo mediante pg_dump.
• La restauración mediante pg_restore.
• El Auto-Deploy desde GitHub hacia Render.
• La aplicación funcionando en la nube. Video: ENLACE DEL VIDEO ⚠️ Antes de publicar este artículo hay que reemplazar esta línea por el enlace real del video. Conclusiones El desarrollo permitió implementar una estrategia práctica de respaldo utilizando PostgreSQL en lugar de Microsoft SQL Server. La herramienta pg_dump permite generar respaldos lógicos de la base de datos, mientras que pg_restore permite trabajar con los archivos generados en formatos compatibles para recuperar la información. Además, utilizar una marca de fecha y hora en los archivos proporciona una base sencilla para conservar diferentes versiones y posteriormente implementar una política de retención. Por otro lado, la integración entre GitHub y Render permitió automatizar el despliegue de la aplicación. Los cambios enviados al repositorio pueden generar automáticamente una nueva versión publicada en la nube. Finalmente, este proyecto demuestra que una solución completa debe considerar tanto la protección de los datos como la automatización del despliegue de la aplicación. El respaldo, la restauración, el control de versiones y el despliegue automatizado son elementos complementarios para mejorar la disponibilidad y recuperación de un sistema. Enlaces del proyecto Repositorio público: GitHub - database-backup-strategies Aplicación pública: Database Backup Strategies en Render Referencias
• PostgreSQL Global Development Group. pg_dump. Documentación oficial de PostgreSQL.
• PostgreSQL Global Development Group. pg_restore. Documentación oficial de PostgreSQL.
• PostgreSQL Global Development Group. Backup and Restore. Documentación oficial de PostgreSQL.
• Django Software Foundation. Documentación de Django.
• Render. Deploy a Django App.
• Render. Deploying on Render. Documentación corroborada: PostgreSQL: pg_dump · PostgreSQL: pg_restore · Render: Deploy a Django App · Render: Deploys y Auto-Deploy