Riduci lo spazio su disco locale evitando di comprimere (in modo ridondante) i backup con gzip

Il processo di backup crea un file tar e poi vi applica gzip. Ci sono due tipi di elementi nel file tar: un dump SQL già compresso con gzip e il contenuto dei caricamenti (se richiesto). Nel mio caso, ogni file di caricamento è già compresso: gz, gzip, gif, jpeg, png, zip. Quindi la compressione finale con gzip aumenta solo dell’1% le dimensioni.

Credo che sarebbe meglio richiedere meno spazio libero.

Un argomento precedente del 2016 menziona la disabilitazione della compressione dei backup, ma sembra che all’epoca il dump SQL non fosse compresso, il che ha modificato i compromessi.

Aggiungi opzione per disabilitare la compressione dei backup

11 Mi Piace

Sto già lavorando a un nuovo formato di backup che rimuove la doppia compressione. Spero che sarà pronto entro uno o due mesi.

13 Mi Piace

Ottimo @gerhard!

2 Mi Piace

Ci sono aggiornamenti in merito? Grazie

1 Mi Piace

Per non disturbarti troppo, ma come sta procedendo?

Lo sviluppo di quella funzionalità è attualmente in pausa e non è nella nostra attuale roadmap. Spero che ci arriveremo nel 2024.

4 Mi Piace

Se scrivessi una patch per accettare uno 0 nel tasso di compressione per disabilitare gzip, sarebbe qualcosa che accettereste?

1 Mi Piace

(Sto ipotizzando che in questo modo si risparmierebbe tempo della CPU, ma non spazio, perché il file tar compresso verrebbe comunque creato.)

Sto cercando di risparmiare tempo di CPU. In realtà, stavo pensando di usare lo 0 come flag che cambierebbe il percorso del codice in modo che non comprima gzip (purtroppo, zero non è un livello di compressione valido supportato da tutte le versioni di gzip, per quanto ne so).

Questo non mi aiuterebbe affatto! (Lo stesso vale per altri che hanno avuto lo stesso problema con spazio su disco limitato.)

Se venisse utilizzato tar, potrebbe essere utilizzato con le opzioni z o j. Se venisse utilizzata una subshell, l’output di tar potrebbe essere inviato tramite pipe a gzip. Ma penso che in realtà vengano utilizzate alcune funzioni ruby di livello superiore.

1 Mi Piace

tosse

2 Mi Piace

Forse non dovrebbe essere troppo difficile… Apprezzo che le modifiche al backup e al ripristino debbano essere apportate con molta cura, ma penso che semplicemente incorporare la compressione risparmierebbe molti requisiti di spazio senza alcuna domanda di compatibilità.

Da tar --help

-a, --auto-compress usa il suffisso dell’archivio per determinare la compressione
-z, --gzip, --gunzip, --ungzip filtra l’archivio tramite gzip

1 Mi Piace

La compressione -z avviene effettivamente sul posto? Ho sempre pensato che eseguisse solo gzip dopo il completamento del file tar.

Saggiamente, in questo caso! I byte che rappresentano il file tar decompresso non toccano il disco.

2 Mi Piace

Stai dicendo che possiamo semplicemente aggiungere
"--gzip",

E smetterà di richiedere il doppio dello spazio effettivamente utilizzato dai dati?

1 Mi Piace

Sì, questa è la modifica al comando tar.

1 Mi Piace

Sembra che una scelta ancora migliore sia --zstd, ma in tal caso dovremmo anche avere il pacchetto ‘zstd’ installato nell’immagine Docker.

2 Mi Piace

Possibile approccio migliore che potrebbe semplificare le cose: gestire i backup esistenti che potrebbero essere *.gz o *.zst utilizzando il rilevamento automatico di tar:

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

Più importante ovviamente per l’estrazione, dove potremmo non sapere cosa ci troveremo di fronte.

Attualmente il codice Ruby sembra fare molte cose che tar può gestire da solo. Speriamo che questo possa essere semplificato, piuttosto che diventare più complesso.

2 Mi Piace

zstd è anche molto più veloce, il che rende meno problematico il tempo che impieghiamo a comprimere dati quasi non comprimibili.

(Se zstd venisse utilizzato anche per il dump SQL, nel mio caso questo risulterebbe del 10% più piccolo.)

1 Mi Piace