Skip to main content
  • EN

Hi all

After working already for more than 2 months with the new version of VBR, I must say it’s great with all new features and changes.

But I must being honest, there is a feature that I’m missing that is not available anymore after the upgrade…

What am I missing after the upgrade?

For a new backup copy-job (not the existing after upgrading) it is not possible to define certain static VMs in a backup copy-job anymore. You have to select an existing primary backup job or repository.

I must be honoust, it’s better than before, now we can change between immediately and periodically backup-copy jobs without the need to create a new backup-copy job.

All good and even better than before, but….

 

Why I need this frequently?

Normally I always create 1-to-1 backup copy jobs to primary backup jobs, so normally everything is OK and not needed, but there is 1 exception to the rule!

Normally we always used periodically backup copy jobs with statically defined VMs in the job for backup copy jobs connected to the VCC?

Why?

In most cases, the tenant is only copying the most critical VMs to the VCC to keep the costs under control (needed storage and number of VMs).

I don’t like to create seperately backup jobs to define the VMs that are also being copied to the VCC.

So, that is not possible anymore in V12 when creating new backup copy jobs.

I can understand that this is perhaps not easy to develop (I don’t know), but an alternative way to define them should be possible - see beneath.

 

Alternative solution : 

If it is not directly possible to define statically defined VMs in the job, perhaps an alternative way is to create certain Veeam tags in VBR, in the way that general exclusions are now possible in V12 is a very handy way.

I already discussed that topic with @Pieter.V (Pieter Vereecken - Team Lead Cloud Architects EMEA - also being a VCC guru) and he agrees that there can several other cases where we can use those Veeam tags.

Those Veeam tags we can use then as referrals in the backup copy job to define which VMs are being copied to the VCC.

 

Does anyone else has alternative solutions for that?

 

I will create a feature request in the Veeam forums.

I hope in the next patch this shotcoming will be solved or at least an alternative way is being possible.

regards

Nico

I would definitely use tags for this type of thing cause you can create many different ones and define what they are for.  In your case the ones required to be copied to VCC as the main job matches the tag and the copy job uses that job.

Hi @Chris.Childerhose , thx for your feedback.

Just to be more clear : I mean a new feature in Veeam VBR is needed : so Veeam tags like the general exclusions possible from version 12. Not the Vmware tags we can use in backup jobs. It has to work for Hyper-V environments, vmware environments and even agents. So using Veeam tags should make the difference in my opinion.

Hi @Chris.Childerhose , thx for your feedback.

Just to be more clear : I mean a new feature in Veeam VBR is needed : so Veeam tags like the general exclusions possible from version 12. Not the Vmware tags we can use in backup jobs. It has to work for Hyper-V environments, vmware environments and even agents. So using Veeam tags should make the difference in my opinion.

Ah gotcha. Thanks for clarifying.

Hi @Nico,

the problem had also been discussed in this post:

In my opinion, tag is not a solution..however Veeam is aware of the problem/disruption, I hope they fix and return to the previous configuration in the next patches!

I must be honoust, it’s better than before, now we can change between immediately and periodically backup-copy jobs without the need to create a new backup-copy job.

 

I wasn’t aware that this was a possibility.  The last time I looked, I thought the option to change was still disabled, but maybe it’s due to a job that existed before upgrading to v12 or maybe I just didn’t see it correctly.  I have a lot of old jobs that are periodic that I’d love to migrate to Immediate.

Hi @Nico,

the problem had also been discussed in this post:

In my opinion, tag is not a solution..however Veeam is aware of the problem/disruption, I hope they fix and return to the previous configuration in the next patches!

Hi @marco_s , thx for referring me to this post, I must have missed it. So I’m definitely not the only one missing it...

Sounds like something to ‘repair’ in v12a...

We hope that @kristofpoppe !

Sounds like something to ‘repair’ in v12a...

Not so much repair as bring back.  😁

Comment


Terms & Conditions