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 Moonz . En réponse au journal Publication de uback 0.7(.1). Évalué à 7. 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.