BackupCopy Job - Big discrepacy between backup size and data size

[cxwsrei]

Hi all

I have big discrepancies on the backup copies of some VMs as following :

DATA BACKUP DEDUPLICATION COMPRESSION DATE RETENTION
SIZE SIZE
VM-A 50.0 GB 531 GB 1.0 x 1.0 x 10/21/2019 10:00:00 PM R
VM-B 350 GB 2.37 TB 1.0 x 1.0 x 10/21/2019 10:00:00 PM R
VM-C 45.0 GB 1.37 TB 1.0 x 1.0 x 10/21/2019 10:00:00 PM R

The target is an EMC Data Domain system.
The copies are performed using the EMC DD Boost protocol.

Data size of VM-B is 350 GB, backup size of the backup job is smaller (about 267 GB) -> the data above is taken from the properties of the BackupCopy job.
Backup is about 267 GB - but the BackupCoyp job reports a backup size of 2.37 TB !!??!!
Any ideaas what could be/is wrong ?

[Shestakov]

Hi
My guess is that you store regular backups as per-VM chains and backup copies combinedly.
Besides the BackupCoyp job report, do files on repository actually have that size?
Thanks

[cxwsrei]

In the backup job log the following can be found :
11/16/2019 6:01:48 PM :: Hard disk 1 (50.0 GB) 18.1 GB read at 99 MB/s [CBT]
11/16/2019 6:01:48 PM :: Hard disk 2 (300.0 GB) 248.7 GB read at 152 MB/s [CBT]

In the backup COPY job log the following can be found :
11/18/2019 10:04:15 PM :: Hard disk 1 (50.0 GB) 2.3 GB read at 20 MB/s
11/18/2019 10:16:41 PM :: Hard disk 2 (300.0 GB) 38.3 GB read at 8 MB/s

On the data domain the following file informations can be found :
sysadmin# filesys show compression /data/col1/DE_WE/BackupCopy_Weekly_01/VM-B.vm-291D2019-10-21T220000.vbk
Total files: 1; bytes/storage_used: 1274.6
Logical Bytes: 2,614,844,456,960
Original Bytes: 2,914,851,921,264
Globally Compressed: 3,479,570,975
Locally Compressed: 2,272,778,135
Meta-data: 14,029,352


sysadmin# filesys show compression /data/col1/DE_WE/BackupCopy_Weekly_01/VM-A.vm-85D2019-10-21T220000.vbk
Total files: 1; bytes/storage_used: 3735.0
Logical Bytes: 1,508,037,885,952
Original Bytes: 1,646,838,784,669
Globally Compressed: 673,796,135
Locally Compressed: 438,362,326
Meta-data: 2,557,700


It seems to compress properly - but the size informations "Logical bytes" and "Original bytes" are confusing !?
Appears rather to be a data domain issue than a veeam issue !?!

[foggy]

Yes, most likely Veeam B&R just shows what the storage has returned here - I'd check with the storage support team first.

[soncscy]

We hit this once with a client, and apparently the explanation is that DataDomain is "Append Only" -- if you're doing jobs that never produce Active/Synthetic Fulls and/or never do a compact full, the Full Backup file just appends data instead of overwriting, and the Datadomain never gets a chance to do a proper garbage collection on it.

Since its Backup Copy, I suppose your only option would be to change it to the other setting so it doesn't do the synthetic GFS points, but instead makes like Active Fulls in the chain. I don't recall if the Data Domain can do compacts or not, but that should fix it too.

[foggy]

Thanks, Harvey, you're right, totally forgot about the "append" nature of the forever forward incremental method merge operation. Indeed, if neither GFS nor compact is enabled, the full backup might grow in size with time on these systems. By default, compact is enabled though so this is a step aside from the best practices.