How to replace gzip with pigz without breaking anything

Solution 1:

Yes, you can. pigz is nearly a a drop-in replacement for gzip. As always, you must test your restores, especially because you changed something.

"Replacement" can be a symlink earlier in $PATH. The previous gunzip is still available with the full path: /usr/bin/gzip.

ln -s /usr/bin/pigz /usr/local/bin/gzip
ln -s /usr/bin/unpigz /usr/local/bin/gunzip

Parallelism is not magic, there are limits. Note what the manual says about decompression being sequential and limited in the number of thread.

If zlib compatible output is not a requirement, consider evaluating other algorithms. Zstd for example, can be tuned to a very wide range of speed versus compression. Also can be built to support multiple threads.

Solution 2:

Better method: Tell your backup solution to use pigz instead.

Don't try to replace it this way. This might break other things that rely on gzip actually being gzip (unless the pigz developer actually has written it as a 100% full replacement with all options and behaviours intact). Also, after the next update of the package containing gzip, this will either replace it back to the OS version or break the update process.

Solution 3:

Don't do it that way - it's unlikely in the extreme that pigz is a 100% emulation of gzip in every respect - it's bound to do a few things different beyond it's stated intent of being faster by being parallel. If you do what you suggest, everything that uses gzip (and there's no good way to know what that all is) is going to break.