Sauvegardes PostgreSQL open source en Go

# Développement d'un outil de sauvegarde open source pour PostgreSQL : de l'incident à la solution prête pour la production

Un développeur a créé une application web auto-hébergée pour les sauvegardes PostgreSQL, destinée aux spécialistes de niveau intermédiaire à senior. Le projet utilise pg_dump comme base, en ajoutant un planificateur, des intégrations de stockage et une surveillance de la disponibilité de la base de données. Pile technologique : Go (portée depuis Java), Gin, GORM, React + TypeScript, PostgreSQL, Docker Compose. Prend en charge les versions PostgreSQL 13–17.

Fonctionnalités clés :

• Sauvegardes planifiées (planificateur de type cron) avec stockage sur disque local, S3, Google Drive.
• Notifications d'échec vers Telegram, email, Slack après N tentatives (filtrage des faux positifs).
• Vérifications de santé avec graphiques de disponibilité de la BD.

Le projet gère les sauvegardes primaires pour les projets VPS et les sauvegardes secondaires pour les DBaaS cloud en tant que plan B.

Incident réel : Perte de données en production

En 2023, un projet personnel (~1 500 $/mois) a souffert d'une erreur humaine. En production, via psql, cette requête a été exécutée :

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

Cela a effacé ~10k enregistrements. La dernière sauvegarde datait d'un mois (utilitaire console comme PgBackRest). Récupéré 65 % avec des scripts basés sur l'ID ; remboursé le reste. Pertes : ~30 % des profits + temps d'arrêt.

L'incident a révélé des lacunes : absence de sauvegardes récentes, ignorance des SAVEPOINT/SELECT, et tests de récupération rares.

Architecture et développement

La première version en Java a pris un mois, puis a été migrée vers Go pour de meilleures performances. Wrapper UI autour de pg_dump avec :

• Compression des sauvegardes (compression personnalisée).
• Notifications de succès optionnelles.
• Point de terminaison API pour les vérifications de santé.

Utilisation actuelle :

• Sauvegarde primaire pour les petits projets VPS.
• Sauvegarde pour DBaaS cloud (duplicata en cas de panne/suppression).

Le projet est sous licence MIT, auto-hébergé, avec une interface web.

Plans de développement : Surveillance et alerte

La feuille de route se concentre sur la surveillance spécifique à PostgreSQL :

• Analyse de pg_stat_activity, pg_stat_sys, pg_locks avec visualisation UI (alternative à postgres_exporter + Grafana).
• Alerte sur les requêtes lentes (seuil >100ms sur INSERT).
• Statistiques sur le temps CPU et la fréquence d'exécution pour détecter les goulots d'étranglement.
• Stockage étendu (Yandex Disk, NFS, FTP) et notifications (Discord, Mattermost).

Sauvegardes incrémentales + streaming WAL avec PITR déjà implémentées (MAJ 2025).

Règles pour travailler avec les bases de données de production

Après l'incident, des pratiques strictes ont été introduites :

• Avant UPDATE : SELECT obligatoire avec LIMIT 1–2 pour validation.
• Pour les opérations en masse : SAVEPOINT manuel.
• Exercices de récupération trimestriels (cloud + sauvegardes locales).

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

Au cours des 2 dernières années, la récupération depuis PostgreSQL et les sauvegardes cloud s'est déroulée sans problèmes.

Points importants

• L'outil résout un vrai point de douleur : l'automatisation + notifications préviennent la perte de données dans ces rares cas de 0,01 %.
• L'implémentation en Go assure une faible surcharge pour les VPS.
• La surveillance de charge s'intègre avec les sauvegardes prêtes à l'emploi.
• Testez la récupération régulièrement — les sauvegardes sont inutiles sans vérification.
• Alternative open source aux sauvegardes DBaaS cloud comme couche tolérante aux pannes.

— Editorial Team