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

ANA CECILIA ESTEBAN RAMOS — Mon, 05 Oct 2026 02:02:20 +0000

Autora: Ana Cecilia Esteban Ramos

Proyecto desarrollado con: Saúl José Alvarado Urbano

Repositorio: github.com/anaesteban1/database-backup-strategies

Aplicación en vivo: database-backup-strategies.onrender.com

Base de datos: PostgreSQL

Cloud / PaaS: Render

Resumen

La protección de la información es una responsabilidad fundamental en cualquier sistema que utilice una base de datos. Una eliminación accidental, un error de aplicación, una falla de infraestructura o una operación incorrecta pueden ocasionar pérdida de información si no existe una estrategia adecuada de respaldo y recuperación.

En este artículo presentamos la implementación práctica de una estrategia de respaldo y restauración de bases de datos utilizando PostgreSQL, evitando Microsoft SQL Server. Para ello desarrollamos una aplicación web con Python y Django, utilizamos GitHub como repositorio público, implementamos respaldos lógicos mediante pg_dump, documentamos el proceso de recuperación con pg_restore y publicamos la solución en Render.

Además, el repositorio se encuentra integrado con Render mediante Auto-Deploy, permitiendo que cada cambio enviado a la rama principal genere automáticamente una nueva versión de la aplicación desplegada en la nube.

El proyecto permite demostrar que el respaldo de una base de datos y el despliegue automatizado son procesos diferentes, pero complementarios dentro de una solución orientada a disponibilidad, recuperación y continuidad del servicio.

1. Arquitectura y stack tecnológico

La solución desarrollada separa la aplicación web, la base de datos, el proceso de respaldo y el flujo de despliegue.

[ Usuario ]
     │
     ▼
[ Aplicación Django ]
     │
     ▼
[ PostgreSQL ]
     │
     ├────────────► pg_dump
     │                  │
     │                  ▼
     │          [ Archivo de respaldo ]
     │                  │
     │                  ▼
     └────────────► pg_restore
                        │
                        ▼
             [ Base de datos recuperada ]

De manera paralela, el despliegue de la aplicación sigue el siguiente flujo:

[ Desarrollador ]
       │
       │ git push
       ▼
[ GitHub Repository ]
       │
       │ Detecta nuevo commit
       ▼
[ Render Auto-Deploy ]
       │
       ├─► Build
       ├─► Migraciones
       ├─► Deploy
       │
       ▼
[ Aplicación en Producción ]

Componentes principales

Backend: Python + Django.
Base de datos: PostgreSQL.
Herramienta de respaldo: pg_dump.
Herramienta de restauración: pg_restore.
Control de versiones: Git.
Repositorio público: GitHub.
Plataforma Cloud / PaaS: Render.
Automatización del despliegue: Render Auto-Deploy.

2. Repositorio público del proyecto

Uno de los requisitos principales del proyecto consiste en mantener el código fuente de la aplicación dentro de un repositorio público.

El proyecto completo se encuentra disponible en GitHub:

👉 Repositorio: anaesteban1/database-backup-strategies

Dentro del repositorio se encuentran los principales componentes de la solución:

database-backup-strategies/
│
├── backup_project/
├── backups/
├── scripts/
│   └── backup_postgres.ps1
├── templates/
│   └── backups/
├── manage.py
├── requirements.txt
├── render.yaml
└── README.md

El repositorio también conserva el historial de commits realizados durante el desarrollo, permitiendo evidenciar las contribuciones realizadas por los integrantes del equipo.

Importancia de GitHub: además de almacenar el código fuente, permite conservar trazabilidad sobre los cambios realizados y facilita la integración con herramientas de despliegue continuo.

3. Estrategia de respaldo con PostgreSQL

La estrategia implementada utiliza las herramientas nativas de PostgreSQL para generar respaldos lógicos de la información.

Se consideraron tres aspectos principales:

Respaldo lógico completo.
Automatización mediante script.
Retención de diferentes versiones del respaldo.

3.1. Respaldo lógico completo con `pg_dump`

