From reading around there is the possibility of running backup jobs in parallel, up to a specific number of jobs per proxy/per repo. Initially I thought of having all of our systems into one job and get over with it. I'm trying to figure out where that would help and how I can utilize that on my own setup. We've got around 15 VMs running on two ESXi 7 hosts. Connection to common FC storage is 1GbE. Half of our VMs are Windows (various versions, from XP to server 2019) and half are various Linux distros.
Any advice / documentation material that could help me spin some tests and check things out?
-
- Enthusiast
- Posts: 74
- Liked: 10 times
- Joined: Jan 23, 2021 10:14 am
- Full Name: Michael Pappas
- Contact:
-
- Enthusiast
- Posts: 45
- Liked: 21 times
- Joined: Nov 25, 2019 8:16 am
- Full Name: Daniel
- Contact:
Re: Criteria/advice for splitting a job/parallelizing jobs?
Our VM jobs reflect company policy. Meaning that for every RPO and Retention Period requirement from corporate, we have exactly one job. We use VMware Tags to assign the VMs to the jobs, and the vmware tags are applied to the VMs coming from our asset management system. Meaning that I, as a backup manager, don't even assign VMs to the jobs.
Anyway, we have one job for each RPO/Retention policy and add both, Windows and Linux VMs to the jobs.
There are some exceptions, because Windows Server failover clusters with CSVs need to be protected with agents. Meaning that you have to create a custom job for these. This is inconvenient with how Veeam internally works, because Veeam doesn't work policy-centric. Veeam has a more technical approach about backup management, unfortunately. But even with some exceptions we still only have three jobs for our RPOs 4h, 12h, 24h. And another two jobs for the WSFCs.
Each of these jobs has a Backup Copy job attached to it for secondary storage locations.
We protect roundabout 300 VMs. This approach works okay for us.
Anyway, we have one job for each RPO/Retention policy and add both, Windows and Linux VMs to the jobs.
There are some exceptions, because Windows Server failover clusters with CSVs need to be protected with agents. Meaning that you have to create a custom job for these. This is inconvenient with how Veeam internally works, because Veeam doesn't work policy-centric. Veeam has a more technical approach about backup management, unfortunately. But even with some exceptions we still only have three jobs for our RPOs 4h, 12h, 24h. And another two jobs for the WSFCs.
Each of these jobs has a Backup Copy job attached to it for secondary storage locations.
We protect roundabout 300 VMs. This approach works okay for us.
-
- Enthusiast
- Posts: 74
- Liked: 10 times
- Joined: Jan 23, 2021 10:14 am
- Full Name: Michael Pappas
- Contact:
Re: Criteria/advice for splitting a job/parallelizing jobs?
Thanks Daniel! I should have noted that with the exception of our 2 AD servers, the rest are of a less critical nature. In any case, I could tolerate a downtime of even 24-48h.
You've clearly addressed my concern here, so a single policy regarding RPO would effectively mean a single job for everything, thanks. I thought that perhaps I should create more jobs to force things to parallelize, but clearly this is not how you create a job.
(Strickly speaking, would one create jobs to cater for VMs that should be backed up with a much smaller frequency?)
You've clearly addressed my concern here, so a single policy regarding RPO would effectively mean a single job for everything, thanks. I thought that perhaps I should create more jobs to force things to parallelize, but clearly this is not how you create a job.
(Strickly speaking, would one create jobs to cater for VMs that should be backed up with a much smaller frequency?)
Who is online
Users browsing this forum: No registered users and 26 guests