Copias de seguridad de PostgreSQL de código abierto en Go

# Desarrollo de una herramienta de copia de seguridad de código abierto para PostgreSQL: De un incidente a una solución lista para producción

Un desarrollador creó una app web autoalbergada para copias de seguridad de PostgreSQL, dirigida a especialistas de nivel intermedio a senior. El proyecto usa pg_dump como base, agregando un programador, integraciones de almacenamiento y monitoreo de disponibilidad de la base de datos. Pila tecnológica: Go (portado desde Java), Gin, GORM, React + TypeScript, PostgreSQL, Docker Compose. Soporta versiones de PostgreSQL 13–17.

Características clave:

• Copias de seguridad programadas (programador tipo cron) con almacenamiento en disco local, S3, Google Drive.
• Notificaciones de fallos a Telegram, correo electrónico, Slack tras N intentos (filtro de falsos positivos).
• Comprobaciones de salud con gráficos de disponibilidad de la BD.

El proyecto maneja copias de seguridad primarias para proyectos en VPS y secundarias para DBaaS en la nube como plan B.

Incidente real: Pérdida de datos en producción

En 2023, un proyecto personal (~$1500/mes) sufrió un error humano. En producción, mediante psql, se ejecutó esta consulta:

UPDATE users SET email = '[email protected]' WHERE email ILIKE '%%';

Eliminó ~10k registros. La última copia de seguridad tenía un mes de antigüedad (utilidad de consola como PgBackRest). Se recuperó el 65% con scripts basados en ID; se reembolsó el resto. Pérdidas: ~30% de ganancias + tiempo de inactividad.

El incidente reveló deficiencias: sin copias frescas, ignorando SAVEPOINT/SELECT y pruebas de recuperación poco frecuentes.

Arquitectura y desarrollo

La primera versión en Java tomó un mes, luego se migró a Go por mejor rendimiento. Interfaz web alrededor de pg_dump con:

• Compresión de copias de seguridad (compresión personalizada).
• Notificaciones de éxito opcionales.
• Endpoint API para comprobaciones de salud.

Uso actual:

• Copia de seguridad primaria para proyectos pequeños en VPS.
• Copia de seguridad para DBaaS en la nube (duplicado en caso de caída/eliminación).

El proyecto tiene licencia MIT, es autoalbergado y cuenta con una interfaz web.

Planes de desarrollo: Monitoreo y alertas

La hoja de ruta se centra en monitoreo específico de PostgreSQL:

• Análisis de pg_stat_activity, pg_stat_sys, pg_locks con visualización en UI (alternativa a postgres_exporter + Grafana).
• Alertas en consultas lentas (umbral >100 ms en INSERT).
• Estadísticas de tiempo de CPU y frecuencia de ejecución para detectar cuellos de botella.
• Almacenamiento ampliado (Yandex Disk, NFS, FTP) y notificaciones (Discord, Mattermost).

Copias de seguridad incrementales + streaming de WAL con PITR ya implementadas (actualización 2025).

Reglas para trabajar con bases de datos en producción

Tras el incidente, se introdujeron prácticas estrictas:

• Antes de UPDATE: SELECT obligatorio con LIMIT 1–2 para validación.
• Para operaciones masivas: SAVEPOINT manual.
• Simulacros de recuperación trimestrales (nube + copias locales).

BEGIN;
SAVEPOINT sp1;
SELECT * FROM users WHERE email ILIKE '%old%' LIMIT 2;
-- ¿OK? UPDATE...
RELEASE SAVEPOINT sp1;
COMMIT;

En más de 2 años, las recuperaciones de Postgresus y copias en la nube han transcurrido sin problemas.

Lo importante

• La herramienta resuelve un problema real: la automatización + notificaciones previenen pérdidas de datos en esos raros casos del 0,01%.
• La implementación en Go asegura bajo sobrecoste para VPS.
• El monitoreo de carga se integra con las copias de seguridad de forma nativa.
• Prueba las recuperaciones regularmente: las copias son inútiles sin verificación.
• Alternativa de código abierto a las copias de seguridad de DBaaS en la nube como capa tolerante a fallos.

— Editorial Team