Compressed backups

[abudef]

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).

[abudef]

(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.)

[frank-s]

@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.

[abudef]

@frank-s Do you have the "data block" option enabled for remote or not?

[frank-s]

@abudef Yes, data blocks is enabled on the remote.

[abudef]

@frank-s This confirms my observations and tests that for compression to be active, data blocks must be enabled for remote.

[abudef]

@florent Can you please provide some summary on backup setup versus compression versus remotes configuration?

[abudef]

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.

[florent]

@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.

[abudef]

@florent Clear now, thanks!