DEV Community: SAUL JOSE ALVARADO URBANO

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

SAUL JOSE ALVARADO URBANO — Sat, 10 Oct 2026 15:23:52 +0000

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

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

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"

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

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

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

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

Repositorio GitHub: https://github.com/anaesteban1/database-backup-strategies
Aplicación pública en la nube: https://database-backup-strategies.onrender.com
Demostración en video: (Pendiente - agregar la URL pública antes de publicar el artículo)

Referencias

Django Software Foundation. (s. f.). Documentación de Django. https://docs.djangoproject.com/
PostgreSQL Global Development Group. (s. f.). pg_dump. Documentación de PostgreSQL. https://www.postgresql.org/docs/current/app-pgdump.html
PostgreSQL Global Development Group. (s. f.). pg_restore. Documentación de PostgreSQL. https://www.postgresql.org/docs/current/app-pgrestore.html
PostgreSQL Global Development Group. (s. f.). Copias de seguridad y restauración. Documentación de PostgreSQL. https://www.postgresql.org/docs/current/backup.html
Render. (s. f.). Desplegar una aplicación Django. https://render.com/docs/deploy-django

Implementación de DevSecOps con Bearer SAST y GitHub Actions: De la Detección a la Remediación

SAUL JOSE ALVARADO URBANO — Mon, 05 Oct 2026 15:25:50 +0000

Autor: Saúl Jose Alvarado Urbano
Autor: Ana Cecilia Esteban Ramos
Repositorio: github.com/saulalvarado1/Bearer_Articulo

API en Vivo: bearer-articulo.onrender.com

Resumen (Abstract)

En el desarrollo de software moderno, la seguridad ya no puede ser una fase tardía o una auditoría aislada antes del lanzamiento a producción. El paradigma Shift-Left propone integrar la seguridad desde las primeras etapas del ciclo de vida del desarrollo de software (SSDLC).

En este artículo técnico presentamos la implementación práctica de un flujo DevSecOps completo para una API REST construida con Node.js y Express. Configuramos un pipeline de Integración Continua (CI) en GitHub Actions utilizando Bearer CLI, una herramienta avanzada de Análisis Estático de Seguridad de Aplicaciones (SAST) especializada en la detección de fallas OWASP Top 10 y riesgos de privacidad/fuga de datos (PII). Demostramos cómo el pipeline bloquea automáticamente código vulnerable ante una fuga de credenciales en logs (CWE-134 / Insecure Logging), y cómo se aplica la remediación para alcanzar un despliegue seguro.

1. Arquitectura y Stack Tecnológico

El flujo implementado conecta las herramientas de desarrollo, análisis estático y automatización:

[ Desarrollador ] 
       │  (git push)
       ▼
[ GitHub Repository ] 
       │  (Trigger Workflow)
       ▼
[ GitHub Actions Runner ]
       │
       ├─► 1. Checkout de Código
       ├─► 2. Escaneo SAST con Bearer CLI
       │      ├── ¿Hay vulnerabilidades HIGH / CRITICAL?
       │      ├── [SÍ] ──► ❌ PIPELINE FALLA (Bloqueo de despliegue)
       │      └── [NO] ──► ✅ PIPELINE EXITOSO
       ▼
[ Despliegue en la Nube (Render / Cloud SaaS) ]

Componentes:

Backend: Node.js & Express (API modular y ligera).
Herramienta SAST: Bearer CLI (Motor de análisis de flujo de datos sensibles y patrones de vulnerabilidad).
Orquestador CI/CD: GitHub Actions (Automatización de pruebas y compuertas de calidad).
Entorno Cloud: Render (Plataforma como Servicio - PaaS para despliegue continuo).

2.Configuración del Pipeline de Seguridad (CI)

Para automatizar la verificación de seguridad en cada cambio de código, definimos el flujo en el archivo .github/workflows/bearer-scan.yml:

yaml
name: Bearer SAST Scan & Security Pipeline

on:
  push:
    branches: [ "main", "master" ]
  pull_request:
    branches: [ "main", "master" ]

jobs:
  security_scan:
    name: Bearer SAST Security Analysis
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Run Bearer CLI Scanner
        uses: bearer/bearer-action@v2
        with:
          # Falla el pipeline si encuentra vulnerabilidades de severidad alta o crítica
          severity: "high,critical"
          # Escanea todo el repositorio
          diff: false

¿Por qué Bearer?

A diferencia de los linters tradicionales o analizadores puramente sintácticos, Bearer rastrea el flujo de datos (dataflow) desde las fuentes de entrada (sources) hasta los puntos de salida (sinks). Esto le permite identificar con precisión si información personal identificable (PII), secretos o credenciales están siendo expuestos o mal manejados.

