Je n'utilise pas rclone mais apparemment l'option --backup-dir avec sync permet de faire cela.
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).
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.
Oui, évidemment, c’était sous entendu "sans arrêter mariadb".
Par ailleurs, il y a un outil dédié : mariadb-backup pour faire des sauvegarde physiques complètes ou incrémentales.
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 Moonz . En réponse au journal Publication de uback 0.7(.1). Évalué à 7. 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 ?)