Reduza as necessidades de espaço no disco local ao não compactar (redundantemente) backups com gzipping

Contribuir Funcionalidade
1

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.

Adicionar opção para desativar a compactação de backup

12 curtidas
Any way to disable gzipping backups?
Can I just tar the whole /var/discourse and run it on a new server?
Migrate from gz compression to zstd for backups
Backup requires 2x disk space - could the process be improved?
'Download remote images to local' disabled despite enough free disk space
2

Já estou trabalhando em um novo formato de backup que remove a compressão dupla. Minha esperança é que ele esteja pronto em um ou dois meses.

14 curtidas
3

Ótimo @gerhard!

2 curtidas
4

Alguma atualização sobre isso? Obrigado

1 curtida
5

Para não te incomodar muito, mas como está o andamento disso?

6

O desenvolvimento desse recurso está atualmente pausado e não está em nosso roteiro atual. Espero que possamos implementá-lo em 2024.

5 curtidas
Add option to disable backup compression
Backup requires 2x disk space - could the process be improved?
Migrate from gz compression to zstd for backups
7

Se eu escrevesse um patch para aceitar um 0 na taxa de compressão para desabilitar o gzip, vocês aceitariam?

1 curtida
8

(Acho que você economizaria tempo de CPU dessa forma, mas não espaço, porque o arquivo tar compactado com gzip ainda seria criado.)

9

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).

10

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.

1 curtida
11

tosse

3 curtidas
12

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

1 curtida
13

O -z realmente faz uma compressão in-loco? Sempre presumi que ele apenas executava o gzip após a conclusão do arquivo tar.

14

Imprudentemente, neste caso! Os bytes que representam o arquivo tar descompactado nunca chegam ao disco.

2 curtidas
15

Você está dizendo que podemos simplesmente adicionar
"--gzip",

E isso irá parar de exigir o dobro do espaço real usado pelos dados?

1 curtida
16

Sim, essa é a alteração no comando tar.

1 curtida
17

Parece que uma escolha ainda melhor é --zstd, mas aí também precisaríamos do pacote ‘zstd’ instalado na imagem do Docker.

2 curtidas
18

Possivelmente uma abordagem melhor, que poderia simplificar as coisas — a capacidade de lidar com backups existentes que podem ser *.gz ou *.zst — é usar a detecção automática do tar:

tar --auto-compress -c -f ../file.tar.gz .
tar --auto-compress -c -f ../file.tar.zst .

Mais importante para a descompactação, é claro, onde podemos não saber o que vamos encontrar.

Atualmente, o código Ruby parece fazer muitas coisas que o próprio tar já pode fazer. Esperamos que isso possa ser simplificado, em vez de se tornar mais complexo.

3 curtidas
19

zstd também é muito mais rápido, o que torna menos problemático o tempo que gastamos comprimindo o quase incompressível.

(Se o zstd também fosse usado para o dump SQL, no meu caso, o resultado seria 10% menor.)

2 curtidas
20

Olá, há alguma novidade sobre isso? Pelo que parece nesta resposta, já sabemos há mais de um ano que se trata de uma correção de uma única linha, então é bastante frustrante continuar acordando para mensagens diretas com backup failed, mesmo tendo quase 30G livres no servidor.

Eu mesmo faria o PR se a assinatura do CLA não exigisse que eu informasse um endereço físico.

3 curtidas