● Linux.fr 📅 24/05/2026 à 10:10

Open Source 👤 killian.larcher

🏷️ Tags : docker kubernetes python réseau rust

3 24mai2026 Portabase est un logiciel libre auto-hébergeable publié sous licence Apache 2.0, conçu pour automatiser la sauvegarde et la restauration de bases de données dans des scénarios de reprise après sinistre et de migration homogène (c’est-à-dire entre bases de données de même type). Son architecture distribuée le rend particulièrement adapté à des environnements décentralisés, où les bases de données ne sont pas accessibles sur un même réseau. Il permet de piloter les sauvegardes depuis une interface unique, tout en laissant l’exécution effective aux agents déployés au plus près des bases de données. Sommaire Un projet né d’un besoin opérationnel Une architecture distribuée : un serveur central et des agents Bases de données prises en charge Aperçu des fonctionnalités clés Sauvegardes planifiées, déclenchement manuel et rétention Restauration et migration homogène Stockage local ou distant Notifications lors d’évènements spécifiques Organisation et contrôle d’accès Installation et déploiement Feuille de route et fonctionnalités à venir Conclusion Un projet né d’un besoin opérationnel Portabase a été créé il y a environ deux ans et demi pour répondre à un besoin interne : remplacer des scripts utilisés pour sauvegarder des bases PostgreSQL par une solution centralisée et facilement maintenable, évitant d’avoir à déployer un script avec une cron sur chaque serveur. N'ayant pas trouvé de logiciels libres répondant à ce besoin, nous avons investi pour créer cette solution et faire un premier pas dans la contribution au monde du libre, après avoir été de simples utilisateurs pendant de nombreuses années. La construction d’une communauté autour du projet a réellement commencé depuis environ six mois, vers mi-décembre 2025, avec la publication d’une documentation plus détaillée, des articles sur Reddit et la création d’un serveur Discord. Quelques statistiques à mi-mai 2026 : environ 850 étoiles, 90 issues ouvertes et 5 contributeurs sur GitHub plus de 10 000 pulls sur Docker Hub environ 2 000 visites mensuelles sur la documentation. Une architecture distribuée : un serveur central et des agents Le serveur central fournit l’interface graphique et joue le rôle de control-plane : il permet de déclarer les agents, configurer les sauvegardes, lancer des restaurations et connecter des systèmes tiers (stockages, notifications). Il est construit avec Next.js en TypeScript. L’agent est déployé au plus près des bases de données : il exécute les tâches de sauvegarde et de restauration. Initialement écrit en Python, il a été réécrit en Rust afin d’obtenir un composant plus léger, plus prévisible et plus robuste à l’exécution. Les garanties apportées par le compilateur Rust contribuent à réduire drastiquement les bugs avant même la mise en production. Le choix architectural est important : le serveur central ne contacte jamais directement les agents. Il n’est donc pas nécessaire d’ouvrir des ports entrants vers les environnements où résident les bases de données. Ce sont les agents qui contactent périodiquement le serveur central. Cette approche réduit la surface d’exposition réseau et limite les conséquences d’une compromission du serveur central. Bases de données prises en charge Le projet a démarré avec PostgreSQL, puis s’est étendu rapidement à d’autres moteurs, d’abord dans l’écosystème SQL. Portabase prend aujourd’hui en charge neuf bases de données : PostgreSQL, MySQL, MariaDB, MongoDB, SQLite, Redis, Valkey, Firebird et Microsoft SQL Server. La prise en charge Microsoft SQL Server est plus récente, puisqu’elle date d’environ une semaine au moment de la rédaction, et doit donc encore être considérée comme en phase de test. Aperçu des fonctionnalités clés Sauvegardes planifiées, déclenchement manuel et rétention Portabase permet de planifier des sauvegardes selon des intervalles fixes ou à l’aide d’une syntaxe cron. Il reste également possible de déclencher une sauvegarde manuellement ce qui est utile avant une opération de maintenance, une mise à jour applicative, une migration ou toute intervention susceptible de modifier fortement l’état des données. La gestion de la rétention repose sur trois politiques configurables : count-based : conserve un nombre maximal de sauvegardes time-based : conserve les sauvegardes pendant une durée maximale GFS (Grandfather-Father-Son) : pour un plan plus élaboré, cf. ci-après. Le GFS permet une granularité avec des sauvegardes journalières, hebdomadaires et mensuelles. L’objectif est de couvrir aussi bien les petites installations auto-hébergées que les besoins d’équipes qui doivent formaliser un plan de conservation. Restauration et migration homogène Sauvegarder est nécessaire, mais ce n’est pas suffisant ! L’objectif principal reste de pouvoir restaurer les données le moment venu, en écrasant les données existantes par celles contenues dans la sauvegarde sélectionnée. Le cas de migration couvert est celui d’une migration homogène : même type de base de données, même version. Portabase permet ainsi de déplacer une base de données de manière contrôlée en passant par l’interface graphique, sans avoir à utiliser des commandes dans un terminal. Attention : Portabase n’est pas un convertisseur de bases de données. Il ne sert pas à transformer une base PostgreSQL en base MySQL, ni une base MongoDB en base MariaDB. Stockage local ou distant Portabase peut stocker les sauvegardes localement, sur l’instance qui héberge le serveur central, ou à distance via des stockages compatibles S3, par exemple AWS S3 ou Garage. Google Drive est également pris en charge. Une même sauvegarde peut être envoyée vers plusieurs destinations simultanément, ce qui permet de créer de la redondance. Notifications lors d’évènements spécifiques Le système de notifications couvre les canaux couramment utilisés par les équipes techniques : email, Slack, Discord, Telegram, Ntfy, Gotify et webhooks. Les alertes peuvent être déclenchées sur les succès comme sur les échecs de sauvegarde, avec des politiques personnalisables au niveau des bases de données. Organisation et contrôle d’accès Portabase intègre un système d’organisation par espace de travail. Toutes les ressources (agents, canaux de notification, stockage, etc) peuvent être attribuées à des organisations spécifiques, permettant de segmenter les accès. Cette fonctionnalité est principalement utilisée par des équipes qui gèrent plusieurs clients. Installation et déploiement L’installation peut se faire avec le CLI, Docker ou sur Kubernetes via Helm Chart. Les images Docker sont disponibles pour les architectures linux/amd64 et linux/arm64. Pour les personnes qui ne souhaitent pas utiliser la CLI, la documentation propose des configurations prêtes à l’emploi, aussi bien pour le serveur central que pour les agents, permettant de démarrer rapidement. Feuille de route et fonctionnalités à venir La feuille de route doit être mise à jour très prochainement. Les prochains développements porteront sur l’amélioration de l’expérience utilisateur, l’intégration dans des écosystèmes auto-hébergés comme Unraid, Proxmox VE Scripts, Dokploy et Coolify, ainsi que le renforcement des tests sur toutes les versions de bases de données prises en charge. Conclusion Portabase est né d’un besoin très concret : disposer d’un outil centralisé pour gérer les sauvegardes et restaurations de bases de données, sans maintenir une collection de scripts maison répartis sur chaque serveur. Le projet couvre déjà plusieurs besoins courants : politiques de rétention, notifications, stockage local ou distant, authentification OIDC/OAuth2, ainsi que des modes de déploiement adaptés à Docker et Kubernetes. Des retours d’usage, rapports de bugs et contributions sont donc les bienvenus pour continuer à durcir le projet et l’adapter aux cas réels rencontrés sur le terrain. N'hésitez pas à rejoindre le Discord ! Aller plus loin Site web de Portabase (10 clics) GitHub (6 clics) Documentation de Portabase (2 clics) Comparatif à des solutions de sauvegarde / restauration (3 clics)

🔗 Lire l'article original 👁️ 2 lectures