Skip to main content

Missing feature in V12

  • April 16, 2023
  • 9 comments
  • 429 views

Nico Losschaert
Forum|alt.badge.img+11

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

9 comments

Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 9586 comments
  • April 16, 2023

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.


Nico Losschaert
Forum|alt.badge.img+11
  • Author
  • On the path to Greatness
  • 681 comments
  • April 16, 2023

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.


Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 9586 comments
  • April 16, 2023

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.


marco_s
Forum|alt.badge.img+8
  • On the path to Greatness
  • 402 comments
  • April 17, 2023

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!


dloseke
Forum|alt.badge.img+8
  • Veeam Vanguard
  • 1459 comments
  • April 17, 2023

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.


Nico Losschaert
Forum|alt.badge.img+11
  • Author
  • On the path to Greatness
  • 681 comments
  • April 17, 2023

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...


kristofpoppe
Forum|alt.badge.img+10
  • Veeam Vanguard
  • 137 comments
  • April 19, 2023

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


marco_s
Forum|alt.badge.img+8
  • On the path to Greatness
  • 402 comments
  • April 20, 2023

We hope that @kristofpoppe !


Chris.Childerhose
Forum|alt.badge.img+21
  • Veeam Legend, Veeam Vanguard
  • 9586 comments
  • April 20, 2023

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

Not so much repair as bring back.  😁