Open-Source PostgreSQL-Backups mit Go

# Entwicklung eines Open-Source-Backup-Tools für PostgreSQL: Vom Vorfall zur produktionsreifen Lösung

Ein Entwickler hat eine selbst gehostete Web-App für PostgreSQL-Backups entwickelt, die sich an Spezialisten auf mittlerem bis senioren Niveau richtet. Das Projekt basiert auf pg_dump und ergänzt einen Scheduler, Speicherintegrationen sowie Überwachung der Datenbankverfügbarkeit. Tech-Stack: Go (aus Java portiert), Gin, GORM, React + TypeScript, PostgreSQL, Docker Compose. Unterstützt PostgreSQL-Versionen 13–17.

Wichtige Funktionen:

• Geplante Backups (cron-ähnlicher Scheduler) mit Speicherung auf lokaler Festplatte, S3, Google Drive.
• Fehlermeldungen an Telegram, E-Mail, Slack nach N Versuchen (Filterung falscher Alarme).
• Health-Checks mit Grafiken zur DB-Verfügbarkeit.

Das Projekt übernimmt Primärbackups für VPS-Projekte und Sekundärbackups für Cloud-DBaaS als Plan B.

Realer Vorfall: Datenverlust in der Produktion

2023 ereignete sich bei einem Nebenprojekt (~1500 $/Monat) ein menschliches Versagen. In der Produktion wurde über psql diese Abfrage ausgeführt:

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

Es wurden ~10.000 Datensätze gelöscht. Das letzte Backup war einen Monat alt (Konsolen-Tool wie PgBackRest). 65 % über ID-basierte Skripte wiederhergestellt; der Rest erstattet. Verluste: ~30 % des Gewinns + Ausfallzeit.

Der Vorfall deckte Lücken auf: keine frischen Backups, Ignorieren von SAVEPOINT/SELECT und seltene Wiederherstellungstests.

Architektur und Entwicklung

Die erste Version in Java dauerte einen Monat, dann Migration nach Go für bessere Performance. UI-Wrapper um pg_dump mit:

• Backup-Kompression (eigene Kompression).
• Optionalen Erfolgsmeldungen.
• API-Endpunkt für Health-Checks.

Aktuelle Nutzung:

• Primärbackup für kleinere VPS-Projekte.
• Backup für Cloud-DBaaS (Duplikat bei Ausfall/Löschung).

Das Projekt ist MIT-lizenziert, selbst gehostet und verfügt über eine Weboberfläche.

Entwicklungspläne: Monitoring und Alarme

Roadmap konzentriert sich auf PostgreSQL-spezifisches Monitoring:

• Analyse von pg_stat_activity, pg_stat_sys, pg_locks mit UI-Visualisierung (Alternative zu postgres_exporter + Grafana).
• Alarme bei langsamen Queries (Schwelle >100 ms bei INSERT).
• Statistiken zu CPU-Zeit und Ausführungshäufigkeit zur Engpass-Erkennung.
• Erweiterte Speicheroptionen (Yandex Disk, NFS, FTP) und Benachrichtigungen (Discord, Mattermost).

Inkrementelle Backups + WAL-Streaming mit PITR bereits implementiert (UPD 2025).

Regeln für den Umgang mit Produktionsdatenbanken

Nach dem Vorfall wurden strenge Praktiken eingeführt:

• Vor UPDATE: Pflicht zu SELECT mit LIMIT 1–2 zur Validierung.
• Bei Massenoperationen: Manuelles SAVEPOINT.
• Vierteljährliche Wiederherstellungsübungen (Cloud + lokale Backups).

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

Über 2 Jahre keine Probleme bei Wiederherstellungen aus Postgres- und Cloud-Backups.

Was wichtig ist

• Das Tool löst ein echtes Problem: Automatisierung + Benachrichtigungen verhindern Datenverlust in den seltenen 0,01 %-Fällen.
• Go-Implementierung sorgt für geringen Overhead auf VPS.
• Last-Monitoring ist out-of-the-box mit Backups integriert.
• Regelmäßige Wiederherstellungstests – Backups sind ohne Überprüfung nutzlos.
• Open-Source-Alternative zu Cloud-DBaaS-Backups als fehlertolerante Schicht.

— Editorial Team