Hi,
I want to copy the Proxmox backup to a cloud repository.
Usually I create the copy job and choose it to run after the source job.
My problem: The Proxmox Backup-Job is not listed in the "After this job"-Dropdown.
Is this a bug?
Greetings
Sebastian
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Oct 28, 2024 3:20 pm
- Full Name: Sebastian Bauhaus
- Contact:
-
- VP, Product Management
- Posts: 7076
- Liked: 1510 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Run Copy after Proxmox Job
You don´t have to queue jobs together that way.
Backup Copy Jobs transport the backups automatically for you. Just setup a backup copy job.
Job chaining is for source backup jobs only and only for those where you need to ensure the specific order. For example at Cluster processing that can not tolerate parallel processing.
Backup Copy Jobs transport the backups automatically for you. Just setup a backup copy job.
Job chaining is for source backup jobs only and only for those where you need to ensure the specific order. For example at Cluster processing that can not tolerate parallel processing.
-
- Lurker
- Posts: 2
- Liked: never
- Joined: Oct 28, 2024 3:20 pm
- Full Name: Sebastian Bauhaus
- Contact:
Re: Run Copy after Proxmox Job
Yeah but i cannot chain source jobs either. For other Jobs (e.g. Agent Backups) this works but as soon as Proxmox Backup is involved, the chaining options disappear.
I want to achieve:
1. Backup first set of Proxmox VMs
2. Backup second set of Proxmox VMs
3. Copy both jobs to cloud
Currently I have to guess when both jobs end. Of course I can let run backup jobs simultanously and the copy job hourly, but I like it in order and do not see the reason why chaining is not available here.
I want to achieve:
1. Backup first set of Proxmox VMs
2. Backup second set of Proxmox VMs
3. Copy both jobs to cloud
Currently I have to guess when both jobs end. Of course I can let run backup jobs simultanously and the copy job hourly, but I like it in order and do not see the reason why chaining is not available here.
-
- VP, Product Management
- Posts: 7076
- Liked: 1510 times
- Joined: May 04, 2011 8:36 am
- Full Name: Andreas Neufert
- Location: Germany
- Contact:
Re: Run Copy after Proxmox Job
Backup Job chaining is a bad things as they would depend then on each other. Would one fail, then the others will not be executed.
As I shared the purpose of job chaining is not for scheduling. Please allow me to explain a bit more.
You define Proxy and Repository Task slots. Those are for individual VM disk processing. You control with this the load that you cause.
To achieve an ideal backup window, all task slots are used 100% of the (backup) time.
For this you overbook basically the task slots by starting more jobs than the task slots could handle at the same time, so that you have always a VM waiting for processing when a task slot becomes free.
There is a priority list. VM disks from an already processed VM has priority for the next available slot, then VMs from already processing job, then the second job will be started, when no VM disks from first job are available.
This will give you ideal backup window for both jobs.
For the backup copy job to cloud. It depends a bit on how you setup the job or ScaleOutBackupRepository (SOBR) Archive Tier, but in general it follows the same pattern, when task slots are available, the offload starts when no VM backup with higher priority is waiting for processing.
Again ideal processing time without chaining of jobs.
As I shared the purpose of job chaining is not for scheduling. Please allow me to explain a bit more.
You define Proxy and Repository Task slots. Those are for individual VM disk processing. You control with this the load that you cause.
To achieve an ideal backup window, all task slots are used 100% of the (backup) time.
For this you overbook basically the task slots by starting more jobs than the task slots could handle at the same time, so that you have always a VM waiting for processing when a task slot becomes free.
There is a priority list. VM disks from an already processed VM has priority for the next available slot, then VMs from already processing job, then the second job will be started, when no VM disks from first job are available.
This will give you ideal backup window for both jobs.
For the backup copy job to cloud. It depends a bit on how you setup the job or ScaleOutBackupRepository (SOBR) Archive Tier, but in general it follows the same pattern, when task slots are available, the offload starts when no VM backup with higher priority is waiting for processing.
Again ideal processing time without chaining of jobs.
Who is online
Users browsing this forum: No registered users and 2 guests