Tout le long de ma carrière, le travail de "qui s’occupe des sauvegardes" (dans un contexte "on a nos données sur nos serveurs, pas dans les nuages") a (presque) toujours fini sur mon dos. Un des points les plus pénibles à mon goût, avec les crons.
Ma constatation :
- quand on part du point de vue "qu’est-ce que je veux sauvegarder", il y a des tas d’excellentes solutions. Vous utilisez ZFS ? Tapez "zfs backup" dans votre moteur de recherche favori, et vous trouverez forcément chaussure à vos pieds ; et le même constat peut être fait pour mariadb, postgres, btrfs,…
- quand on part du point de vue "où est-ce que je veux le backup", S3, FTP, webdav ? Pareil, il n’y a que l’embarras du choix.
Par contre, dès lors qu’on pose la question "je veux sauvegarder ça ici", la compatibilité entre les deux peut devenir plus épineuse. Ajoutez à ça des desiderata tels que "je veux que mes sauvegardes soient chiffrées", et il est possible de ne pas trouver de solution.
Et même si vous trouvez ? Félicitations, vous avez maintenant autant d’outils de sauvegarde que de couples "ce que je veux sauvegarder"/"où je veux le sauvegarder", chacun avec sa configuration séparée dans un format spécifique, avec ses clés de chiffrement différentes dans un format différent. Et le jour où vient votre exercice de plan de reprise d’activité annuel…
J’ai donc il y a maintenant 5 ans créé uback, un système pour faire l’intermédiaire entre "sources produisant des sauvegardes" (quelques unes fournies de base, mais l’idée est que vous pouvez écrire les votre en shell/dans votre langage de programmation favori) et "destinations qui peuvent accueillir ces sauvegardes" (idem), se chargeant du chiffrement, de la compression, et de la politique de rétention.
Je n’en ai jamais fait la promotion jusqu’ici, mais je profite de la 0.7(.1) pour le faire : je considère cette version comme "finale", complète en terme de fonctionnalités : la suite sera très probablement uniquement correction de bugs, maintenance courante. Pas dans le sens "j’en ai marre, j’abandonne le projet", dans le sens "ça fait largement ce que je lui demande, je ne vois rien à ajouter". Le seul point sur lequel je ne suis pas entièrement satisfait est le système de configuration, mais le problème est légitimement (et surprenamment !) complexe et je ne vois pas vraiment comment faire significativement mieux.
Pourquoi pas 1.0 si je considère la 0.7 comme "finale" ? Parce que je réserve "1.0" au cas (improbable, mais sait-on jamais) "le projet prend de l’ampleur, avec beaucoup d’utilisateurs et de contributeurs, et après de nombreux retours nous publions une 1.0 définitivement stable" (ou, autrement dit : quand ce n’est plus juste moi qui considère la version actuelle comme finale). En attendant, qu’est-ce que je me réserve le droit de casser en 0.x ? Tout sauf la capacité de restaurer d’anciennes sauvegardes. Est-ce qu’il y a des chances que je casse (volontairement) des choses ? Les chances sont faibles pour le système de configuration, quasi nulles pour le reste.
# rclone ?
Posté par dzecniv . Évalué à 7 (+5/-0).
Merci pour le partage. Quelques mots de comparaison avec rclone ? Qui permet de faire des sauvegardes (chiffrées) depuis et vers pas mal de services (local, (S)FTP, SSH, HTTP et de multiples services "cloud". À vue de nez le point fort d'
ubackserait ses sources "prêtes à l'emploi", telles que celle pour MariaDB.[^] # Re: rclone ?
Posté par Moonz . Évalué à 7 (+5/-0). Dernière modification le 01 mars 2026 à 11:56.
La réponse est simple : aucun rapport entre les deux, ce sont des outils complètement différents :)
Une copie n’est pas une sauvegarde — si un malware chiffre tes données 5 minutes avant que ton script rclone tourne, ça te fait une belle jambe 2 heures plus tard quand tu t’en rends compte que au moins si ton disque dur crash tes données "chiffrées" aient une copie ailleurs.
Un ensemble de copies datées est une sauvegarde. Mais il faut maintenant gérer "j’en garde combien, pour combien de temps", aka une politique de rétention. Ce que rclone ne fait pas. Et si tu gardes naïvement 30 copies (une copie journalière) de tes données de 100 Go, ça fait 30 To de sauvegardes, souvent avec énormément de redondance entre deux copies, donc tu te dis rapidement "j’aimerai que mes sauvegardes soient incrémentales, et ne prennent en espace disque supplémentaire que ce qui a changé". Là encore on sort du cahier des charges de rclone.
Et tu ne peux pas sauvegarder (physiquement) une base mariadb avec rclone.
rclone /var/lib/mysql /mnt/nfsbackups/mysql/$(date)n’est pas une opération valide. La seule solution est une sauvegarde logique (mariadb-dump), qui a l’inconvénient d’un temps de restauration assez long sur une grosse base (reconstruction des index notamment).La comparaison serait plus avec une solution telle que restic ou borg (qui pour le coup ont politique de rétention et sauvegardes incrémentales), et la réponse est simple : restic et borg sont spécialisés dans "sauvegardes d’une hiérarchie de fichiers générique", et sont probablement une meilleure solution si c’est la seule chose que tu veux faire, mais sont incapables également de sauvegarder (physiquement) une base mariadb, ou d’utiliser des snapshots ZFS/btrfs comme mécanisme de sauvegarde incrémentale, préférant la déduplication au moment du stockage.
[^] # Re: rclone ?
Posté par Voltairine . Évalué à 4 (+2/-0). Dernière modification le 01 mars 2026 à 13:01.
Je n'utilise pas rclone mais apparemment l'option
--backup-diravecsyncpermet de faire cela.En quoi n'est-ce pas valide ? Évidemment pour une sauvegarde physique des bases de données il convient d’arrêter au préalable le service.
Par ailleurs, il y a un outil dédié : mariadb-backup pour faire des sauvegarde physiques complètes ou incrémentales.
[^] # Re: rclone ?
Posté par Moonz . Évalué à 7 (+5/-0). Dernière modification le 01 mars 2026 à 13:19.
Oui, mais ensuite en cas de restauration sur un point précédent, tu dois avoir un système pour revenir au point précédent, que tu vas devoir faire toi même. Exactement comme "garder un ensemble de copies datées" vs "faire une copie", ou gérer la politique de rétention : rclone est certainement une brique te permettant de mettre en place un système de sauvegardes mais une bonne partie de ces tâches autour de la brique restent à ta charge. Et à ce moment, autant se diriger vers une solution de sauvegarde qui prend en charge tout ça.
Si tu en arrives à là, il vaut mieux un vrai système de sauvegarde. restic, borg (pour système de fichier générique) ou uback (pour sources hétérogènes).
Oui, évidemment, c’était sous entendu "sans arrêter mariadb".
Tout à fait, et c’est ce que uback utilise : https://github.com/sloonz/uback/blob/main/sources/mariabackup.go. Mais mariabackup ne gère pas la politique de rétention, pas le chiffrement, et ne fait qu’écrire soit sur stdout, soit sur le système de fichier (pas s3, pas ftp…).
C’est pile poile la problématique à laquelle uback répond : "j’ai mariadbackup qui peut produire des sauvegardes, mais n’a pas tout ces trucs autours que j’attends d’un système complet de sauvegardes" (et : je n’ai pas que mariadb, j’ai aussi des datasets zfs, une instance etcd, quelques instances valkey, des données sur un bon vieux système de fichiers ext4… comment je les fait partager une politique de rétention, des même clés de chiffrement, des même credentials sftp ?)
[^] # Re: rclone ?
Posté par Voltairine . Évalué à 3 (+1/-0).
Merci pour le complément d’informations et globalement pour cette publication sous licence libre.
J'ai regardé justement comment je pourrais utiliser ton outil de sauvegarde pour mariadb. Mais j'avoue que cela me dépasse complètement. Je ne comprends ni comment l'utiliser ni la logique de fonctionnement : cela parle de sauvegarde physique mais le script shell utilise maraidb-dump…, pourquoi lancer une nouvelle instance de mariadb dans un conteneur podman, etc.
Tant pis je resterai avec mes outils « maison » qui pour l'instant donnent satisfaction, en attendant d'avoir le temps de creuser ce que tu proposes pour y prendre éventuellement des idées.
[^] # Re: rclone ?
Posté par Moonz . Évalué à 5 (+3/-0). Dernière modification le 01 mars 2026 à 17:07.
Le script utilise mariadb-dump pour produire un .sql à partir d’une base physique. Il utilise podman pour lancer une instance de mariadb correspondant à la version qui a généré le backup physique (pour éviter de lancer un mariadb 10 installer sur une sauvegarde physique générée par mariadb 12).
Pour faire simple, quand tu demandes à uback de restaurer une sauvegarde mariadb, il te donne un dossier physique (l’équivalent de /var/lib/mysql) + ces deux scripts te permettant facilement d’obtenir un .sql à partir du dossier physique. Si ton but est juste de restaurer l’ensemble de la base, un simple
mv restored-data/ /var/lib/mysqlest suffisant (juste attention à l’owner évidemment) et tu peux ignorer ces scripts.C’est pour les collègues qui disent "j’aimerai bien l’état de la table T de la base B il y a un mois".
uback restore, puis le script./sqldump-podman.sh B T > b-t.sql.(et
uback restoreutilise par défaut podman pour utiliser la bonne version de mariadb-backup correspondant au mariadb-backup qui a généré le backup)[^] # Re: rclone ?
Posté par Voltairine . Évalué à 3 (+1/-0). Dernière modification le 02 mars 2026 à 06:59.
Merci encore pour les précisions. Je comprends mieux le fonctionnement mais c'est beaucoup trop complexe pour mon usage.
C'est le but des sauvegardes logiques avec un fichier SQL pour chaque base. De mon côté un simple script bash basé sur
mariadb-dumppour des sauvegardes très régulières avec rétention et rotation paramétrables est suffisant.Au passage, j'ai oublié de préciser que mariadb-backup (anciennement mariabackup) gère le chiffrement et les sauvegardes incrémentales (cf. un assez bon article d'IT-Connect là dessus)
[^] # Re: rclone ?
Posté par Moonz . Évalué à 3 (+1/-0). Dernière modification le 02 mars 2026 à 11:25.
L’article montre très bien que mariabackup ne gère pas le chiffrement et la compression par lui même (c’est pas une critique ; ce n’est pas son boulot) : l’auteur utilise deux outils externes (gzip & openssl) wrapppés dans un script shell pour se faire. uback se substitue à ces deux outils & le wrapper, pas à mariabackup.
Et oui, uback n’est pas capable de créer des sauvegardes incrémentales par lui-même, il se repose sur la source (comme ici mariabackup) pour le faire. Ce que j’entends par "gèrer les sauvegardes incrémentales", c’est la couche de gestion au dessus :
# Merci !
Posté par jyes . Évalué à 5 (+3/-0).
Cela fait un moment que je cherche en vain un outil pour sauvegarder mes snapshots BTRFS via SFTP pour les enregistrer comme de simples fichiers sur un système de fichier quelconque. Je vais peut-être enfin pouvoir me débarrasser de mes scripts peu robustes et passer à des sauvegardes plus régulières.
Ton outil comble un vrai manque et je te remercie de le diffuser et d’en avoir fait la pub ici. Je m’en vais de ce pas le tester !
# autre input
Posté par Nicolas Boulay (site web personnel) . Évalué à 3 (+0/-0).
est-ce que tu gères un S3 comme source ? En gros, j'ai un serveur S3 pour le web,et une sauvegarde "ailleurs".
Est-ce facile d'ajouter des scripts pour sauver du influxdb par exemple ?
"La première sécurité est la liberté"
[^] # Re: autre input
Posté par Moonz . Évalué à 2 (+0/-0).
Non. L’outil n’est qu’un wrapper autour de sources existantes (comme mariabackup) et à ma connaissance S3 n’a pas vraiment son mariabackup.
Si tu es un sysadmin qui fait ses scripts pour gérer ses backups, tu sauras créer une source oui. Par exemple : ré-implémentation de la source tar tar dans les tests unitaires (un poil plus compliquée que nécessaire : pour tar le type de snapshot devrait être bookmark, pas "configurable", j'ai rendu configurable de manière un peu artificielle pour les besoins des tests unitaires)
# borg ?
Posté par oau . Évalué à 3 (+2/-1).
Bonjour à toi,
je sais c'est chiant, tu as beaucoup bossé, tu as créé l'outil qui te convient et tu as la gentillesse de le partager.
Pour ma part j'utilise borgbackup depuis de très nombreuses années et j'en suis très heureux. Je backup des fs uniquement. Les db sont backupé dans un s3, les fs dans k8s sont copiés dans sur un serveur tampon et ensuite borg fait le taf. C'est chiffré, dé-dupliqué, relativement rapide, compressé et un outil existe pour vérifier la consistance. On sauvegarde comme ça environ 200To chaque jour.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.