O processo de backup cria um arquivo tar e, em seguida, aplica o gzip a ele. Existem dois tipos de coisas no arquivo tar: um dump SQL já compactado com gzip e o conteúdo dos uploads (se solicitado). No meu caso, cada arquivo de upload já está compactado: gz, gzip, gif, jpeg, png, zip. Portanto, a compactação final com gzip ganha apenas 1% de tamanho.
Acredito que seria melhor exigir menos espaço livre.
Um tópico anterior de 2016 menciona a desativação da compactação de backup, mas parece que o dump SQL não estava compactado naquele momento, o que alterou os compromissos.
Estou tentando economizar tempo de CPU. Na verdade, eu estava pensando em usar o 0 como um sinalizador que alteraria o caminho do código para que ele não usasse gzip (infelizmente, zero não é um nível de compressão válido suportado em todas as versões do gzip, até onde sei).
Hmm, isso não me ajudaria em nada! (Da mesma forma, outros que tiveram o mesmo problema com espaço em disco limitado.)
Se o tar estivesse sendo usado, ele poderia ser usado com as opções z ou j. Se um subshell estivesse sendo usado, a saída do tar poderia ser canalizada para o gzip. Mas eu acho que, na verdade, algumas funções de nível superior do Ruby podem estar em uso.
Talvez não deva ser muito difícil… Agradeço que fazer alterações no backup e restauração deva ser feito com muito cuidado, mas acho que apenas incorporar a compressão economizaria muito espaço sem nenhuma questão de compatibilidade.
Do tar --help
-a, --auto-compress use archive suffix to determine the compression
-z, --gzip, --gunzip, --ungzip filter the archive through gzip