Open source backupy PostgreSQL w Go

# Opracowanie narzędzia open source do tworzenia kopii zapasowych PostgreSQL: od incydentu do gotowego do produkcji rozwiązania

Programista stworzył self-hosted aplikację webową do tworzenia kopii zapasowych PostgreSQL, skierowaną do specjalistów middle/senior. Projekt wykorzystuje pg_dump jako podstawę, dodając planista, integracje z magazynami i monitoring dostępności. Stack: Go (przepisany z Java), Gin, GORM, React + TypeScript, PostgreSQL, Docker Compose. Obsługuje wersje PostgreSQL 13–17.

Kluczowe funkcje:

• Planowane backupy (scheduler podobny do cron) z przechowywaniem na lokalnym dysku, S3, Google Drive.
• Powiadomienia o niepowodzeniach w Telegram, email, Slack po N próbach (filtr fałszywych alarmów).
• Health checks z wykresami dostępności bazy danych.

Projekt rozwiązuje zadania primary backupu dla projektów VPS oraz secondary dla chmurowych DBaaS jako plan B.

Rzeczywisty incydent: utrata danych w produkcji

W 2023 roku pet-projekt (~$1500/mies.) ucierpiał z powodu błędu ludzkiego. W produkcji przez psql wykonano zapytanie:

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

Zmazano ~10k rekordów. Ostatni backup — miesiąc wcześniej (konsolowa użyteczność typu PgBackRest). Odtworzono 65% skryptami po ID, reszcie zwrócono pieniądze. Straty ~30% zysków + przestój.

Incyident ujawnił luki: brak świeżych backupów, ignorowanie SAVEPOINT/SELECT, rzadkie testy odzyskiwania.

Architektura i rozwój

Pierwsza wersja na Java w miesiąc, potem migracja na Go dla wydajności. Interfejs użytkownika wokół pg_dump z:

• Kompresją backupów (custom compression).
• Opcjonalnymi powiadomieniami o sukcesie.
• API endpoint dla health checks.

Aktualne wykorzystanie:

• Primary backup dla small-scale projektów na VPS.
• Backup dla cloud DBaaS (duplikat na wypadek outage/usunięcia).

Projekt na licencji MIT, self-hosted, z interfejsem webowym.

Plany rozwoju: monitoring i alerty

Mapa drogowa skupia się na monitoringu specyficznym dla PostgreSQL:

• Analiza pg_stat_activity, pg_stat_sys, pg_locks z wizualizacją UI (alternatywa dla postgres_exporter + Grafana).
• Alerty na spowolnienie zapytań (próg >100ms na INSERT).
• Statystyki CPU time i częstotliwości wykonywania dla wykrywania bottlenecków.
• Rozszerzenie storage (Yandex Disk, NFS, FTP) i powiadomień (Discord, Mattermost).

Inkrementalne backupy + WAL streaming z PITR już zaimplementowane (UPD 2025).

Zasady pracy z bazą danych w produkcji

Po incydencie wprowadzono surowe praktyki:

• Przed UPDATE: obowiązkowy SELECT z LIMIT 1–2 do walidacji.
• Dla operacji bulk: ręczny SAVEPOINT.
• Ćwiczenia odzyskiwania co kwartał (chmura + lokalne backupy).

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

Przez 2 lata odzyskiwanie z Postgresus i chmurowych backupów przebiegało bez awarii.

Co ważne

• Narzędzie rozwiązuje realny ból: automatyzacja + powiadomienia zapobiegają utracie danych w 0,01% przypadków.
• Implementacja w Go zapewnia niski overhead dla VPS.
• Monitoring obciążenia integruje się z backupami out-of-box.
• Testujcie odzyskiwanie regularnie — backupy są bezużyteczne bez sprawdzenia.
• Open source alternatywa dla backupów cloud DBaaS jako warstwa fault-tolerant.

— Editorial Team