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