Open source PostgreSQL backups on Go

Development of an Open Source PostgreSQL Backup Tool: From Incident to Production-Ready Solution

A developer built a self-hosted web app for PostgreSQL backups, targeted at mid- to senior-level specialists. The project uses pg_dump as its foundation, adding a scheduler, storage integrations, and database availability monitoring. Tech stack: Go (ported from Java), Gin, GORM, React + TypeScript, PostgreSQL, Docker Compose. Supports PostgreSQL versions 13–17.

Key features:

• Scheduled backups (cron-like scheduler) with storage on local disk, S3, Google Drive.
• Failure notifications to Telegram, email, Slack after N attempts (false positive filtering).
• Health checks with DB availability graphs.

The project handles primary backups for VPS projects and secondary backups for cloud DBaaS as Plan B.

Real Incident: Data Loss in Production

In 2023, a pet project (~$1500/month) suffered from human error. In production, via psql, this query was executed:

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

It wiped out ~10k records. The last backup was a month old (console utility like PgBackRest). Recovered 65% with ID-based scripts; refunded the rest. Losses: ~30% of profit + downtime.

The incident exposed gaps: no fresh backups, ignoring SAVEPOINT/SELECT, and rare recovery tests.

Architecture and Development

First version in Java took a month, then migrated to Go for better performance. UI wrapper around pg_dump with:

• Backup compression (custom compression).
• Optional success notifications.
• API endpoint for health checks.

Current usage:

• Primary backup for small-scale VPS projects.
• Backup for cloud DBaaS (duplicate in case of outage/deletion).

Project is MIT-licensed, self-hosted, with a web interface.

Development Plans: Monitoring and Alerting

Roadmap focuses on PostgreSQL-specific monitoring:

• Analysis of pg_stat_activity, pg_stat_sys, pg_locks with UI visualization (alternative to postgres_exporter + Grafana).
• Alerting on slow queries (threshold >100ms on INSERT).
• Stats on CPU time and execution frequency for bottleneck detection.
• Expanded storage (Yandex Disk, NFS, FTP) and notifications (Discord, Mattermost).

Incremental backups + WAL streaming with PITR already implemented (UPD 2025).

Rules for Working with Production Databases

Post-incident, strict practices were introduced:

• Before UPDATE: mandatory SELECT with LIMIT 1–2 for validation.
• For bulk operations: manual SAVEPOINT.
• Quarterly recovery drills (cloud + local backups).

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

Over 2 years, recovery from Postgresus and cloud backups has gone without issues.

What's Important

• The tool solves a real pain point: automation + notifications prevent data loss in those rare 0.01% cases.
• Go implementation ensures low overhead for VPS.
• Load monitoring integrates with backups out-of-the-box.
• Test recovery regularly—backups are useless without verification.
• Open source alternative to cloud DBaaS backups as a fault-tolerant layer.

— Editorial Team