Suggestion: Add lrzip to Backup compression options

U

UrkoM

New Member
Oct 15, 2014
17
0
1
Hi,
I love using Proxmox VE, and it is a remarkable product.
I have a small suggestion, which could be easy to add: lrzip for Backup as a compression option.

In my use, lrzip compresses quite quickly, and achieves very impressive ratios. It seems to be particularly efficient for VM images.

Here are some links:
https://a3nm.net/blog/images_lrzip.html
http://blog.patshead.com/2010/01/achieving-better-compression-with-lrzip-and-rzip.html

I can script it myself, but I thought it would be worth suggesting.

Thanks!
 
Hi,
In many cases it beats gzip in compression ratio by far.
Just today I converted a gzip backup to lrzip, and it went from 100Gb to 29Gb.

I am going to convert an existing lzo backup to gzip and lrzip for comparison, and I will post the numbers here.
 
AFAIK it dependent very much on free Memory.
If you have more free Memory the better is the results.
 
I made some quick tests. VM image is a 8GB RAW on raid5, compressing to tmpfs (edit: I was wrong, my /tmp isn't tmpfs):

edit: machine is a 2*quad xeon E5620 / 32GB RAM with hyperthreading enabled


time lzop vm-911-disk-1.raw -o /tmp/lzo-default.lzo
real 0m20.990s
user 0m11.284s
sys 0m5.452s
Resulting size: 425M

time lzop -d /tmp/lzo-default.lzo -o /path/to/raid5/bla
real 0m49.460s
user 0m28.020s
sys 0m6.340s

time lzop --best vm-911-disk-1.raw -o /tmp/lzo-best.lzo
real 7m42.072s
user 7m37.036s
sys 0m4.856s
Resulting size: 356M

time lzop -d /tmp/lzo-best.lzo -o /path/to/raid5/bla
real 0m34.672s
user 0m24.472s
sys 0m5.568s

time lrzip vm-911-disk-1.raw -o /tmp/lrzip-default.lrzip
real 4m45.538s
user 23m46.060s
sys 1m32.544s
Resulting size: 154M

time lrzip -d /tmp/lrzip-default.lrzip -o /path/to/raid5/bla
real 1m28.949s
user 1m11.140s
sys 0m15.884s

time lrzip -L 9 vm-911-disk-1.raw -o /tmp/lrzip-best.lrzip
real 6m38.668s
user 36m36.904s
sys 2m28.660s
Resulting size: 156M

time lrzip -d /tmp/lrzip-best.lrzip -o /path/to/raid5/bla
real 1m36.579s
user 1m27.244s
sys 0m10.348s

edit/added (compressing only):
time lrzip -l vm-911-disk-1.raw -o /tmp/x/lrzip-default-lzo.lrzip
real 4m17.703s
user 2m13.568s
sys 0m39.320s
Resulting size: 297M

time lrzip -g vm-911-disk-1.raw -o /tmp/x/lrzip-default-gzip.lrzip
real 4m17.254s
user 3m56.316s
sys 0m44.488s
Resulting size: 207M

time lrzip -b vm-911-disk-1.raw -o /tmp/x/lrzip-default-bzip2.lrzip
real 4m10.694s
user 5m44.112s
sys 0m43.148s
Resulting size: 191M

edit/added (compressing only):
time pigz -c vm-911-disk-1.raw > /tmp/x/pigz-default.gz
real 0m18.418s
user 4m14.576s
sys 0m5.448s
Resulting size: 300M

time pigz -c --fast vm-911-disk-1.raw > /tmp/x/pigz-default-fast.gz
real 0m13.434s
user 2m50.048s
sys 0m5.984s
Resulting size: 351M

time pigz -c --best vm-911-disk-1.raw > /tmp/x/pigz-default-best.gz
real 0m33.993s
user 7m43.068s
sys 0m5.620s
Resulting size: 298M

edit/added (compressing only):
time pxz -c vm-911-disk-1.raw > /tmp/pxz-default.xz
real 3m14.094s
user 30m45.572s
sys 0m44.500s
Resulting size: 181M

time pxz -c -1 vm-911-disk-1.raw > /tmp/pxz-fast.xz
real 0m47.791s
user 7m39.364s
sys 0m21.896s
Resulting size: 218M

time pxz -c -9 vm-911-disk-1.raw > /tmp/pxz-best.xz
real 5m20.899s
user 28m49.716s
sys 1m2.384s
Resulting size: 161M

edit/added:
time pzstd -c vm-911-disk-1.raw > /tmp/pzstd-default.zst
real 0m19.516s
user 0m29.304s
sys 0m8.800s
Resulting size: 254M

time pzstd -d /tmp/pzstd-default.zst
real 0m29.036s
user 0m15.012s
sys 0m6.844s
 
Last edited:
Wow those are very complete numbers!
I'm still working on mine (chose a very bad example, a VM that uses whole-disk encryption, going back to the beginning now).

As I said, just a suggestion. Happy to do it on my own by scripting backups.
 
I vote for lrzip as a further option for backup jobs. More choices makes more flexible ;)
In my opinion gzip (pigz) for fast dumps with good compression and lrzip for slow(er) dumps with better compression, if size matters (ie for archiving purposes).
 
