-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Mar 29, 2020 6:24 am
- Full Name: myRCvmforum
- Contact:
Alternative to job chaining
We have several backup jobs based on retention, target repository (local vs remote) that used to work based on job chaining when we were using VMware. Now that we've moved to Proxmox, job chaining is no longer supported. What's the best way to ensure that when running backup jobs, they don't run simultaneously causing a conflict (the disk is blocked by another backup job)?
-
- Product Manager
- Posts: 10968
- Liked: 3008 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Alternative to job chaining
Hi M.Y.,
May I ask why you need to use different backup jobs?
Typically, customers use a single backup job per virtual machine and utilize Backup Copy Jobs for different retention requirements.
This ensures that only one job processes your virtual machines.
Best regards,
Fabian
May I ask why you need to use different backup jobs?
Typically, customers use a single backup job per virtual machine and utilize Backup Copy Jobs for different retention requirements.
This ensures that only one job processes your virtual machines.
Best regards,
Fabian
Product Management Analyst @ Veeam Software
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Mar 29, 2020 6:24 am
- Full Name: myRCvmforum
- Contact:
Re: Alternative to job chaining
Not really sure as it was set up by our cloud backup provider. But if I were to guess, it's because of different retentions and different target repos.
Backup Job 1: VMs from data center 1 with 7 days retention destined for repo in data center 2
Copy Job 1: copy backup job 1 to cloud repo
Backup Job 2: VMs from data center 1 with 7 days retention destined for repo in data center 1
Backup Job 3: VMs from data center 1 with 14 days retention destined for repo in data center 2
Copy Job 2: copy backup job 3 to cloud repo
Backup Job 4: VMs from data center 1 with 14 days retention destined for repo in data center 1
The above used to work because each Backup Job was set to run after the previous one was completed.
After moving to Proxmox, without job chaining, if Backup Job 1 took a long time (e.g. full backup) to complete, Backup Job 2 will start running and fail (disk is blocked by another backup job).
Backup Job 1: VMs from data center 1 with 7 days retention destined for repo in data center 2
Copy Job 1: copy backup job 1 to cloud repo
Backup Job 2: VMs from data center 1 with 7 days retention destined for repo in data center 1
Backup Job 3: VMs from data center 1 with 14 days retention destined for repo in data center 2
Copy Job 2: copy backup job 3 to cloud repo
Backup Job 4: VMs from data center 1 with 14 days retention destined for repo in data center 1
The above used to work because each Backup Job was set to run after the previous one was completed.
After moving to Proxmox, without job chaining, if Backup Job 1 took a long time (e.g. full backup) to complete, Backup Job 2 will start running and fail (disk is blocked by another backup job).
-
- Product Manager
- Posts: 10968
- Liked: 3008 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: Alternative to job chaining
Hi myRCvmforum,
I recommend using a single backup job and selecting a primary repository located in the same datacenter.
Backup job performance can be significantly affected if backups are written over a slow or unreliable network to another datacenter. Storing backups in a repository within the same location and with optimal network connectivity will allow the backup job to complete much faster.
To clarify, do Backup Job 1 and Backup Job 2 protect different sets of VMs?
If so, I would suggest the following configuration:
Example configuration:
Fabian
I recommend using a single backup job and selecting a primary repository located in the same datacenter.
Backup job performance can be significantly affected if backups are written over a slow or unreliable network to another datacenter. Storing backups in a repository within the same location and with optimal network connectivity will allow the backup job to complete much faster.
To clarify, do Backup Job 1 and Backup Job 2 protect different sets of VMs?
If so, I would suggest the following configuration:
Example configuration:
- Backup Job 1: VMs from datacenter 1, target repository in datacenter 1, retention 7 days
- Backup Copy Job 1: Copy of Backup Job 1, target repository in datacenter 2, retention 7 days
- Backup Copy Job 2: Copy of Backup Job 1, target repository in cloud, retention x days
- Backup Job 2: VMs from datacenter 1, target repository in datacenter 1, retention 14 days
- Backup Copy Job 3: Copy of Backup Job 2, target repository in datacenter 2, retention 14 days
- Backup Copy Job 4: Copy of Backup Job 2, target repository in cloud, retention x days
Fabian
Product Management Analyst @ Veeam Software
-
- Influencer
- Posts: 11
- Liked: 1 time
- Joined: Mar 29, 2020 6:24 am
- Full Name: myRCvmforum
- Contact:
Re: Alternative to job chaining
Thanks @Fabian. We'll look into doing that although data center 2 is actually just a different room within the same campus (linked via fibre).
Who is online
Users browsing this forum: Baidu [Spider], ncl22 and 3 guests