💾 Portabase : centraliser les sauvegardes de ses bases de données

📚 Introduction

La sauvegarde, c’est le sujet qu’on repousse. Un pg_dump dans un cron, un mysqldump qui pousse vers un bucket, un script Bash hérité d’un ancien projet et recopié depuis trois ans. Ça tourne. Enfin, on le suppose : personne n’a relu le log depuis des mois, et personne n’a jamais tenté de restaurer.

Le jour où il faut restaurer, les détails remontent tous en même temps. Le dump s’arrêtait à 2 Go, disque plein. La rotation gardait sept jours quand le client en attendait trente. Le fichier existe, mais il est tronqué au milieu d’un INSERT. Et comme les bases sont réparties sur cinq machines chez trois hébergeurs, chaque serveur a sa version du script et ses approximations à lui.

Portabase attaque le problème par le milieu : une interface unique qui pilote les sauvegardes de toutes vos bases, où qu’elles tournent, avec restauration depuis le navigateur. Licence Apache 2.0, auto-hébergement complet, projet porté par une organisation à but non lucratif. La version 1.30.1 date du 14 septembre 2026.

🔎 Pourquoi pas simplement un cron et un mysqldump ?

Parce qu’un cron ne vous dit rien de ce qu’il fait. MAILTO existe, et rien n’empêche un script d’appeler un webhook en cas d’échec. Encore faut-il l’écrire sur chaque machine, puis le maintenir. Ce qui manque n’a jamais été la possibilité technique d’alerter : c’est le suivi centralisé, une rotation plus fine que « supprime ce qui dépasse N jours », et une restauration praticable à 3 h du matin.

Portabase ajoute la couche qui manque au-dessus des outils de dump natifs, qu’il continue d’appeler en dessous. La planification se décrit en cron. La rétention se choisit parmi trois stratégies : garder les N dernières copies (de 1 à 100), garder tout ce qui a moins de N jours, ou une rotation GFS — grand-père, père, fils — qui conserve un représentant par période pour couvrir plusieurs années sans exploser le volume. Une même sauvegarde part vers toutes les destinations actives à la fois, et les échecs déclenchent des alertes.

Les trois stratégies de rétention, telles que le dashboard les propose. Capture issue de la documentation officielle.

Dix moteurs sont gérés, tous marqués stables : PostgreSQL 12 à 18, MySQL 5.7 à 9, MariaDB 10 et 11, MongoDB 4 à 8, SQLite 3.x, Redis 2.8+, Valkey 7.2+, Firebird 3.0 à 5.0, Microsoft SQL Server 2017, 2019 et 2022 ainsi qu’Azure SQL, plus les volumes Docker depuis l’Engine 20.10. La restauration couvre tout sauf Redis et Valkey.

🧱 Un dashboard, des agents, zéro port ouvert

Portabase se déploie en deux morceaux. Le dashboard est le plan de contrôle, une application Next.js installée une seule fois : on y déclare les agents, on y configure sauvegardes, stockages et intégrations, et il ne parle jamais à vos bases. L’agent est un binaire Rust posé sur chaque serveur hébergeant des bases. C’est lui qui exécute les dumps et les restaurations, et il chiffre les archives en AES-GCM avant que la moindre donnée quitte la machine.

Le sens de la communication fait tout l’intérêt. La documentation est explicite : « le serveur central ne contacte jamais les agents directement. Il n’y a donc pas besoin d’ouvrir de ports entrants dans les environnements où résident les bases de données. Ce sont les agents qui contactent périodiquement le serveur central. » Le sondage tourne toutes les cinq secondes par défaut.

Vos serveurs de bases n’exposent donc rien de neuf. Sur un parc éclaté entre un VPS, un homelab Proxmox et deux hébergeurs managés, ça change la conversation avec l’équipe réseau.

Une nuance s’impose au passage, parce qu’elle est facile à sur-interpréter. Ce que cette architecture supprime, c’est le chemin réseau entrant, pas le lien d’autorité : l’agent interroge le dashboard précisément pour y prendre ses ordres, restaurations comprises. Quelqu’un qui prend le contrôle du dashboard peut donc toujours faire déclencher des dumps ou des restaurations par vos agents. La documentation ne dit d’ailleurs pas autre chose : l’approche « limite les conséquences d’une compromission du serveur central ». Elle les limite, elle ne les annule pas. Le dashboard reste à traiter comme un actif sensible.

L’agent transporte son identité dans une Edge Key : une chaîne encodée contenant son identifiant, sa clé de chiffrement et l’URL du dashboard à joindre. C’est le seul élément à transporter d’un bout à l’autre de l’installation.

🚀 Installer le dashboard et un premier agent

Le CLI est la voie la plus courte : il génère le secret de chiffrement et démarre les conteneurs à votre place. Il lui faut Docker avec le plugin Compose, et il régénère le docker-compose.yml à chaque changement de configuration — vos ajustements maison vont dans un docker-compose.override.yml, pas dans le fichier généré.

curl -sL https://portabase.io/install | bash
portabase --version

Le binaire couvre Linux (amd64, arm64), macOS et Windows. On crée le dashboard, puis on le démarre :

portabase dashboard create mon-dashboard
portabase start mon-dashboard

L’assistant demande le port web (8887 par défaut), le mode de base et le fuseau horaire. L’interface répond sur http://localhost:8887.