PostgreSQL proporciona la herramienta pg_dump, utilizada para exportar una base de datos y generar un respaldo lógico.

En PowerShell se puede ejecutar:

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.

El resultado será un archivo similar a:

postgres_backup.dump

Este formato es especialmente útil porque posteriormente puede utilizarse con pg_restore.

Flujo del respaldo

[ PostgreSQL ]
      │
      ▼
   pg_dump
      │
      ▼
[ Archivo .dump ]

3.2. Identificación de respaldos mediante fecha y hora

Si todos los respaldos utilizaran exactamente el mismo nombre, una nueva ejecución podría reemplazar una copia anterior.

Para evitarlo se utiliza una marca de tiempo:

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"

$backupFile = "postgres_backup_$timestamp.dump"

Esto permite generar archivos como:

postgres_backup_2026-10-03_18-30-15.dump
postgres_backup_2026-10-04_09-15-32.dump
postgres_backup_2026-10-04_18-40-22.dump

De esta manera se pueden conservar diferentes versiones e identificar fácilmente cuándo fue generado cada respaldo.

3.3. Automatización del respaldo

Realizar respaldos únicamente de manera manual puede representar un riesgo, debido a que el proceso depende de que una persona recuerde ejecutarlo.

Por esta razón se implementó el script:

scripts/backup_postgres.ps1

El flujo del script es el siguiente:

[ Inicio ]
    │
    ▼
¿Existe DATABASE_URL?
    │
    ▼
¿Está disponible pg_dump?
    │
    ▼
Generar timestamp
    │
    ▼
Ejecutar pg_dump
    │
    ▼
Crear archivo .dump
    │
    ▼
Verificar resultado

Una parte esencial del script es:

if (-not $env:DATABASE_URL) {
    Write-Host "Falta la variable DATABASE_URL."
    exit 1
}

$timestamp = Get-Date -Format "yyyy-MM-dd_HH-mm-ss"

$backupFile = Join-Path `
    $OutputDirectory `
    "postgres_backup_$timestamp.dump"

