Table des matières
Git revert, c'est magique. Mais pour ma base de données ?
J'ai fait une erreur dans mon code ? git revert. Je veux revenir à la version d'hier ? git checkout. Je veux tester un truc sans risque ? Je crée une branche.
Le code, c'est safe. Tout est versionné, tout est réversible.
Mais ma base de données ? C'est une autre histoire.
J'ai 4 applications en production. Chacune avec sa base PostgreSQL, ses données utilisateurs, ses heures de configuration.
Et à chaque fois que je lance une migration Prisma, je serre les fesses.
Le problème : une migration, c'est irréversible
Prisma fait le lien entre ton code et ta base : tu décris tes données dans un fichier, il génère le SQL qui va avec.
C'est pratique. Mais voilà le truc : quand tu lances prisma migrate, le SQL s'exécute directement sur ta base de données. Pas de "annuler". Pas de "revenir en arrière". C'est fait.
Imagine : tu rénoves ta maison. Tu abats un mur. Et là tu réalises que c'était un mur porteur. Trop tard.
C'est exactement ça, une migration qui se passe mal.
Mon cauchemar : les RPC de VetoWork
Sur VetoWork, une fonction SQL gère le filtre des annonces vétérinaires : type de poste, spécialité, rayon géographique, et des règles métier que seul un vétérinaire comprend. J'ai passé des heures dessus.
Quand je demande une migration à l'IA, elle peut juger que cette fonction ne sert à rien et l'écraser. C'est le revers de toute cette logique métier rangée dans la base plutôt que dans le code : personne ne la voit, donc personne ne la protège.
Je fais des sauvegardes manuelles de mes RPC, mais j'ai toujours cette angoisse : est-ce que j'ai bien tout sauvegardé ? Est-ce que je retrouverai la bonne version ?
Coolify backup : le backup invisible
J'utilise Coolify pour déployer mes applications. Et Coolify propose un système de backup vers S3. J'ai même écrit un article dessus.
Donc mes bases sont sauvegardées. En théorie.
Le problème ? Je ne vois rien.
- Pas de dashboard pour voir mes backups
- Pas d'alerte si un backup échoue silencieusement
- Pour restaurer, il faut : télécharger depuis S3, se connecter en SSH, lancer des commandes...
C'est comme avoir une assurance dont tu ne sais pas si elle est toujours active. Tu le découvres le jour où tu en as besoin. Et là, c'est trop tard.
Pgbackweb : le tableau de bord qui me rassure
Pgbackweb, c'est une interface web pour gérer tes backups PostgreSQL. Open-source, gratuit, et surtout : visible.
Ce que ça change concrètement
1. Un dashboard
Je vois mes backups. Je vois la date du dernier backup. Je vois si ça a marché ou pas. C'est bête, mais juste ça, ça change tout.
2. Des health checks automatiques
pgbackweb vérifie régulièrement que ta base de données est accessible et que ton stockage S3 fonctionne. Si quelque chose ne va pas, tu le sais AVANT d'en avoir besoin.
3. Des notifications
Tu peux configurer des webhooks pour recevoir une alerte Discord ou Slack si un backup échoue. Plus de backup qui casse silencieusement pendant 2 semaines.
4. Un restore en quelques clics
Pas de commandes SSH. Pas de téléchargement manuel depuis S3. Tu cliques, tu restaures.
Installation sur Coolify
Sur Coolify, c'est un service disponible en 1 clic. Mais il y a une subtilité qui m'a fait perdre du temps.
Étape 1 : Ajouter les variables d'environnement AVANT de démarrer
PBW_ADMIN_EMAIL=ton-email@exemple.com
PBW_ADMIN_PASSWORD=TonMotDePasseSecurise123!Étape 2 : Démarrer le service
Étape 3 : Créer le compte avec les MÊMES identifiants
Quand tu accèdes à l'interface pour la première fois, pgbackweb te demande de créer un compte. Tu dois entrer exactement les mêmes identifiants que ceux des variables d'environnement. Sinon, ça ne marchera pas.
C'est contre-intuitif : on s'attend à ce que les variables créent le compte automatiquement. En fait, elles définissent juste quels credentials seront valides.
Les limites (soyons honnêtes)
pgbackweb n'est pas parfait :
- L'image Docker est lourde, de l'ordre du giga une fois installée. Sur un petit serveur, ça compte.
- Pas d'API à ce jour : tout passe par l'interface, donc Claude Code ne peut pas aller consulter l'historique des backups tout seul. C'est demandé par plusieurs utilisateurs, ça finira sans doute par arriver.
- Quelques bugs S3 : Certains utilisateurs ont reporté des timeouts avec certains providers S3.
Pour qui c'est utile ?
- ✅ Applications en production avec de vraies données
- ✅ Bases de données que tu ne peux pas te permettre de perdre
- ❌ Side-projects sans enjeu
- ❌ Petits serveurs avec peu d'espace disque
C'est aussi une double sécurité : si le backup Coolify natif se passe mal, j'ai un filet. Mais honnêtement, ce n'est pas obligatoire, je le fais pour les apps vraiment sensibles.
Ma décision
Je l'ai installé sur les applications dont les données ont une valeur réelle : VetoWork, LiliMyBestie, ObsidianRAG. Pour les projets perso sans enjeu, le backup Coolify natif suffit largement.
Pour les apps avec de vraies données, de vraies heures de travail et de vraies conséquences si ça plante, je voulais voir mes sauvegardes, pas juste croire qu'elles existent.
Depuis, avant chaque migration Prisma, je vérifie la date du dernier backup sur le tableau de bord. Ça prend cinq secondes, et je lance la migration sans serrer les fesses. C'est tout ce que je demandais.
Besoin d’un coup de main pour cette partie technique ?
Je sais que parfois, même bien expliqué, un workflow reste intimidant.
Si tu préfères qu’on le mette en place ensemble, contacte-moi : je suis freelance en automatisation, et je peux t’aider à passer de “je devrais le faire” à “c’est déjà en place”.
Sinon, continue de piocher dans les ressources du site, elles sont faites pour ça ✌️
Commentaires