Les comparatifs entre ces algorithmes existent déjà, je ne pense pas que ça en vaille la peine. Ici l’intérêt à mon avis c’était de voir l’impact de l’option auto (vs l’absence de compression ou une compression “bête et méchante” sans “auto”) sur des données a priori peu adaptées à la compression.
Une recherche de compromis au final.
YAKAFALLAITQUEJE, c’est fait.
J’ai fait un nouveau run avec zstd,3 sans l’option auto.
J’ai modifié mon commentaire plus haut pour tout regrouper ensemble.
Il n’y a pas de différences majeures, à part peut-être sur small vidéos. Cela m’étonne un peu. Ceci dit sur une grosse instance Peertube qui contient des milliers de fragments de vidéos, cela doit jouer assez fort.
La taille globale finale exagère légèrement les Mo gagnés car je suis parti de 0 Mo alors que dans les tests précédents, il y avait 30 ou 40 MO au départ. Les valeurs archive par archive sont, elles, homogènes.
En tout cas ce petit test m’aura permis de mieux comprendre Borg et de me donner bien plus de confiance dans la migration de mon système de backup à base de script yunohost backup create. Et j’attends avec impatience le gain d’espace disque ainsi que la durée de rétention plus importante que je pourrai gérer.
Edit : J’ai finalement fait un test sans compression (none). Et j’ai ajouté les valeurs de CPU mesurées par time (GNU).
Bonjour @CatsLover71.
Merci pour l’ajout de ces tests au dépôt. ![]()
Mise à jour des graphiques ( Ajout des tests none et zstd,3)
EDIT : J’ai également segmenté le graphique “6. Synthèse comparative” par application.
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.