Could you please compare to pxz? The best compression is possible with pxz, yet it is also the slowest possible solution:

Code: 
root@backup /rpool/proxmox/1000/data > time pxz -9 -kc disk-drive-virtio0.raw | wc --bytes
759282532

real    5m27.595s
user    40m20.788s
sys     1m15.352s



root@backup /rpool/proxmox/1000/data > time lrzip -l disk-drive-virtio0.raw -o - | wc --bytes
disk-drive-virtio0.raw - Compression Ratio: 6310.050. Average Compression Speed: 32.637MB/s.
Total time: 00:04:10.81
1093068858

real    4m10.826s
user    2m39.256s
sys     0m47.524s

Normally, I don't care about compression, because I decompress and store my backups on a ZFS for easier differential backup and space usage.
 
+1 vote for xz. xz is important to anyone who needs to move images over a WAN connection. A long overnight backup window gives me plenty of time to let xz chew on the data for maximum compression.
 
vetman said:
+1 vote for xz. xz is important to anyone who needs to move images over a WAN connection. A long overnight backup window gives me plenty of time to let xz chew on the data for maximum compression.
Click to expand...
Hi,
In my experience, lrzip more often than not beats xz. If you look at the numbers above by ojaksch, lrzip made smaller files in less time.
This is not a surprise, lrzip uses LZMA like xz, with a pre-optimization of chunks to increase compression.

I'm going to run some numbers now with a Windows 10 qcow2 hard disk image.
 
Some initial results with a 128Mb file (the first 128Mb of the Windows 10 qcow2 file I have):
Code: 
-----------------------
lzop standard
43832314

real    0m0.442s
user    0m0.376s
sys     0m0.112s
-----------------------

-----------------------
lzop best
36883139

real    0m25.011s
user    0m24.948s
sys     0m0.116s
-----------------------

-----------------------
gzip standard
33542330

real    0m6.171s
user    0m6.156s
sys     0m0.168s
-----------------------

-----------------------
lrzip standard
16580786

real    0m15.242s
user    0m32.804s
sys     0m1.020s
-----------------------

-----------------------
xz standard, 4 threads
23785388

real    0m49.573s
user    0m49.480s
sys     0m0.132s
-----------------------
With these, my conclusion would be:
1- It makes no sense to use lzop best, use gzip standard instead.
2- It makes no sense to use xz standard, use lrzip standard instead.
 
More tests, 1Gb data:
Code: 
-----------------------
lzop standard
560125954

real    0m5.299s
user    0m4.648s
sys     0m1.136s
-----------------------

-----------------------
gzip standard
423726193

real    1m13.817s
user    1m13.588s
sys     0m2.164s
-----------------------

-----------------------
gzip -9
422101206

real    2m48.607s
user    2m48.272s
sys     0m2.272s
-----------------------

-----------------------
lrzip standard (LZMA -7)
293776799

