Compression Comparison

There is no "best" compression tool for every backup. Your choice is a trade-off between CPU/time (how long it takes to create and restore) and size (how much storage/bandwidth you save). This page gives a practical comparison for WordPress VPS operations.

Quick Summary

• Default for WordPress files: tar.zst (or tar.gz if you want maximum compatibility).
• Default for SQL dumps and logs: zstd or gzip.
• Use xz and high-compression 7z for cold storage (smallest, slowest).
• Use zip when recipients are on Windows/macOS and you need simple extraction.

Practical recommendations

Backup item	Good default	Notes
WordPress files (/var/www/...)	tar.zst	Great balance of speed and size
WordPress database dump (.sql)	zstd	Fast compression and fast restore
Logs (/var/log/...)	gzip or zstd	Often managed by logrotate; keep it simple
Cross-platform handoff	zip	Most portable format
Encrypted archive	7z (AES-256)	Also supports multi-part archives

Tool comparison (high level)

This table focuses on the most common tools you will see on a VPS.

Tool / format	Typical use	Compression ratio	CPU/time cost	Split support	Join support
tar	Directory archiving	none	low	yes (with split)	yes (with cat)
gzip (.gz)	Single-file compression	medium	low	no (use split)	yes (cat then gunzip)
zstd (.zst)	Single-file compression	medium-high	low-medium	yes (streamable)	yes (zstdcat)
xz (.xz)	Single-file compression	very high	high	no (use split)	yes (cat then xz -d)
tar.gz	Directory backup	medium	medium	yes (with split)	yes
tar.zst	Directory backup	high	medium	yes (with split)	yes
tar.xz	Directory backup	very high	very high	yes (with split)	yes
zip (.zip)	Cross-platform archive	medium	medium	yes (zip -s)	yes (zip -FF)
7z (.7z)	High compression + encryption	high-very high	high	yes (-v)	yes (auto-detect parts)

Split and join (quick reference)

Splitting is useful when you have upload limits, object storage part limits, or you want smaller chunks for transport.

Split a file into 5GiB parts:

split-archive-into-parts.sh

split -b 5G /backups/wp-files-2026-03-01.tar.zst /backups/wp-files-2026-03-01.tar.zst.part-

Join parts back into a single file:

join-split-parts.sh

cat /backups/wp-files-2026-03-01.tar.zst.part-* > /backups/wp-files-2026-03-01.tar.zst

warning

When joining with cat, make sure parts are in the correct order (lexicographic order for the default split suffixes). If you rename parts, sort them carefully before joining.

Notes for WordPress backups

• For faithful Linux restores (ownership/permissions), prefer tar-based archives.
• For operational backups, restore speed matters as much as archive size.
• High compression can hide bottlenecks: CPU-bound compression can be slower than the network.

More detailed view (categories)

Category	Best choices	Why
Best balance (fast + small)	zstd, tar.zst	Excellent speed/ratio
Smallest archives	xz, tar.xz, 7z -mx=9	Maximum ratio, slow
Most compatible	gzip, tar.gz, zip	Supported almost everywhere
Best for large DB dumps	zstd (higher levels if off-peak)	Great restore speed

Verification commands

Before you delete source data (or before you trust an offsite copy), run a quick integrity check.

Format	Quick integrity check
.tar	tar -tf archive.tar >/dev/null
.tar.gz	tar -tzf archive.tar.gz >/dev/null
.tar.zst	zstd --test archive.tar.zst (and tar -I zstd -tf archive.tar.zst >/dev/null)
.tar.xz	xz -t archive.tar.xz (and tar -tJf archive.tar.xz >/dev/null)
.gz	gzip -t file.gz
.zst	zstd --test file.zst
.xz	xz -t file.xz
.zip	unzip -t file.zip
.7z	7z t file.7z

Example checks:

verify-common-archive-formats.sh

tar -tzf /backups/wp-files-2026-03-01.tar.gz >/dev/null
gzip -t /backups/wp-db-2026-03-01.sql.gz
zstd --test /backups/wp-files-2026-03-01.tar.zst
unzip -t /backups/wp-handoff-2026-03-01.zip

Compression levels (rules of thumb)

Higher levels are smaller but cost more CPU. For operational backups, restore speed often matters more than squeezing the last 5-10%.

• gzip -1 to gzip -6: common defaults; use -1 for speed.
• zstd -1 to zstd -6: great defaults for daily backups; -10 to -15 for colder data.
• xz -6 to xz -9: use for cold storage only unless you enjoy waiting.
• 7z -mx=9: maximum compression, high CPU; best when encryption is also required.

Example: a WordPress backup layout that restores fast

Instead of putting everything into one giant archive, many operators keep two artifacts:

• wp-files-YYYY-MM-DD.tar.zst
• wp-db-YYYY-MM-DD.sql.zst

This makes verification and partial restores easier.

example-backup-layout.txt

/backups/
  wp-files-2026-03-01.tar.zst
  wp-db-2026-03-01.sql.zst

Performance tips

• Run heavy compression off-peak.
• Prefer zstd over xz for daily jobs.
• Consider lowering CPU priority for cron backups:

run-compression-with-lower-priority.sh

nice -n 10 ionice -c2 -n7 tar -I zstd -cvf /backups/wp-files-$(date +%F).tar.zst /var/www/html

Troubleshooting

Symptom	Likely cause	Fix
Archive is small but restore is very slow	Too-high compression level	Use zstd at a lower level for daily backups
Restore overwrote unexpected paths	Archive contains absolute paths	Use tar -C /path ... . patterns
Split parts do not join cleanly	Parts out of order or missing	Re-download and join in correct order
unzip restores with weird permissions	Zip portability trade-off	Use tar for Linux-native restores
Backup job spikes load and times out	CPU/disk bottleneck	Lower level, add nice/ionice, schedule off-peak

Cheat sheet

Task	Command
Best default for directories	tar -I zstd -cvf out.tar.zst dir/
Best default for SQL dumps	`mysqldump ...
Portability handoff	zip -r out.zip dir/
Smallest cold storage	tar -cJf out.tar.xz dir/
Split 5G chunks	split -b 5G file part-
Join chunks	cat part-* > file

Mini quiz

1. Why is tar usually preferred over zip for Linux server restores?

2. When would you choose xz over zstd?

3. What is the first command you run before trusting a backup archive?

4. What can go wrong if you extract an archive with absolute paths?