Backup file encryption and backup/transfer size

[J.S.]

Hi,

we noticed that after enabling the "backup file encryption" option on some of our backup jobs (the target is a Cloud Repository), the transfer size of the backups is arround 100% - 200% bigger then before. We are doing forever forward incrementals.

Without encryption, the stats for one of the jobs is,

Total size 4,1 TB Backup size 153,5 GB
Data read 193,5 GB Dedupe 1,2x
Transferred 70,2 GB Compression 1,0x

with encryption enabled,

Total size 4,6 TB Backup size 322,6 GB
Data read 275,5 GB Dedupe 1,2x
Transferred 256,6 GB Compression 0,8x

The backup job includes arround 55 Windows Server VMs. Is this the expected behaviour after enabling the encryption for a backup job?

According to other posts on the forum, the Veeam compression/deduplication should still be active, even with backup file encryption enabled?

veeam-backup-replication-f2/effect-of-b ... 39758.html
veeam-backup-replication-f2/deduplicati ... 10826.html

Thanks.

[foggy]

Hi James, indeed, Veeam B&R encryption is transparent to its inline dedupe and compression, since is done afterwards. My first guess, looking at the 'Total size' indicator (4,1 TB vs 4,6 TB), is that there's some new data appeared inside VMs between two job runs that is being captured and transferred.

[J.S.]

Hi foggy,

you are right, the stats for the job without encryption is already some weeks old. So there were some new vms added in the meantime.

Below the stats for the job (encrypted) for the past 4 days,

Total size 4.5 TB Backup size 215.6 GB
Data read 188.1 GB Dedupe 1.1x
Transferred 171.1 GB Compression 0.8x

Total size 4.5 TB Backup size 211.7 GB
Data read 186.1 GB Dedupe 1.1x
Transferred 167.9 GB Compression 0.8x

Total size 4.6 TB Backup size 322.6 GB
Data read 275.5 GB Dedupe 1.2x
Transferred 256.6 GB Compression 0.8x

Total size 4.5 TB Backup size 316.4 GB
Data read 288.5 GB Dedupe 1.7x
Transferred 251.7 GB Compression 0.8x

The ratio between Data read/Transferred is almost every time near 1:1. Old backup job, was close to 3:1.

The old backup job was synthetic full, the new backup job is forever forward incremental. But i dont think, that makes any difference? Since the data to backup was quite big, we created the first full backup (encrypted) to a local, external repository, shipped it to our Cloud Connect SP and mapped the new jobs to the imported data on our Cloud Repository. Could this be the problem? We didn't do that for the old job.

[J.S.]

Hi,

a case was opened ID03540692.

According to the support technician, after activating the option "Decompress backup data blocks before storing" on the repository, encrypted data is sent uncompressed. Thats why more data is transferred compared to the job without encryption.

Sounds strange to me. Can anyone confirm this?

Thanks

[foggy]

What type of repository is at the target site? In case it is CIFS with gateway server located on the source side and decompression is enabled, data will flow between gateway and storage uncompressed.