real    3m2.417s
user    10m22.576s
sys     0m8.592s
-----------------------

-----------------------
lrzip -l (LZO compression)
485884955

real    0m34.964s
user    0m32.068s
sys     0m3.900s
-----------------------

-----------------------
lrzip -g (gzip compression)
369674816

real    0m48.239s
user    1m37.892s
sys     0m4.368s
-----------------------

-----------------------
lrzip -b (bzip2 compression)
362908591

real    1m18.342s
user    3m17.720s
sys     0m5.516s
-----------------------

-----------------------
lrzip -L9 (LZMA best)
291795577

real    3m36.120s
user    11m59.544s
sys     0m13.096s
-----------------------

-----------------------
lrzip -z (ZPAQ)
284666128

real    8m41.106s
user    29m52.844s
sys     0m7.956s
-----------------------

-----------------------
xz -T 4 (standard)
315502444

real    11m24.417s
user    11m22.500s
sys     0m1.620s
-----------------------

-----------------------
xz -9 -T 4
315502444

real    11m20.826s
user    11m20.132s
sys     0m1.164s
-----------------------

CPU: 4 cores, Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (1 Socket)
RAM 10Gb

Conclusions:
1- If you have the cores and RAM, lrzip standard is more interesting than gzip -9
2- lrzip is better than xz if all you care about is smallest possible file (archival)
3- The multi-threading of xz is not working. pxz or pixz might be better, but looking at the user time, they won't give you better results than lrzip, and the filesize will still be bigger.
4- lrzip, when using gzip or bzip2, offers a very interesting middle ground
5- lrzip -z (ZPAQ) keeps its promise of smallest size, but almost 3 times the effort!
 
Last edited:
I now concur that lrzip produces the smallest files. It did take twice as long with my 133GB Windows Server with data test file. 2hr30min for lrzip vs 1hr17min pxz. lrzip was 9% smaller. Now I want lrzip in Proxmox too! :)

Some other notes: The newest version of xz with built-in mutli-threading support is out but not widely available yet, so I used pxz. Yes, pxz had every core/thread at 100% most of the time. lrzip seemed like it was barely using more than 1 thread at 100%. It would be better to use lrzip while other vms are running since it didn't hog the entire machine. This was tested on a beefy Dual E5-2670 16c/32t 128GB Ram 10x Intel S3710 SSD Dell R620 on ZFS.

Code: 
# time lrzip -L 9 vzdump-qemu-100-2016_06_07-23_00_01.vma -o vzdump-qemu-100-2016_06_07-23_00_01.vma.lrzip
vzdump-qemu-100-2016_06_07-23_00_01.vma - Compression Ratio: 1.729. Average Compression Speed: 15.013MB/s.
Total time: 02:30:49.33

real    150m49.335s
user    1361m5.212s
sys    55m54.268s

# time pxz -z -9e -k vzdump-qemu-100-2016_06_07-23_00_01.vma

real    77m19.670s
user    1737m52.660s
sys    43m31.168s

-rwx------ 1 root root 142466170368 Jun  7 23:00 vzdump-qemu-100-2016_06_07-23_00_01.vma
-rw------- 1 root root  82391203567 Sep 28 22:20 vzdump-qemu-100-2016_06_07-23_00_01.vma.lrzip
-rwx------ 1 root root 115658643163 Sep 28 19:34 vzdump-qemu-100-2016_06_07-23_00_01.vma.lzo
-rwx------ 1 root root  89262429176 Jun  7 23:00 vzdump-qemu-100-2016_06_07-23_00_01.vma.xz
 
vetman said:
Yes, pxz had every core/thread at 100% most of the time. lrzip seemed like it was barely using more than 1 thread at 100%.
Click to expand...
AFAIK, lrzip defaults to nice 19, which would explain why pxz did it faster while having a larger "user" time.
 
+1

Zstd is now available in debian stretch and supports multithreaded compression. I'm already using it for personal disk backups with >300MB/s compression speeds on consumer hardware.
 
vzdump could be extended to include zstd als compress option and issue an error if zstd is not installed. Implementation is similar to 'pigz'.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back