Le processus de sauvegarde crée un fichier tar, puis lui applique gzip. Il y a deux types d’éléments dans le fichier tar : un dump SQL déjà compressé avec gzip et le contenu des téléchargements (si demandé). Dans mon cas, chaque fichier de téléchargement est déjà compressé : gz, gzip, gif, jpeg, png, zip. Donc, la compression finale avec gzip n’apporte qu’un gain de taille de 1 %.
Je pense qu’il serait préférable d’exiger moins d’espace libre.
Un sujet précédent de 2016 mentionne la désactivation de la compression des sauvegardes, mais il semble qu’à l’époque, le dump SQL n’était pas compressé, ce qui a modifié les compromis.
Le développement de cette fonctionnalité est actuellement en pause et elle ne figure pas sur notre feuille de route actuelle. J’espère que nous pourrons nous y consacrer en 2024.
Je cherche à économiser du temps CPU. En fait, je pensais utiliser le 0 comme un indicateur qui changerait le chemin du code afin qu’il ne compresse pas en gzip (malheureusement, zéro n’est pas un niveau de compression valide pris en charge par toutes les versions de gzip, à ma connaissance).
Hmm, cela ne m’aiderait pas du tout ! (De même que d’autres qui ont eu le même problème avec un espace disque limité.)
Si tar était utilisé, il pourrait être utilisé avec les options z ou j. Si un sous-shell était utilisé, la sortie de tar pourrait être redirigée vers gzip. Mais je pense qu’en fait, certaines fonctions ruby de plus haut niveau pourraient être utilisées.
Peut-être que cela ne devrait pas être trop difficile… J’apprécie que les modifications apportées à la sauvegarde et à la restauration doivent être effectuées avec le plus grand soin, mais je pense que l’intégration de la compression permettrait d’économiser beaucoup d’espace sans aucune question de compatibilité.
D’après tar --help
-a, --auto-compress utiliser le suffixe d’archive pour déterminer la compression
-z, --gzip, --gunzip, --ungzip filtrer l’archive via gzip