Backup Copy Job - One giant one, or one for each Backup job?

[JoshuaPostSAMC]

I have 14 backup jobs covering 500 VMs and 76 TB of backup data. I'm doing an initial copy to a separate storage device that will be heading to a DR location as soon as data is seeded.

What do most people do in regards to the copy job? Create one job that includes all backup jobs so there is only one task to manage? I plan to keep the same retention period on all copy jobs, but if I have to do an active full of a set of VMs, I don't necessarily want to do every VM I'm backing up. So I can see it both ways.

Right now I'm leaning towards one copy job for each backup job, but open to comments

[Gostev]

Hello!

Multiple jobs give you more control, but also more things to manage. What do you like better?

From the product perspective, for 500 VMs you can certainly go with the single one (just make sure you have 9.5 U1 installed).

[DeadEyedJacks]

Hi,
We found that when performing synthetic operations, transforms, etc, the backup storage needs as much free space as the largest backup or backup copy job.
So with a single jobs of 500 VMs and 76TB you might well need 76TB+ of free space on the backup repository.

We started off with aggregating backup jobs into fewer backup copy jobs but have since reverted to a one-to-one relationship between backup jobs and copy jobs.
(Environment is 600+ VMs and 1PB source data.)

[JoshuaPostSAMC]

Thanks DeadEyeJacks.

I went ahead and set them up with a one-to-one so I could gradually turn them on and give the granular control Gostev mentioned.

[dellock6]

Hi,
We found that when performing synthetic operations, transforms, etc, the backup storage needs as much free space as the largest backup or backup copy job.
So with a single jobs of 500 VMs and 76TB you might well need 76TB+ of free space on the backup repository.

That's true however only if you don't use per-vm backup chains. With per-vm enabled, the number of VMs in a job doesn't matter in regards to the size of a backup file, as each VM is still stored in its dedicated file.

[CoffeeCup]

Hello,

We are running 70+ backup jobs every two hours form the VMWare Cluster. Each job includes two VMs (client based) so we are backing up this way more then 150 VMs. I’m currently adding Backup Copy job to implement GFS schema for each VM. What would be recommended way to setup Backup Copy job: use one job that aggregates all the VMs or split it in multiple (the backup/retention policy for each VM should be the same)? Would it be any difference from the performance/administration point of view? Running one job looks easier but would it be any drawback when, for example, adding new VMs to the job or restoring from the backup?

We are constantly adding more backup jobs and looks like our current backup schema is about too change so I’m looking for some kind of “Best Practice” recommendation of using Veeam in busy constantly growing environment.

Thank you very much

[foggy]

Hi Luba, seems you're perfectly getting all pros and cons of each approach. It's totally up to you to decide what fits your environment best or to find some middle ground. Some additional considerations are mentioned above.

[drb]

That's true however only if you don't use per-vm backup chains. With per-vm enabled, the number of VMs in a job doesn't matter in regards to the size of a backup file, as each VM is still stored in its dedicated file.

Thanks for that advice Luca.
The op’s question was about ‘backup copy job’.
Would your per-vm advice also apply to a ‘backup job’ as well?
So, just one backup job to capture all vm’s in the vsphere cluster and then let per-vm, set on the repository, do the donkey work of splitting up each vm into its own chain?
If I have an existing single backup chain on a repository, containing many vm’s, how would they behave if I now enabled per-vm on the repository?
Cheers.

[tpayton]

One thing to consider when deciding whether to enable Per-VM backup files is repository space usage.
https://helpcenter.veeam.com/docs/backu ... files.html

• If you enable the Use per-VM backup files option, data deduplication between VMs will not work. For more information, see Data Compression and Deduplication.

With regards to the question of enabling Per-VM with existing restore points:

Per-VM Backup Files Option for Existing Backup Repositories

You can enable or disable the Use per-VM backup files option for existing backup repositories at which backup jobs are already targeted. The new setting will not have any effect on previously created backup files on the backup repository. It will affect new backup files created after the setting is changed.

Veeam Backup & Replication applies the new setting starting from the next active full backup. You can create an active full backup manually or wait for Veeam Backup & Replication to automatically create active full backup (if active full backups are scheduled). Synthetic full backups do not affect the Use per-VM backup files setting.