dellock6 wrote:A quick and dirty workaround, have you considered to simply process that large 8TB vm with a dedicated job?
It is possible, but then we may have too many things running in parallel or the small VMs from the other job tmay steal all repository slots. Again, we prefer "well defined" settings than "random selection".
Also, moving these VMs to a different job will mean new full + chains and housekeeping the former jobs to clear manually old unneeded versions.
dellock6 wrote: but while you wait for a feature that may or not come in v10 or even later, this could solve your problem
Well, we will need to adapt and live with it. But if it was implemented (just ordering should be not a big deal IMHO), it would be a plus
Spex wrote:If you use one tag to describe the complete processing I understand your concern about complicated job handling.
In our environment each tag has only one meaning. we have tags for schedule time, guest processing, retention, useraccount for guest agent.
So you can combine them all to your need. For each backuptime I have a backupjob - the rest is done by tags within the job.
Yes, we use several tags for different kinds of jobs (repo, app processing or not, scheduling, retention, etc.).
We have different tags to manage for a VM the kind of retention, backup frequency (from every 1h to every 7 days), off-site copyjob settings, the target repository, app processing or not, etc. But we would like to avoid "thinking" as much as possible as to where to put a VM and doubling all tags to add a suffix "-bigVM" or "-1stGroup" to them complicates much more the infrastructure.
ITP-Stan wrote:If you use TAGS you do not get a list of VM's in the JOB but you can actually manually add those 2 big VM's to the job and set it to process them first. Veeam will be smart enough not to process them twice.
However this does remove some of the flexibility the tags system offers. Because when you change the tags on those VM's they will still be processed by that job you added them manually too.
Exactly. We can do that but we lose the flexibility and role separation. It also breaks our automatic reporting system:
APP X uses VM1, VM2, VM3, VM4, which have tags A,B,C,and D which are well defined backup policies. There is no need to query Veeam to discover if somebody added a VM by hand here or there or if it lands in a job because it was nested from somewhere else. Our reporting just needs to query vCenter.
Thanks you all for this discussion and ideas