pg_dump `
    --dbname=$env:DATABASE_URL `
    --format=custom `
    --file=$backupFile

El script permite estandarizar el proceso de respaldo y puede integrarse posteriormente con un mecanismo de programación de tareas.

Nota: el proyecto implementa el script necesario para automatizar el proceso. La periodicidad puede definirse posteriormente mediante un programador de tareas, un flujo CI/CD o un servicio especializado de automatización.

4. Estrategia de retención

Generar un respaldo no es suficiente. También es necesario determinar durante cuánto tiempo deberían conservarse las diferentes copias.

Una posible política de retención podría ser:

Respaldos diarios    → 7 días
Respaldos semanales  → 4 semanas
Respaldos mensuales  → 12 meses

Estos tiempos son únicamente un ejemplo de política y deben adaptarse a las necesidades reales de cada organización.

En el proyecto, la utilización de fecha y hora en el nombre de cada archivo constituye la base necesaria para conservar múltiples versiones.

En un entorno productivo también sería recomendable almacenar las copias importantes en una ubicación diferente del servidor principal.

Buena práctica: mantener la aplicación y todos sus respaldos en el mismo servidor puede provocar que una sola falla afecte tanto a los datos originales como a sus copias.

5. Restauración mediante `pg_restore`

Un respaldo solamente resulta útil si puede utilizarse para recuperar la información.

Los archivos generados mediante pg_dump en formato personalizado pueden restaurarse utilizando pg_restore.

Ejemplo:

pg_restore `
  --dbname=$env:DATABASE_URL `
  postgres_backup.dump

El proceso completo puede representarse así:

[ PostgreSQL ]
      │
      ▼
   pg_dump
      │
      ▼
[ Backup .dump ]
      │
      ▼
  pg_restore
      │
      ▼
[ PostgreSQL restaurado ]

Además de generar respaldos, una estrategia correcta debería realizar periódicamente pruebas de recuperación.

Principio importante: la existencia de un archivo de respaldo no garantiza por sí sola que la información pueda recuperarse. La restauración también debe ser comprobada.

6. Despliegue automatizado con GitHub y Render

Otro requisito del proyecto consiste en desplegar la aplicación mediante un mecanismo automatizado.

Para ello se conectó directamente el repositorio de GitHub con Render.

El flujo implementado es:

[ Proyecto local ]
       │
       ▼
git add .
       │
       ▼
git commit
       │
       ▼
git push origin main
       │
       ▼
[ GitHub ]
       │
       ▼
[ Render Auto-Deploy ]
       │
       ├─► Construcción
       ├─► Instalación de dependencias
       ├─► Migraciones
       └─► Deploy
       │
       ▼
[ Aplicación Live ]

Para comprobar el funcionamiento se realizó el siguiente commit:

git add .
git commit -m "Verifica despliegue automatico desde GitHub"
git push origin main

Después del push, Render detectó automáticamente el nuevo commit y generó un nuevo despliegue.

El historial de Render mostró:

Verifica despliegue automatico desde GitHub

Trigger: Auto-Deploy
Estado: Live

Esto permitió verificar experimentalmente el requisito de Deploy through automation.

Posteriormente, un commit realizado por Saúl Alvarado para documentar el proceso de restauración también activó un nuevo Auto-Deploy.

7. Publicación en nube pública

La aplicación fue desplegada públicamente utilizando Render, una plataforma como servicio que permite alojar aplicaciones web.

La aplicación está disponible en:

👉 Producción: https://database-backup-strategies.onrender.com

En la interfaz se muestra el estado actual:

Aplicación activa ✅
Despliegue automático GitHub → Render ✅
Motor actual: POSTGRESQL

La aplicación permite registrar información de prueba que posteriormente puede formar parte de los respaldos realizados sobre la base de datos.

Con esto se cumplen dos de los requisitos principales del proyecto:

✅ Aplicación publicada en nube pública
✅ Uso de PostgreSQL en lugar de Microsoft SQL Server

8. Variables de entorno y protección de credenciales

Debido a que el repositorio es público, las credenciales de la base de datos no deben almacenarse directamente dentro del código fuente.

La aplicación utiliza variables de entorno:

DATABASE_URL
SECRET_KEY
DEBUG

Por ejemplo:

DATABASES = {
    "default": dj_database_url.config(
        default=f"sqlite:///{BASE_DIR / 'db.sqlite3'}",
        conn_max_age=600,
        conn_health_checks=True,
    )
}

La variable DATABASE_URL permite proporcionar la conexión de PostgreSQL desde el entorno cloud sin publicar directamente:

Usuario
Contraseña
Host
Puerto
Nombre de la base de datos

Buena práctica: las credenciales y secretos nunca deberían almacenarse directamente dentro de un repositorio público.

9. Diferencia entre respaldo y Auto-Deploy

Durante el desarrollo también fue importante diferenciar dos conceptos que pueden confundirse: respaldo de base de datos y despliegue automatizado.

Auto-Deploy

Protege y automatiza el proceso de entrega del software:

Nuevo código
    │
    ▼
GitHub
    │
    ▼
Render
    │
    ▼
Nueva versión de la aplicación

Backup

Protege la información almacenada:

Datos
  │
  ▼
PostgreSQL
  │
  ▼
pg_dump
  │
  ▼
Archivo de respaldo

El Auto-Deploy permite publicar nuevas versiones de la aplicación, pero no reemplaza un respaldo de la base de datos.

Una solución confiable debe considerar ambos procesos.

10. Resultado final

Al finalizar la implementación se obtuvo el siguiente resultado:

Repositorio público: ✅ GitHub.
Aplicación web: ✅ Django.
Base de datos: ✅ PostgreSQL.
Microsoft SQL Server: ❌ No utilizado.
Respaldo lógico: ✅ pg_dump.
Restauración: ✅ pg_restore.
Script de respaldo: ✅ PowerShell.
Cloud público: ✅ Render.
Despliegue automático: ✅ GitHub → Render.
Aplicación pública: ✅ Online.

La solución completa queda representada de la siguiente manera:

                    ┌──────────────────────┐
                    │    Desarrollador     │
                    └──────────┬───────────┘
                               │
                            git push
                               │
                               ▼
                    ┌──────────────────────┐
                    │        GitHub        │
                    └──────────┬───────────┘
                               │
                         Auto-Deploy
                               │
                               ▼
                    ┌──────────────────────┐
                    │        Render        │
                    │       Django         │
                    └──────────┬───────────┘
                               │
                               ▼
                    ┌──────────────────────┐
                    │     PostgreSQL       │
                    └──────────┬───────────┘
                               │
                   ┌───────────┴───────────┐
                   │                       │
                   ▼                       ▼
               pg_dump                pg_restore
                   │                       │
                   ▼                       ▼
             Backup .dump             Recuperación

11. Demostración en video

Como parte de la actividad se realizará un video público de una duración máxima de 5 minutos.

En el video se mostrará:

El repositorio público del proyecto.
La estructura de la aplicación Django.
La utilización de PostgreSQL.
El script de respaldo.
El uso de pg_dump.
El proceso de restauración mediante pg_restore.
El Auto-Deploy desde GitHub.
El servicio desplegado en Render.
La aplicación funcionando públicamente.

🎥 Video de demostración:

PENDIENTE - AGREGAR ENLACE DE YOUTUBE

Esta URL se agregará antes de realizar la publicación definitiva del artículo.

12. Lecciones aprendidas y buenas prácticas

Un respaldo debe ser recuperable: generar archivos de respaldo no es suficiente; también debe comprobarse el proceso de restauración.
La automatización reduce errores humanos: utilizar scripts permite ejecutar procedimientos repetibles y disminuye la dependencia de acciones manuales.
Los respaldos necesitan retención: conservar distintas versiones facilita recuperar información de diferentes momentos.
Las credenciales deben permanecer fuera del repositorio: las variables de entorno permiten proteger información sensible cuando el código fuente es público.
Backup y deployment cumplen objetivos diferentes: el despliegue automatizado actualiza el software, mientras que los respaldos protegen los datos.
La trazabilidad es importante: Git y GitHub permiten mantener evidencia de los cambios realizados durante todo el desarrollo.

Conclusiones

La implementación permitió demostrar una estrategia práctica de respaldo utilizando PostgreSQL, evitando Microsoft SQL Server según las condiciones establecidas para la actividad.

El uso de pg_dump permite generar respaldos lógicos de la información, mientras que pg_restore proporciona el mecanismo necesario para recuperar archivos generados en formatos compatibles.

Asimismo, la utilización de marcas de fecha y hora proporciona una base para mantener diferentes versiones de los respaldos y aplicar posteriormente políticas de retención.

La integración entre GitHub y Render permitió automatizar el despliegue de la aplicación, verificando que un cambio enviado mediante git push puede producir automáticamente una nueva versión disponible públicamente.

Finalmente, este proyecto demuestra que una solución completa debe proteger tanto el código fuente como los datos almacenados. El control de versiones, los respaldos, la restauración, las variables de entorno y el despliegue automatizado constituyen prácticas complementarias para mejorar la confiabilidad de una aplicación.

Recursos y enlaces

Código fuente completo: GitHub - anaesteban1/database-backup-strategies
Aplicación en vivo (Producción): https://database-backup-strategies.onrender.com
Documentación oficial de PostgreSQL: https://www.postgresql.org/docs/
Documentación de pg_dump: https://www.postgresql.org/docs/current/app-pgdump.html
Documentación de pg_restore: https://www.postgresql.org/docs/current/app-pgrestore.html
Backup y Restore en PostgreSQL: https://www.postgresql.org/docs/current/backup.html
Documentación oficial de Django: https://docs.djangoproject.com/
Despliegue de Django en Render: https://render.com/docs/deploy-django
Documentación de Deploys en Render: https://render.com/docs/deploys
Video de demostración: PENDIENTE - AGREGAR ENLACE DE YOUTUBE

Autora

Ana Cecilia Esteban Ramos

Universidad Privada de Tacna

Escuela Profesional de Ingeniería de Sistemas

Curso: Base de Datos II

DEV Community: ANA CECILIA ESTEBAN RAMOS