L’accueil du dashboard, servi sur le port 8887. Les compteurs donnent l’état du parc d’un coup d’œil ; la barre latérale rassemble agents, stockages, notifications et gestion des accès.

Côté serveur de bases, l’agent se crée aussi simplement, l’Edge Key se récupérant sous Organisation > Settings > Agents :

portabase agent create mon-agent --key "<edge-key>" --tz "Europe/Paris" --start

Les autres options utiles sont --polling (fréquence de sondage, en secondes), --log-level parmi debug, info, warn et error, et --yes. Une fois l’agent en ligne, les bases qu’il détecte remontent toutes seules dans l’interface. Pour celles qu’il ne devine pas, un fichier monté sur /config/config.json les déclare en JSON ou en TOML.

Pour garder la main sur le Compose, l’image portabase/portabase:latest s’utilise directement :

docker run -d \
    --name portabase-app-prod \
    -p 8887:80 \
    --restart unless-stopped \
    -e TZ="Europe/Paris" \
    --env-file .env \
    -v ./portabase-data:/data \
    portabase/portabase:latest

La commande est reprise telle quelle de la documentation, latest compris ; en production, remplacez-le par le tag que vous avez vérifié (1.30.1 au moment où j’écris), pour la raison donnée plus bas. Trois variables comptent : PROJECT_URL, PROJECT_SECRET (un openssl rand -hex 32 fait l’affaire) et DATABASE_URL. La documentation réserve ce docker run aux essais, sa base embarquée n’étant pas prévue pour la production : la forme recommandée reste un Compose avec un PostgreSQL dédié. Kubernetes via Helm, Unraid, Dokploy et Coolify sont documentés aussi.

🗄️ Où atterrissent les archives

Le stockage local dépanne pour un premier essai, le temps de vérifier que la chaîne fonctionne. Au-delà, la sauvegarde partage le sort de la machine qu’elle protège. Portabase sait viser du S3-compatible (MinIO, AWS, Scaleway), Google Drive, Google Cloud Storage, Azure Blob Storage, SFTP, et tout backend atteignable par Rclone.

Plusieurs destinations restent actives en même temps sur une base, et la sauvegarde part vers toutes simultanément. De quoi tendre vers la règle 3-2-1, à condition de choisir des cibles vraiment indépendantes. Deux buckets du même fournisseur, sous le même compte, disparaissent ensemble le jour où ce compte est suspendu. Une copie chez l’hébergeur, une copie chez un tiers, des identifiants distincts : c’est le minimum qui tienne. Le stockage se configure comme un canal, au même titre que les connecteurs de notification qui vous préviennent d’un échec.

Les destinations se déclarent par base. Ici un bucket CloudFlare R2 actif, avec le stockage local du serveur disponible en second canal.

🤖 Un serveur MCP pour piloter le tout

Le dashboard expose ses opérations en Model Context Protocol : un assistant peut lister agents, bases et sauvegardes en langage naturel. Deux variables l’activent, API_ENABLED=true et MCP_ENABLED=true. L’endpoint /api/v1/mcp s’authentifie par un en-tête x-api-key :

{
	"mcpServers": {
		"portabase": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote",
				"https://your-dashboard.example.com/api/v1/mcp",
				"--header",
				"x-api-key: YOUR_API_TOKEN"
			]
		}
	}
}

Pratique pour interroger l’état d’un parc. Tenez-vous-en à la lecture le temps d’éprouver la chose : « restaure la base de prod » reste une phrase qu’on préfère taper soi-même.

⚠️ Quelques précautions

Le projet bouge vite. Trois versions sur les deux jours précédant le 1.30.1. La cadence est rassurante sur la vitalité du projet, et rend latest hasardeux sur une installation qu’on oublie : épinglez un tag et lisez les notes de version avant de monter.

L’Edge Key est un secret complet. Identifiant de l’agent, clé de chiffrement et URL du dashboard tiennent dans une seule chaîne. Qui l’obtient enrôle un agent chez vous. Un .env non versionné, et rien d’autre.

La restauration écrase les données en place. La documentation le dit sans détour. Deux modes existent — restaurer depuis une sauvegarde déjà connue du dashboard, ou depuis un fichier repris sur un stockage externe — et aucun des deux ne vous demandera si vous étiez bien sûr de la base cible.

Une sauvegarde non restaurée n’est pas une sauvegarde. L’interface supprime l’excuse principale. Programmez un test réel sur une base jetable, et chronométrez-le : ce chiffre-là est celui qui alimente vos objectifs de service, pas celui que vous espérez.

🎉 Conclusion

Sous le capot, Portabase appelle les mêmes pg_dump, mysqldump et mongodump que votre script. Tout le travail est dans la couche autour : centraliser, planifier, alerter, chiffrer, et rendre la restauration assez simple pour qu’on la teste vraiment.

Pour un freelance ou une petite équipe aux bases éparpillées, le rapport effort/tranquillité est difficile à battre : deux commandes pour le dashboard, une par serveur. Commencez par la base dont la perte coûterait le plus cher. Une fois celle-là couverte et restaurée pour de vrai, le reste suit.

🔗 Liens utiles

• Portabase — site officiel
• Documentation Portabase
• Portabase sur GitHub
• Installation par le CLI
• Serveur MCP Portabase
• Image Docker officielle