Best Practice for Offsite BC Job Repos

[Nick Stan]

We currently purchased a new Synology NAS to use as a repository for both our remote office backup infrastructure and to house our main site backup copies. Before sending it to the remote site I'm seeding the main site backup copy jobs to it. Before I get this seeding I'm starting to wonder what the best practice is for setting these backup copy jobs up. For example, should I include all 11 jobs (one job per VM on our main cluster) and use per-VM files for our backup copy jobs or should I just make an individual backup copy job for each of our 11 backup jobs to keep them all separated? Also when it comes to the repository itself should I create a separate LUN for the remote site backup jobs to keep them "separate" from my backup copy jobs, or does that come down to preference? I'm sure in any of these cases I can get it working but am curious as to how an experienced Veeam tech would set this up.

[foggy]

Hi Nick, considering the size of your environment, it mostly preference. A single backup copy is better from the management perspective so is more typical.

[Nick Stan]

Foggy, I think I like the idea of all VMs being on one backup copy job. Could this affect changes down the road, for example, adding or removing VMs to the job? We are rebuilding our clusters soon and will be adding and removing VMs from jobs, this job included. I've not worked with per-VM files on a repo before so am not sure if I should expect anything to act differently.

[nmdange]

I find it easier to have one backup copy job for each backup job (where the copy job is configured to use the backup job for the list of VMs to copy). You can then also configure the copy job interval to match the backup job's schedule.

[Nick Stan]

nmdange, any reason why you prefer that method? I've been the same, one job per VM, one backup copy job per VM to our cloud repo, but figured I'd look into why someone would do put all VMs in the same job instead of one job per VM. For myself it just keeps everything a little more organized in terms of backup chains and settings for each job.

[nmdange]

I have only a few backup jobs, with many VMs in each job. The reason to have multiple jobs is if they have settings that differ, like the number of restore points to keep. I definitely wouldn't recommend having one VM per backup job for no reason. If you have 11 VMs and 11 backup jobs, I would suggest consolidating your primary backups into as few jobs as possible, possibly even just 1 backup job.

I prefer one backup copy job per backup job since it helps ensure every VM that is backed up is copied to a remote location. When a new VM is created, you only have to add it to the primary backup job, and then the copy job will add it automatically. I also find the copy jobs work better when the copy interval start time coincides with the backup job start time.

[foggy]

Foggy, I think I like the idea of all VMs being on one backup copy job. Could this affect changes down the road, for example, adding or removing VMs to the job? We are rebuilding our clusters soon and will be adding and removing VMs from jobs, this job included.

During cluster rebuild, keep in mind that if VMs will be re-registered in VI, their IDs will change and they will be treated by Veeam B&R as new ones, which will trigger full job run for them. It is not specific to a single job scenario though.

[Nick Stan]

Foggy, is it possible to map the backups in that case, or re-map to the specific VM? We're going from a single-node environment to a two-node environment, just creating a cluster with the existing node but adding a second.

[foggy]

Mapping will not help, if you create a new cluster and re-register nodes/VMs there, you will need to re-add them into jobs and a full backup job run will be performed.