Trois logiciels libres sauvegardent un serveur, mais ils ne prennent pas les mêmes données. restic et Plakar rangent des fichiers dans un dépôt chiffré et dédupliqué, en ligne de commande et sans planificateur : restic écrit nativement vers S3, SFTP ou Backblaze B2, quand Plakar ajoute une interface web et des connecteurs de bases de données, à installer en paquets. Databasus ne sauvegarde que PostgreSQL, MySQL, MariaDB et MongoDB, depuis une interface qui planifie, applique la rétention et vérifie chaque sauvegarde en la restaurant.
Sauvegarde de fichiers ou sauvegarde de bases de données
restic et Plakar lisent des répertoires, les découpent en blocs et n'écrivent dans le dépôt que les blocs qu'il ne contient pas encore. Chaque passage produit un snapshot que l'on liste, compare ou monte en FUSE pour en extraire un seul fichier, sans tout restaurer. Plakar se présente pourtant comme l'étape suivante : son billet A Short history of backup range restic avec Borg, Duplicity, Tarsnap et Kopia, puis affirme que la plupart exigeaient une restauration complète pour montrer leur contenu, ce que restic ne demande pas.
Une base de données n'entre dans restic que par la sortie d'une commande comme pg_dump. Lancé avec --stdin-from-command, restic annule le snapshot si le dump échoue ; avec un simple tube vers restic backup --stdin, sa documentation prévient qu'un dump raté donne un snapshot vide. Plakar appelle lui-même pg_dump ou pg_basebackup par son connecteur PostgreSQL, à condition que ces outils clients soient installés sur la machine qui sauvegarde, et lit aussi MySQL, MongoDB, etcd ou Kubernetes. Fichiers et bases partagent alors le même dépôt.
Databasus prend le problème par l'autre bout : il ne sauvegarde ni fichiers ni répertoires. À partir de PostgreSQL 17, il enchaîne sauvegarde complète, incrémentales au niveau du bloc et flux WAL continu, par le protocole de réplication et sans rien installer sur le serveur de base, de quoi restaurer à la seconde près. MySQL, MariaDB, MongoDB et PostgreSQL avant la 17 passent par un dump complet à chaque sauvegarde. Le projet vise les équipes qui veulent une interface, des rôles par espace de travail et une mise en route sans expertise PostgreSQL, et sa page de comparaison avec pgBackRest renvoie vers ce dernier pour les sauvegardes physiques avant PostgreSQL 17, les différentielles ou la restauration delta.
Chiffrement, déduplication et destinations
restic, Plakar et Databasus chiffrent tous trois avant d'envoyer. restic chiffre tout ce qu'il écrit en AES-256 (mode CTR) et l'authentifie par Poly1305-AES, avec une clé dérivée du mot de passe par scrypt : son README part du principe que d'autres, administrateurs système compris, ont accès au stockage. Plakar chiffre données et métadonnées par défaut, et depuis sa v1.1.5 refuse d'ouvrir un dépôt non chiffré sans la variable PLAKAR_INSECURE_PLAINTEXT ; l'audit de sa cryptographie, publié en février 2025, n'a relevé aucun problème de sécurité majeur. Databasus chiffre chaque sauvegarde en AES-256-GCM avec une clé dérivée de son fichier secret.key. Chez restic, un mot de passe oublié rend les données irrécupérables ; chez Databasus, le README conseille de copier secret.key dès l'installation, pour pouvoir restaurer si le serveur de Databasus est perdu.
La déduplication sépare les deux familles. Dans un dépôt restic ou Plakar, un bloc déjà présent n'est pas réécrit, et plusieurs machines peuvent sauvegarder dans le même dépôt restic, où un bloc commun n'est stocké qu'une fois. Databasus ne documente aucune déduplication : chaque sauvegarde logique est un dump complet, compressé en zstd, et seules les incrémentales physiques de PostgreSQL 17 se limitent à ce qui a changé depuis la dernière sauvegarde complète.
restic écrit sans plugin vers un disque local, SFTP, S3 et compatibles, OpenStack Swift, Backblaze B2, Azure Blob Storage, Google Cloud Storage et rest-server, le serveur HTTP du projet, avec rclone pour le reste. Lancé en --append-only, rest-server refuse toute suppression : une machine compromise ne peut plus effacer ses anciennes sauvegardes. Plakar couvre S3, SFTP, Azure Blob Storage, Google Cloud Storage, un registre OCI et rclone, mais par des connecteurs absents de son binaire, qui ne livre que des connecteurs de base comme celui du système de fichiers. Ces connecteurs s'installent avec plakar pkg add, qui échoue sans compte Plakar, ou se compilent avec git, make et Go, et le paquet obtenu n'est pas signé. Databasus envoie vers un disque local, S3 et compatibles, Cloudflare R2, Google Drive, Azure Blob Storage, un NAS, FTP, SFTP et rclone.
Ce que chaque outil demande pour tourner
Relevé dans les dépôts et les documentations le 7 octobre 2026.
| Outil | Licence | À faire tourner | Ce qu'il sauvegarde | Planification | Dernière version |
|---|---|---|---|---|---|
| restic | BSD-2-Clause | un binaire Go, aucun serveur ; rest-server en option | fichiers ; bases par la sortie d'un dump | aucune : cron, timer systemd | 0.19.1, 5 juil. 2026 |
| Plakar | ISC | un binaire Go et son processus de cache ; connecteurs en paquets, avec un compte ou compilés | fichiers ; PostgreSQL, MySQL, MongoDB, etcd, Kubernetes par connecteurs | aucune depuis la 1.1 : cron, ou Plakar Control Plane | 1.1.7, 24 sept. 2026 |
| Databasus | Apache-2.0 | un conteneur Docker qui embarque son PostgreSQL 17 ; 1 cœur, 500 Mo de RAM et 5 Go de disque au minimum | PostgreSQL, MySQL, MariaDB, MongoDB ; aucun fichier | intégrée, de l'horaire au mensuel ou par expression cron | 3.60.0, 22 sept. 2026 |
Plakar publie une mesure de sa consommation : sur un million d'éléments, le CHANGELOG de sa v1.1.3 relève un pic d'environ 1,3 Gio de RAM en sauvegarde, 1,7 Gio en synchronisation et 800 Mio en restauration, avec un cache disque d'environ 1,8 Gio par défaut. La vérification des sauvegardes de Databasus passe par un agent, sur une machine qui a Docker et un accès HTTPS à l'instance, avec au moins 1 cœur et 512 Mo de RAM par vérification simultanée.
Planification, rétention et test de restauration : ce que chaque outil laisse à faire
restic et Plakar ne planifient rien d'eux-mêmes. La documentation de restic le dit : il s'exécute quand on l'appelle et n'est pas un démon. Cron, un timer systemd ou le Planificateur de tâches de Windows le déclenchent, et c'est au script d'empêcher deux exécutions simultanées. Plakar a retiré dans sa branche 1.1 le planificateur de la 1.0, que la pull request de suppression juge inutilisable en l'état, et renvoie lui aussi à cron ; la planification centralisée relève de Plakar Control Plane. Databasus planifie chaque base dans son interface et signale le résultat par e-mail, Slack, Telegram ou webhook.
La rétention, chez restic, se fait en deux temps : restic forget retire les snapshots selon des règles comme --keep-daily, --keep-weekly ou --keep-within, puis prune efface les données qu'ils étaient seuls à référencer. Pendant un prune, le dépôt est verrouillé et aucune sauvegarde n'aboutit : la documentation demande de le caler hors des créneaux de sauvegarde, puis de lancer restic check. Plakar range ses règles dans des politiques nommées, par exemple un snapshot par semaine sur trois mois, que plakar prune -policy applique ; sans l'option -apply, la commande liste ce qu'elle supprimerait sans rien effacer. Databasus règle la conservation par durée, par nombre ou en rotation GFS, qui garde séparément des sauvegardes horaires, quotidiennes, hebdomadaires, mensuelles et annuelles.
Databasus est le seul des trois à vérifier une sauvegarde en la restaurant. Son agent restaure la dernière sauvegarde dans un conteneur jetable de la même version majeure, après chaque sauvegarde ou selon un calendrier, et le rapport compare la taille restaurée à celle de la sauvegarde puis liste chaque table avec son nombre de lignes. restic et Plakar contrôlent le dépôt sans restaurer, et leurs commandes ne vérifient pas la même chose par défaut. restic check ne regarde que la structure du dépôt ; --read-data relit toutes les données, quitte à tout télécharger, et --read-data-subset n'en relit qu'une part à chaque passage, par groupe, pourcentage ou taille. plakar check, à l'inverse, valide d'emblée les MAC de toutes les données, et -fast se limite à la structure. Chez l'un comme chez l'autre, essayer une restauration revient à lancer un restore à la main ou par script.
Où en sont les projets
restic est le doyen : son dépôt date d'avril 2014 et n'a jamais publié de 1.0. La v0.19.0 est sortie le 9 juin 2026, quatorze mois après la 0.18.0, suivie de la v0.19.1 le 5 juillet, et depuis la 0.6.1, chaque binaire publié se reconstruit octet pour octet à partir des sources. Le dépôt de Plakar date de mars 2021, mais le projet n'est stable que depuis la v1.0.1 de mai 2025, et sa branche 1.1 change encore de comportement en version corrective : depuis le 18 septembre 2026, le serveur de Plakar rejette les connexions qui n'empruntent pas le flux d'authentification introduit en v1.1.6. Databasus, qui s'appelait Postgresus, a ouvert son dépôt en juin 2025 et publié 251 versions entre la v0.1.0 de juillet 2025 et la v3.60.0 du 22 septembre 2026 ; un développeur signe 955 des 1 047 commits. Sa v3.43.0 a retiré l'agent qui faisait les sauvegardes physiques depuis le serveur de base : qui garde de telles sauvegardes doit rester en 3.42.0 ou les supprimer avant de monter de version.
Licences et offres payantes
restic est sous BSD-2-Clause, Plakar sous ISC et Databasus sous Apache-2.0, trois licences permissives. Plakar réserve la planification centralisée, l'inventaire et l'interface complète à Plakar Control Plane, une appliance virtuelle à héberger soi-même, gratuite jusqu'à 500 Go de données gérées ; au-delà, le tarif se demande à l'équipe commerciale. Ses connecteurs précompilés sont gratuits mais demandent un compte, et ceux de VMware et de SQL Server, sans dépôt public, n'existent que sous cette forme. Databasus exclut l'open core : aucune fonction réservée, aucune version hébergée, et un sponsoring de 25 à 5 000 dollars par mois qui affiche le nom du sponsor sans rien débloquer.