Implementación de copias de seguridad programadas, recuperación de información, cifrado y despliegue en la nube con Render y Neon
- Introducción
Hoy en día, las bases de datos son una parte fundamental de cualquier aplicación web, ya que almacenan información que necesita estar disponible y protegida. Sin embargo, una falla del sistema, un error humano o la eliminación accidental de registros puede ocasionar la pérdida de datos importantes.
Por esta razón, no basta con tener una base de datos funcionando correctamente. También es necesario contar con mecanismos que permitan generar copias de seguridad y recuperar la información cuando se presente algún problema.
En este artículo se presenta una estrategia de automatización y recuperación de respaldos utilizando PostgreSQL como alternativa a Microsoft SQL Server. Para ello, se trabaja con el proyecto BackupManager, desarrollado con FastAPI y conectado a una base de datos PostgreSQL alojada en Neon.
La propuesta utiliza GitHub Actions para ejecutar tareas automáticas, pg_dump para generar respaldos, pg_restore para recuperar información y Render para publicar la aplicación en la nube.
El objetivo es demostrar cómo estas herramientas pueden integrarse para implementar una estrategia de protección de datos sin depender de procesos manuales.
- Problemática
Uno de los problemas más comunes en la administración de bases de datos es realizar copias de seguridad de forma manual.
Cuando una persona es responsable de generar los respaldos, pueden presentarse diferentes inconvenientes:
- Olvidar realizar una copia de seguridad.
- Guardar respaldos desactualizados.
- Perder los archivos por almacenarlos en un solo equipo.
- No comprobar si los archivos pueden restaurarse.
- Exponer información sensible mediante archivos sin protección.
Estas situaciones pueden afectar la continuidad de una aplicación y dificultar la recuperación de sus datos.
Para reducir estos riesgos, se propone automatizar los respaldos mediante GitHub Actions y almacenar las copias en un espacio seguro y persistente.
Además, se considera necesario verificar periódicamente los archivos generados, ya que tener una copia de seguridad no garantiza que esta pueda utilizarse correctamente durante una recuperación.
- Herramientas utilizadas
Para desarrollar esta propuesta se consideran las siguientes tecnologías:
- Herramienta
- Función
- PostgreSQL
- Motor de base de datos relacional de código abierto.
- Neon
- Servicio administrado de PostgreSQL en la nube.
- FastAPI
- Framework de Python utilizado en la aplicación BackupManager.
- GitHub
- Repositorio público para almacenar el código fuente.
- GitHub Actions
- Automatización de los procesos de respaldo.
- pg_dump
- Generación de copias de seguridad de PostgreSQL.
- pg_restore
- Recuperación de datos desde respaldos en formatos compatibles.
- GPG
- Cifrado de archivos de respaldo.
- Render
- Despliegue público de la aplicación web.
Estas herramientas permiten construir una solución que integra desarrollo web, almacenamiento de datos, automatización y recuperación.
- Arquitectura de la solución
La arquitectura propuesta utiliza servicios que cumplen funciones diferentes, pero trabajan de manera conjunta.
El usuario accede a BackupManager mediante una dirección pública proporcionada por Render. La aplicación FastAPI se comunica con PostgreSQL alojado en Neon para consultar y administrar la información.
Por otro lado, GitHub Actions ejecuta un flujo de trabajo programado que establece una conexión segura con PostgreSQL y genera una copia de seguridad mediante pg_dump.
Posteriormente, el archivo se cifra y se envía a un almacenamiento externo persistente. Este último componente resulta importante porque los archivos temporales generados durante una ejecución de GitHub Actions no deben considerarse un repositorio permanente de respaldos.
El proceso general es el siguiente:
GitHub Actions inicia una ejecución programada.
Se establece la conexión con PostgreSQL en Neon.
pg_dump genera un respaldo de la base de datos.
Se verifica que el archivo se haya creado correctamente.
Se cifra el respaldo para proteger su contenido.
El archivo cifrado se almacena en un servicio externo.
Se registra el resultado de la ejecución.
Con esta arquitectura, la aplicación y el proceso de respaldo pueden funcionar de manera independiente.
- Automatización de respaldos con GitHub Actions
GitHub Actions es una herramienta de integración y automatización que permite ejecutar tareas a partir de eventos definidos en un repositorio.
En este proyecto se utiliza para programar respaldos periódicos de PostgreSQL sin necesidad de ejecutar manualmente los comandos.
5.1 Configuración de las credenciales
Para conectarse a PostgreSQL se necesita una cadena de conexión que contiene información sensible, como el usuario y la contraseña.
Esta información no debe escribirse directamente en el código fuente ni publicarse en el repositorio.
GitHub permite configurar secretos desde la sección:
Settings → Secrets and variables → Actions
Para este ejemplo se utiliza el secreto DATABASE_URL, que almacena la cadena de conexión de PostgreSQL proporcionada por Neon.
También se debe configurar BACKUP_PASSPHRASE, que será utilizada para cifrar los archivos de respaldo.
En una implementación real, ambos valores deben mantenerse protegidos y limitarse a los procesos que realmente los necesitan.
5.2 Creación del flujo de trabajo
Dentro del repositorio se crea el siguiente archivo:
.github/workflows/postgresql-backup.yml
El siguiente ejemplo genera un respaldo diario y lo cifra utilizando GPG:
name: PostgreSQL Backup
on:
workflow_dispatch:
schedule:
- cron: "0 3 * * *"
permissions:
contents: read
jobs:
backup:
runs-on: ubuntu-latest
steps: - name: Instalar cliente PostgreSQL run: | sudo apt-get update sudo apt-get install -y postgresql-client gnupg - name: Generar respaldo env: DATABASE_URL: ${{ secrets.DATABASE_URL }} run: | pg_dump "$DATABASE_URL" \ --format=custom \ --file=backup.dump test -s backup.dump - name: Cifrar respaldo env: BACKUP_PASSPHRASE: ${{ secrets.BACKUP_PASSPHRASE }} run: | gpg --batch --yes \ --pinentry-mode loopback \ --passphrase-fd 0 \ --symmetric \ --cipher-algo AES256 \ --output backup.dump.gpg \ backup.dump \ <<< "$BACKUP_PASSPHRASE" test -s backup.dump.gpg rm -f backup.dump Importante: este código demuestra la generación y el cifrado del respaldo. Para completar la estrategia de producción es necesario agregar un paso de subida a un almacenamiento persistente, como un bucket privado compatible con S3, y establecer una política de retención.
El horario configurado corresponde a las 03:00 UTC. Las ejecuciones programadas de GitHub Actions pueden presentar retrasos, por lo que no deben utilizarse como garantía de ejecución en un minuto exacto.
5.3 Verificación de la ejecución
Una vez configurado el archivo, GitHub Actions permite observar las ejecuciones desde la pestaña Actions del repositorio.
Allí se puede revisar si cada etapa terminó correctamente y detectar posibles errores de conexión, autenticación o generación del respaldo.
Esta supervisión facilita la identificación de fallas, aunque para un sistema de producción también sería recomendable configurar alertas automáticas cuando un respaldo no se complete.
- Recuperación de respaldos mediante pg_restore
Generar copias de seguridad es solamente una parte de la estrategia de protección de datos. La otra parte consiste en comprobar que la información pueda recuperarse.
PostgreSQL proporciona la herramienta pg_restore, que permite restaurar respaldos generados por pg_dump en formatos compatibles, incluido el formato personalizado utilizado en este proyecto.
6.1 Restauración del archivo
Si el respaldo se encuentra cifrado, primero se debe descifrar utilizando la contraseña correspondiente.
gpg --batch --yes \
--pinentry-mode loopback \
--decrypt \
--output backup.dump \
backup.dump.gpg
Una vez obtenido el archivo original, se puede ejecutar la restauración:
pg_restore \
--dbname="postgresql://usuario@servidor:5432/bd_prueba" \
--no-owner \
--no-acl \
backup.dump
La cadena de conexión mostrada es referencial. En una implementación real debe utilizarse una conexión válida y autenticada, evitando exponer las credenciales en comandos compartidos.
Es recomendable realizar las pruebas en una base de datos temporal o independiente para evitar sobrescribir información de producción.
6.2 Comprobación de la información
Después de restaurar el respaldo, se deben realizar consultas que permitan verificar la existencia de las tablas y los registros.
Por ejemplo:
SELECT COUNT(*) FROM usuarios;
Esta consulta permite comprobar cuántos registros contiene la tabla después de la restauración.
También se pueden comparar los nombres de las tablas, la estructura de la base de datos y una muestra de registros con la información original.
Una restauración se considera satisfactoria cuando los datos esperados están disponibles y la aplicación puede utilizarlos correctamente.
- Seguridad y cifrado de los respaldos
Los archivos de respaldo pueden contener información confidencial, por lo que su protección debe considerarse una parte fundamental del proceso.
Para este proyecto se plantea utilizar cifrado simétrico mediante GPG y AES-256.
Esto permite proteger el contenido de los archivos antes de almacenarlos fuera de la infraestructura principal.
Además del cifrado, es importante aplicar otras medidas de seguridad:
- Utilizar secretos de GitHub Actions para administrar las credenciales.
- Evitar publicar contraseñas o archivos de respaldo en repositorios públicos.
- Mantener los respaldos en almacenamiento privado.
- Restringir los permisos de acceso.
- Conservar la clave de recuperación en un lugar seguro.
- Establecer una política de retención y eliminación de archivos antiguos.
El cifrado protege la confidencialidad del respaldo, pero no reemplaza la necesidad de verificar su integridad y comprobar que pueda restaurarse.
- Despliegue de BackupManager en Render
Para que la aplicación esté disponible mediante Internet, se propone utilizar Render como plataforma de despliegue.
Render permite conectar un repositorio de GitHub y ejecutar una aplicación web desarrollada con Python.
En este caso, el servicio ejecutará BackupManager mediante FastAPI, mientras que PostgreSQL permanecerá alojado en Neon.
El proceso de despliegue contempla los siguientes pasos:
- Subir el código fuente de BackupManager a GitHub.
- Crear un nuevo servicio web en Render.
- Conectar el repositorio correspondiente.
- Configurar el entorno de ejecución de Python.
- Instalar las dependencias desde requirements.txt.
- Configurar la variable de entorno DATABASE_URL.
- Establecer el comando de inicio de FastAPI.
- Verificar el funcionamiento de la aplicación mediante su URL pública.
- Un comando de inicio habitual para FastAPI es:
- uvicorn main:app --host 0.0.0.0 --port $PORT
Este comando supone que la instancia de FastAPI se encuentra en el archivo main.py y se llama app. Si el proyecto tiene otra estructura, debe adaptarse.
Una ventaja de esta arquitectura es que el servicio web no necesita ejecutar directamente los respaldos. GitHub Actions se encarga de esa tarea y se conecta a PostgreSQL de forma independiente.
- Pruebas y validación del sistema
Para evaluar la estrategia se proponen cuatro pruebas principales.
- Prueba
- Objetivo
- Resultado esperado
- Generación
- Ejecutar pg_dump
- Crear un archivo válido y no vacío.
- Automatización
- Ejecutar el workflow
- Completar las etapas sin errores.
- Cifrado
- Proteger el respaldo
- Obtener un archivo cifrado recuperable.
- Restauración
- Ejecutar pg_restore
Recuperar las tablas y los registros esperados.
Los resultados reales deberán documentarse mediante capturas de pantalla de GitHub Actions, registros de ejecución y consultas realizadas después de la restauración.
También es recomendable registrar el tamaño de cada respaldo, su tiempo de generación y el tiempo requerido para recuperar la información.
Estas mediciones ayudan a evaluar la utilidad de la solución y permiten identificar oportunidades de mejora.
- Ventajas y limitaciones
La principal ventaja de esta propuesta es que utiliza herramientas de código abierto y servicios en la nube para construir una estrategia de respaldos sin depender de Microsoft SQL Server.
La automatización reduce las tareas manuales y permite mantener una programación constante de copias de seguridad.
Además, separar la aplicación, la base de datos y el almacenamiento de respaldos ayuda a reducir el riesgo de perder todos los componentes ante una misma falla.
Sin embargo, también existen limitaciones. Los respaldos realizados con pg_dump son copias lógicas y no sustituyen mecanismos de recuperación a un instante específico, como los basados en WAL. Asimismo, la disponibilidad de GitHub Actions, los límites de los proveedores y la conservación de las claves de cifrado deben considerarse al diseñar la solución.
Por ello, para aplicaciones con mayores exigencias de disponibilidad, se recomienda complementar esta estrategia con respaldos administrados, supervisión y pruebas periódicas de recuperación.
- Conclusiones
La automatización de copias de seguridad es una práctica importante para proteger la información almacenada en una base de datos.
Mediante PostgreSQL, GitHub Actions y las herramientas pg_dump y pg_restore, es posible implementar un proceso que permita generar respaldos programados y comprobar su recuperación.
El uso de Neon facilita la administración de PostgreSQL en la nube, mientras que Render permite publicar la aplicación sin mantener un servidor físico propio.
Por otra parte, incorporar cifrado y almacenamiento externo mejora la protección de los archivos generados.
Finalmente, este proyecto demuestra que una estrategia de respaldo no debe enfocarse únicamente en crear copias de seguridad. También debe garantizar que los archivos estén protegidos, disponibles y puedan utilizarse cuando sea necesario recuperar la información.
- Referencias
PostgreSQL Global Development Group. PostgreSQL Documentation: pg_dump. https://www.postgresql.org/docs/current/app-pgdump.html
PostgreSQL Global Development Group. PostgreSQL Documentation: pg_restore. https://www.postgresql.org/docs/current/app-pgrestore.html
GitHub Docs. Workflow syntax for GitHub Actions.
