Compressed backups
-
In addition, I have verified that if the option "Store backup as multiple data blocks instead of a whole VHD file" is enabled, the restore from the data blocks structure takes about 2-3 longer than from the .vhd if this option is disabled (I tested the health check restore).
-
(The idea behind is to have both a compressed delta backup (the backup repository itself is backed up to another location via vpn, so the size of the backup matters) and the fastest possible restore option.)
-
@abudef I just had a backup failure. This triggered a full (key) backup on the next run which transferred 165GiB. When I rdpd into the vm I could see that the vm contained 345GiB of data including the system drive. I conclude, therefore that compression is working for full key backups at a ration of around 2:1.
I hope this helps. -
@frank-s Do you have the "data block" option enabled for remote or not?
-
@abudef Yes, data blocks is enabled on the remote.
-
@frank-s This confirms my observations and tests that for compression to be active, data blocks must be enabled for remote.
-
@florent Can you please provide some summary on backup setup versus compression versus remotes configuration?
-
Hello @florent may I remind you to make this question clear, when and under what circumstances is compression used and when is it not? Thanks a lot.
-
@abudef
incremental backups on block storage are compressed with brotli in fastest mode. But this is enough to have a massive gain , since we compress all the zeroes.incremental backup ( *.vhd files ) on non block storage aren't compressed
Full backup (as in xva file ) aren't compressed by xo, but can be compressed by xcp ng ( using gzip or zstd )
for now, this is not configurable, we are waiting for the future remote form to handle this.
-
@florent Clear now, thanks!
-
O olivierlambert marked this topic as a question
-
O olivierlambert has marked this topic as solved
