Journal Publication de uback 0.7(.1)

Posté par  . Licence CC By‑SA.
Étiquettes : aucune
18
28
fév.
2026

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…

I don’t want to live on this planet anymore

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  . Évalué à 2 (+0/-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'uback serait ses sources "prêtes à l'emploi", telles que celle pour MariaDB.

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.