What app is this about, and its version: Borg 1.4.3~ynh1 What YunoHost version are you running: 12.1.39 (stable) What type of hardware are you using: Raspberry Pi 3, 4+
Describe your issue
Bonjour,
Ceci n’est pas une issue, mais une question.
Je m’apprête à adopter Borg pour mes backups.
Mes données sont principalement composées de vidéos (en volume) et je vois que dans les script backup_method, le borg create n’utilise pas le tag --compression auto, lz4 (lz4 est le type de compression par défaut, mais d’autres sont possibles).
Le tag auto dans --compression semble très important pour les fichiers incompressibles car sans cela, Borg perd énormément de temps à compresser des fichiers incompressibles (exemple : discuss: remove “auto” compression mode in borg2?).
Si je ne fais pas de mauvaise interprétation, il semble intéressant de modifier le borg create (ou bien d’ouvrir le choix dans l’admin, mais c’est pas mal de boulot).
Bonne question ! Par contre, je pense qu’il y a une petite confusion sur le rôle du mode auto (enfin si moi-même, j’ai bien compris ).
Le script borg_ynh n’utilise effectivement aucun flag --compression (source : backup_method), ce qui fait que Borg utilise lz4 par défaut (doc Borg).
Or le mode auto a été conçu pour protéger contre les “compresseurs coûteux” (lzma, zlib…) sur des données incompressibles. Comme l’explique le mainteneur de Borg dans l’issue #7054 que tu cites :
The “auto” compression mode was added to avoid that bad compressors cause a lot of cpu load when trying to compress incompressible data, like: borg create --compression auto,lzma,6
Concrètement auto fonctionne ainsi :
Il teste d’abord avec lz4 si le chunk est compressible (< 97% de la taille originale)
Si oui → il applique le compresseur coûteux spécifié
Si non → il stocke en lz4 ou sans compression
Du coup --compression auto,lz4 ne changerait rien : ça reviendrait à tester la compressibilité avec lz4… pour ensuite compresser avec lz4. C’est redondant.
Et comme lz4 est déjà ultra-rapide, l’overhead sur tes vidéos (incompressibles) reste négligeable, même sur un Raspberry Pi.
Si tu veux vraiment optimiser pour ton cas d’usage (beaucoup de vidéos sur RPi), deux pistes :
--compression none → supprime tout overhead de compression (gain marginal vs lz4 mais ça peut compter sur un RPi)
--compression auto,zstd,3 → bonne compression sur les fichiers compressibles (configs, BDD…) tout en évitant l’overhead sur les vidéos
Bref, le mieux reste encore de faire des tests ! (j’ai hâte de voir)
Bonne remarque ! J’ai creusé un peu le sujet et c’est effectivement vrai, mais avec une nuance importante.
Depuis zstd 1.5.1, les match finders de zstd augmentent leur pas de recherche tous les 256 octets traités sans trouver de correspondance (PR #3552). Concrètement, sur des données incompressibles, l’algorithme accélère progressivement et passe dessus beaucoup plus vite.
Mais c’est une optimisation de vitesse interne à l’algorithme : zstd tentera quand même la compression sur chaque chunk. Le mode auto de Borg, lui, agit en amont : il teste d’abord avec lz4 si le chunk est compressible (< 97 % de la taille originale), et sinon, il saute complètement le compresseur coûteux.
Du coup les deux mécanismes sont “complémentaires” :
auto → filtre les chunks incompressibles avant même d’appeler zstd
zstd → accélère en interne si malgré tout, il tombe sur des données incompressibles
Sur un Raspberry Pi avec beaucoup de vidéos, --compression auto,zstd,3 cumulerait donc les deux protections.
Ben, je veux bien essayer de tester ça, mais je n’ai que mon serveur de “prod” capable de recevoir les (un peu moins de) 300Go de vidéos plus tout le reste.
Alors des tests sur la prod, pourquoi pas, mais ça me fait un peu transpirer.
Je peux toutefois installer Borg sur cette machine, faire des tests et désinstaller (ou désactiver) en attendant d’être prêt complètement avec mon co-admin en site distant.
L’idée des tests serait de faire un backup initial de tout avec option de base (par défaut).
Désinstaller tout.
Refaire un test complet le lendemain avec --compression auto,zstd,3 (Question bête, il n’y a pas d’espace entre auto, zstd et 3 ?)
Si je désinstalle avec -–purge, il ne restera plus rien de Borg sur le serveur ?
Concernant la désinstallation : Attention, yunohost app remove borg --purge ne supprimera pas ton dépôt Borg (ni local, ni distant). J’ai vérifié le borg_ynh/scripts/remove at master · YunoHost-Apps/borg_ynh · GitHub : il ne gère pas YNH_APP_PURGE et se contente de supprimer les configs système (timer systemd, sudoers, hooks de backup, logrotate). Tes données de backup resteront intactes. C’est probablement un choix de sécurité du package.
Par contre, le répertoire d’installation de l’app et ses clés SSH seront bien supprimés à la désinstallation. Donc si tu désinstalles puis réinstalles, il faudra reconfigurer l’accès au dépôt distant.
Pour tes tests, puisque tu n’as que ta prod, une approche prudente :
Installe Borg normalement (config par défaut = lz4)
Lance un premier backup complet → note le temps et la taille du dépôt
Pour le second test avec --compression auto,zstd,3, il faudrait modifier le fichier /etc/yunohost/hooks.d/backup_method/05-borg_app (c’est le hook généré depuis conf/backup_method) pour ajouter le flag --compression auto,zstd,3 à la ligne borg create. Attention, ce fichier sera écrasé à chaque mise à jour de l’app.
Supprime le dépôt manuellement, puis relance un backup complet → compare
Ça évite le cycle install/désinstall et c’est moins risqué pour ta prod.
Ceci dit, tester en prod n’est jamais idéal, mais ici le risque est limité : le backup Borg est une opération en lecture seule sur tes données, le pire qui puisse arriver c’est un backup raté ou un peu de charge CPU/IO sur ton RPi.
Merci de la recherche.
J’en comprends que si l’on cherche une compression rapide mais significative, mais pas trop coûteuse en ressources CPU, auto+zstd est un très bon combo.
Pour gagner du temps, peut-être que réduire le nombre de vidéos sauvegardées est pertinent.
Si par exemple il y a 20Go de données “autres” + 20Go de vidéo (quasi-incompressibles) dans le test, ça me semble déjà très raisonnable pour un résultat significatif, sans traiter et copier 280Go de plus
Oui, je vais construire un environnement dans un CT PVE dont je dispose. Comme cela, j’aurai des données de test cohérentes et je ne risquerai pas de flinguer quoi que ce soit.
Vais faire un peu un mix backup apps Yunohost + Borg et backup Borg to court.
Pour les vidéos, j’essaierai de faire un dossier avec quelques grosses vidéos et un dossier avec plein de petites.
Par contre, il faut vraiment que je m’occupe d’un dossier administratif qui n’a que trop traîné parce que je trouve toujours plus intéressant à faire et en l’occurrence, ce test Borg est très intéressant. Je m’y colle dès que j’aurai mis ce tracas derrière moi.
Bon, j’ai préparé mon environnement et un jeu de données? Je vais m’atteler à l’aspect exécution, mais si vous avez des remarques ou souhaits d’autres types de données, allez-y.
Benchmark de Borg backup sur Yunohost
Environnement matériel et logiciel
HP Proliant Microserver Gen 8
Intel(R) Xeon(R) CPU E3-1265L V2 @ 2.50GHz-3.50GHz (4C/8T)
16Go RAM DDR3 1600 ECC
Proxmox VE 8.4.16
Tests réalisés dans un container PVE :
CT Debian 12 / Yunohost 12.1.39
4T / 8 Go affectés au CT
Volume données sur pool ZFS SSD Sata3
Volume accueillant sauvegardes Pool ZFS HDD Sata 3
Jeu de données
Pour utiliser le processus de backup Yunohost hooké Borg, toutes les données ont été placées dans un Yunohost dans le container.
Une sélection de vidéos ont été placées dans 2 applications webapp ;
webapp contient 20.1 GB de 1528 petites vidéos de moins de 60Mo (en fait des fragments de vidéos Peertube)
webapp__2 contient 20.4 GB de 7 vidéos de taille comprise entre 1.8GB et 7.2 GB
Une application Funkwhale de 13 Go principalement constitué de fichiers mp3.
Une application Calibre Web de 15 Go contenant principalement des ePub et PDF.
Une application Mobilizon qui traînait par là pour un autre test de 2.9Go
Un Peertube runner qui est exploité ici mais dont le service sera arrêté pour la durée des tests afin d’éviter qu’une vidéo 4k de 1h30 vienne exploser les tests.
Je compte utiliser time (version GNU) pour lancer les commandes. Je vais tâcher de time la partie yunohost backup create et modifier le hook pour time le borf create. Un Borg info à la fin de chaque itération.
Je procéderai application par application. d’abord avec les réglages de compression par défaut, puis je détruirai le repo et modifierai le borg create pour adopter la compression --compression auto,zstd,3
Voilà, vous tiens au courant et dites moi si vous voyez des trucs à changer.
Euh, le borg create ne suit pas les liens symboliques ?
Parce que n’ayant pas d’espace alloué sur le montage / de mon CT, j’ai mis les fichiers mp4 dans un répertoire /home/yunohost.app/my_webapp et créé un lien symbolique dans /var/www/my_webapp/ vers ce répertoire.
La sauvegarde a duré un quart de seconde et le contenu de la sauvegarde pour /var/ww/my_webapp est le lien symbolique, et pas les vidéos.
Salut,
Va falloir attendre encore un peu. Ce matin, mon PVE s’est dit “tient, il y a longtemps que je ne l’ai pas emmerdé celui-là”. Voilà, c’est fait. Et je dois dire que là, pour l’instant il est parti pour gagner la partie.
Je n’aime pas trop PVE (mais j’avoue mal maîtriser et ne pas avoir eu le goût de le faire).
Je n’aime pas trop tous ces systèmes qui mettent une surcouche de complexité sur des choses simples.
J’aime beaucoup Yunohost.
J’aime beaucoup les systèmes qui mettent une surcouche de simplicité sur des choses complexes.
Les fichiers vidéo (BIG-VIDEOS et SMALL-VIDEOS) ne se compressent quasiment pas, quelle que soit la méthode utilisée. C’est attendu : les formats vidéo (MP4, MKV, etc.) utilisent déjà une compression interne très efficace, et aucun algorithme général ne peut les réduire davantage.
À l’inverse, CALIBREWEB et MOBILIZON montrent un gain visible. La méthode auto,zstd,3 compresse systématiquement un peu mieux que lz4, mais l’écart reste modeste.
EDIT : CALIBREWEB, FUNKWHALE et MOBILIZON montrent un gain visible. zstd,3 compresse autant, voire légèrement mieux que auto,zstd,3, qui reste devant lz4. none sert de référence et confirme l’absence de réduction pour les données déjà compressées.
Ce graphique croise les deux dimensions principales : combien d’espace est économisé et combien de temps cela coûte. Le positionnement idéal est en haut à gauche (beaucoup de gain, peu de temps).
CALIBREWEB se distingue comme le jeu de données où la compression apporte le plus de valeur : un gain supérieur à 1 GB pour un temps raisonnable. FUNKWHALE suit, avec un gain proche de 1 GB.
Les fichiers vidéo (gros points en bas à droite) sont les pires : ils consomment le plus de temps tout en ne bénéficiant d’aucun gain de compression. C’est le cas d’usage typique où la compression est contre-productive.
EDIT : Les fichiers vidéo restent groupés en bas du graphique (gain quasi nul). Les points none (gris) montrent qu’en désactivant la compression, la durée diminue sans perte, confirmant que la compression est inutile pour ces données.
Encore merci d’avoir mis à disposition ce jeu de données ! Même si je ne suis pas certain que les graphiques servent à grand-chose, au moins, ça m’a fait passer une bonne soirée. Chacun ses vices ne me jugez pas.
PS les graphiques ont été réalisés à l’aide du langage R via RStudio.
Merci beaucoup pour ces tests, résultats et analyses
Et le gain de la compression est lui aussi très limité.
Pour Funkwhale comme Calibre, je parierais que c’est un “forfait” sur la partie logicielle, et que les données en elles-même (le volume qui varie d’une instance à l’autre) ne sont que peu impactées.
Conclusion personnelle : la différence de temps semble proche d’être négligeable, sauf en cas de forte contrainte en ressources systèmes (processeur peu performant, concurrence d’usages sur le serveur, chauffe, énergie…).
Il faudrait également avoir une métrique sur la durée de sauvegarde sans compression pour trancher: peut-être est-ce long uniquement parce que ce sont de gros fichiers à copier (= temps limité par le support de stockage).
Si le surcoût en temps est marginal, peut-être que ce gain de compression marginal (ou de simplicité à ne pas devoir trier → c’est aussi du temps) n’est pas problématique.
Si j’étais joueur, façon Yakafokon, je dirais qu’il serait intéressant d’avoir également un test avec zstd mais sans l’option auto (notamment en vidéo vs n’importe quel autre), pour voir s’il y a un coût important en temps “perdu” à peu compresser les données.
Facile à dire bien entendu
).
ne me jugez pas. 