El proceso de copia de seguridad crea un archivo tar y luego le aplica gzip. Hay dos tipos de elementos en el archivo tar: un volcado de base de datos SQL ya comprimido con gzip y el contenido de las subidas (si se solicita). En mi caso, cada archivo de subida ya está comprimido: gz, gzip, gif, jpeg, png, zip. Por lo tanto, la compresión final con gzip solo aporta un 1% de tamaño.
Creo que sería mejor exigir menos espacio libre.
Un tema anterior de 2016 menciona la desactivación de la compresión de copias de seguridad, pero parece que en ese momento el volcado de SQL no estaba comprimido, lo que cambió los equilibrios.
Estoy tratando de ahorrar tiempo de CPU. De hecho, estaba pensando en usar el 0 como un indicador que cambiaría la ruta del código para que no comprima con gzip (lamentablemente, cero no es un nivel de compresión válido compatible en todas las versiones de gzip, hasta donde sé).
Eso no me ayudaría en absoluto. (Lo mismo ocurre con otros que han tenido el mismo problema de espacio limitado en el disco).
Si se estuviera utilizando tar, se podría usar con las opciones z o j. Si se estuviera utilizando un subshell, la salida de tar podría enviarse a través de una tubería a gzip. Pero creo que, de hecho, se están utilizando algunas funciones de Ruby de nivel superior.
Quizás no debería ser demasiado difícil… Aprecio que hacer cambios en la copia de seguridad y restauración deba hacerse con gran cuidado, pero creo que simplemente integrar la compresión ahorraría muchos requisitos de espacio sin ninguna cuestión de compatibilidad.
De tar --help
-a, --auto-compress use archive suffix to determine the compression
-z, --gzip, --gunzip, --ungzip filter the archive through gzip