Backup compression reduces storage costs and transfer time, but at the cost of CPU usage during backup creation — understanding this trade-off helps you choose appropriate compression settings for your specific situation.
The Core Trade-Off
Higher compression ratios (smaller files) generally require more CPU time and take longer to compress — the right balance depends on your specific priorities: minimizing storage cost, minimizing backup duration, or minimizing CPU impact on a server that's also handling production traffic.
Comparing Common Compression Options
| Tool | Compression Ratio | Speed | CPU Usage |
|---|---|---|---|
| gzip | Good, moderate | Fast | Moderate |
| bzip2 | Better than gzip | Slower | Higher |
| xz | Best compression | Slowest | Highest |
| zstd | Very good, tunable | Fast, especially at lower levels | Tunable, generally efficient |
Using gzip (Common Default)
tar -czvf backup.tar.gz /dataUsing zstd (Often the Best Modern Choice)
tar -cf - /data | zstd -o backup.tar.zstzstd offers a genuinely strong balance — compression ratios competitive with higher-CPU options at much better speed, with tunable compression levels letting you dial in your preferred trade-off point.
Tuning zstd's Compression Level
zstd -3 -o backup.tar.zst backup.tar # faster, less compression
zstd -19 -o backup.tar.zst backup.tar # slower, maximum compressionHigher numbers mean better compression at the cost of more time/CPU — test different levels against your actual data to find your preferred balance point.
When to Prioritize Speed Over Compression Ratio
- Backing up during active production hours where CPU contention with your application is a real concern
- Very large databases where backup duration itself affects your effective RPO
- Frequent (e.g. hourly) backups where cumulative CPU time across many backup runs adds up
When to Prioritize Compression Ratio Over Speed
- Storage cost is a significant, genuine concern (particularly relevant for long-term retention of many historical backups)
- Backups run during genuinely idle periods where CPU usage doesn't compete with anything else
- Bandwidth for transferring backups off-server is limited/costly, making smaller files valuable
Considering Multi-Threaded Compression
tar -cf - /data | pigz > backup.tar.gzpigz is a parallel implementation of gzip, utilizing multiple CPU cores — can significantly speed up compression on a multi-core VPS compared to standard single-threaded gzip, at the same compression ratio.
Testing Compression Options Against Your Actual Data
Compression effectiveness varies significantly based on data type (text compresses very well; already-compressed formats like JPEG/video barely compress further) — test with your actual backup data rather than assuming generic benchmarks apply directly to your specific situation.
Balancing with Your Actual RPO/RTO Needs
See Understanding RPO and RTO: Setting Realistic Recovery Objectives — if backup duration itself threatens your RPO target (backup takes so long that you can't run them frequently enough), prioritize speed even at the cost of larger, less-compressed backup files.
Common Errors
Backup CPU usage causing production performance issues — consider lower compression levels, multi-threaded compression to finish faster, or shifting backup timing to genuinely lower-traffic windows.
Continue Reading
- How to Set Up Automated VPS Backups
- How to Back Up a Large Database Without Locking It
- How to Diagnose and Fix High CPU Usage on a VPS
Browse more articles in Backup & Disaster Recovery.