3. Caso Práctico: Introducción Intencional de una Vulnerabilidad

En el endpoint de autenticación (/api/login), se simuló un error común pero crítico en el desarrollo de software: el registro no sanitizado de credenciales de usuario para fines de depuración (debugging).

Código vulnerable original (`server.js`):

app.post('/api/login', (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ error: 'Email y contraseña requeridos' });
  }

  // ALERTA SAST: Imprimir contraseñas y PII en logs estándar (CWE-134 / CWE-532)
  console.log(`[AUTH-LOG] Intento de login para usuario: ${email} con credencial: ${password}`);

  const user = users.find(u => u.email === email);
  if (user && password === 'admin123') {
    return res.json({
      message: 'Autenticación exitosa',
      token: 'jwt-simulated-token-bearer-demo',
      user: { id: user.id, email: user.email, name: user.name }
    });
  }

  return res.status(401).json({ error: 'Credenciales inválidas' });
});

4. Detección y Bloqueo en GitHub Actions (Compuerta de Calidad)

Al realizar el push hacia el repositorio remoto, el runner de GitHub Actions ejecutó el escaneo de Bearer.

Resultado del Análisis:

Bearer detectó la vulnerabilidad de severidad HIGH y finalizó el proceso con código de salida 1, deteniendo inmediatamente la integración:

HIGH: Unsanitized user input in format string [CWE-134]
https://docs.bearer.com/reference/rules/javascript_lang_format_string_using_user_input

File: server.js:54
54  console.log(`[AUTH-LOG] Intento de login para usuario: ${email} con credencial: ${password}`);

87 checks, 1 findings
CRITICAL: 0
HIGH: 1 (CWE-134)
Error: Process completed with exit code 1.

Impacto de Seguridad: Registrar credenciales en texto claro (password) y datos no sanitizados en los flujos de salida del servidor viola normas de cumplimiento como GDPR, HIPAA y PCI-DSS, además de exponer los datos en sistemas centralizados de agregación de logs (CloudWatch, Datadog, ELK).

5. Fase de Remediación (Fix)

Para resolver el problema sin comprometer la trazabilidad de eventos del sistema, aplicamos el principio de Mínimo Privilegio en Logs:

Eliminar completamente el registro de contraseñas u otros datos sensibles.
Evitar concatenaciones de cadenas no sanitizadas con datos directos provenientes del cliente.
Registrar únicamente el evento de autenticación genérico.

Código corregido (`server.js`):

app.post('/api/login', (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ error: 'Email y contraseña requeridos' });
  }

  // PRÁCTICA SEGURA: Registro de eventos sin exponer datos sensibles ni formatos dinámicos
  console.log('[AUTH-LOG] Intento de login');

  const user = users.find(u => u.email === email);
  if (user && password === 'admin123') {
    return res.json({
      message: 'Autenticación exitosa',
      token: 'jwt-simulated-token-bearer-demo',
      user: { id: user.id, email: user.email, name: user.name }
    });
  }

  return res.status(401).json({ error: 'Credenciales inválidas' });
});

6. Verificación de Seguridad y Aprobación del Pipeline

El equipo subió la remediación mediante el commit:
fix: remove sensitive login data from logs

Resultado del nuevo escaneo:

Checks ejecutados: 87
Hallazgos Críticos: 0
Hallazgos Altos: 0
Estado del Pipeline: SUCCESS (Verde ✅)

Al no encontrarse infracciones de severidad alta o crítica, el pipeline aprueba los artefactos y autoriza el paso al despliegue continuo en la nube pública.

7. Lecciones Aprendidas y Buenas Prácticas DevSecOps

La seguridad como código (Security as Code): Definir políticas de escaneo en archivos versionables (.yml) garantiza consistencia y auditoría en cada contribución.
Retroalimentación temprana: Detectar vulnerabilidades en el momento del pull request reduce drásticamente el costo temporal y financiero de mitigar incidentes en producción.
Equilibrio entre seguridad y velocidad: Configurar filtros de severidad (high,critical) previene falsos positivos que puedan frenar innecesariamente el ritmo de entrega del equipo de ingeniería.
Protección de PII: Las herramientas modernas de SAST deben comprender el contexto de privacidad y no limitarse únicamente a inyecciones SQL o XSS tradicionales.

Recursos y Enlaces

Código fuente completo: GitHub - saulalvarado1/Bearer_Articulo
Aplicación en Vivo (Producción): https://bearer-articulo.onrender.com
Documentación oficial de Bearer: https://docs.bearer.com/
CWE-134 (Use of Externally-Controlled Format String): https://cwe.mitre.org/data/definitions/134.html
CWE-532 (Insertion of Sensitive Information into Log File): https://cwe.mitre.org/data/definitions/532.html