Hey,
I'd like a feature in the console that makes an analysis of the VMs when starting a tag based job and from a set of rules manipulate the way veeam handles the backup job.
Background:
- We rely heavily on vmware tags when setting up backups. Having custom jobs is no option for us.
- When creating a job that contains VM objects only you can modify the VM backup start order. When using tags there is no way in the console to modify the startorder since the backup list is dynamic.
- Not being able to control the start order is giving us alot of pain in regards to extended backup times.
Example:
When running our jobs, we have 20 cores running the jobs per site, starting off with about 10-15 vms/site simoultaneous being backed up. At the end of the jobs, having the largest VM is being backuped alone for a couple of hours is extremly inefficient.
If the largest machine started first, we can backup other machines concurrently and we would then cut about 50% of the backup time for that job.
Proposed solution:
Have a feature that analyse a set of properties of each vm contained in the backup job and from a set of rules (or policies) control the behavior of the job.
In our case we want to veeam to analyse the vms and set the starting order in the job based on largest vm size.
There might be other companies wanting to control the backup job based on other criteria than us, so making the feature it as flexible as possible from the beginning might be a good thing.
Best Regards
Chris
-
- Novice
- Posts: 3
- Liked: never
- Joined: Apr 22, 2016 9:45 am
- Full Name: Chris Bing
- Contact:
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Feature request - Pre-backup analysis and rule based bac
Hi Chris and welcome to the forums!
First of all thanks for clear request explanation.
As for the backup priority logic, there is an interesting topic explaining the load balancing and priorities. Please take a look. I believe the basic rules didn`t change since v8.
Your request of making a priority rule inside VM folder/cluster/resource pool/etc. makes sense and will be taken into account.
First of all thanks for clear request explanation.
As for the backup priority logic, there is an interesting topic explaining the load balancing and priorities. Please take a look. I believe the basic rules didn`t change since v8.
Your request of making a priority rule inside VM folder/cluster/resource pool/etc. makes sense and will be taken into account.
-
- Novice
- Posts: 3
- Liked: never
- Joined: Apr 22, 2016 9:45 am
- Full Name: Chris Bing
- Contact:
Re: Feature request - Pre-backup analysis and rule based bac
Thanks for your reply,
Just to clarify, I don't mean the logic of prioritizing resources between jobs. I'm talking about being able to change the start order of vm's in the same job when using tags, based on vm disk size. Basically like you can do if the job only contains vm-objects moving them up and down the list. Main difference is that we need a feature to be able to change the start order within a job dynamically with rules.
Best Regards
Chris
Just to clarify, I don't mean the logic of prioritizing resources between jobs. I'm talking about being able to change the start order of vm's in the same job when using tags, based on vm disk size. Basically like you can do if the job only contains vm-objects moving them up and down the list. Main difference is that we need a feature to be able to change the start order within a job dynamically with rules.
Best Regards
Chris
-
- Veteran
- Posts: 7328
- Liked: 781 times
- Joined: May 21, 2014 11:03 am
- Full Name: Nikita Shestakov
- Location: Prague
- Contact:
Re: Feature request - Pre-backup analysis and rule based bac
Provided topic also explains VM priority logic inside a single job(just FYI):
Thanks!
And your request of making a rule to list the VMs of the VM container is clear.tsightler wrote:One important thing to remember is that "resources" can refer to things like datastores as well. By default Veeam will only run 4 snapshots on the same datastore within a job, so if a job has a lot of VMs from a single datastore, while the job stated later has VMs on another datastore, it's possible that the second job will get task assignments even though the first job is not finished. Also, if you've enabled storage I/O control it can play a role here as well since it can stop tasks being assigned to a datastore that is already overloaded which means proxy task resources can be assigned to jobs datastores that aren't as busy.
Thanks!
Who is online
Users browsing this forum: Bing [Bot] and 39 guests