Backup Size vs. Backup Copy Size

[BLC]

I have all of my backups going to a large JBOD, approximately 265TB in size. It is about 80% full.
I have a backup copy job set for each of my backup jobs to another JBOD, also 265TB in size.

The second JBOD is only utilizing a fraction of the space. Why are my backup copy jobs so small? Is something missing?
Thanks

[foggy]

Hi Bryan, do you have similar number of restore points on both arrays? Backup copy job doesn't just copy files from source top the target repository, it has its own chain and retention, so the size shouldn't be similar, depending on the job settings (copy interval, retention, GFS settings). Besides, it creates a single restore point per interval and doesn't copy everything that you have on source during the initial run - if it was set up recently, it might have not even reached the specified retention yet. Just look into the folders and see what you have on disks.

[F182]

OP. I have always wondered the same thing. For example, if I compare the total size of a FULL "backup" on my backup jobs, they are much bigger than the the "Backup Copy" job's full backup.

I was scratching my head there for a while. I even had to-do a lot of validation to make sure the "backup copy" job data was good and could fully restore. It all checked out fine.

Eventually, I reasoned it out to this. On my "backup" jobs I use "per-vm backup files" on the repository they go to. While on the "backup copy" jobs they are not. So I figure that the "backup copy" job is factoring in data de-duplication. I am only making a guess though.

[foggy]

That is the correct guess, with per-VM backup chains you do not have deduplication between VMs as you have if they are stored in a single backup file.

[BLC]

Yes, basically I have a 30 day retention and a backup copy per job sent to the secondary unit.

[foggy]

Anyway, that doesn't mean you should have similar space occupied on source and target due to the reasons outline above.

[Anguel]

@BLC: Do you have Veeam Agent backups?

[BLC]

I do.