VBR and Renamed backup jobs

[ThierryF]

Hello,

A word about ourconfig : WBR953 on Win2016. SQL db on SQL HAG 2016 Cluster, Vm backup (VC65, ESX65)
All disk backups are thru a tape job written to tape.
We just discovered that when a backup job is renamed, new backup job is correctly
listed, editable and schedulable in Jobs->Backups from Home gui.

But :
From Backup->Disks in Home gui, backups are still registered using "OLD" backup job name ...
If you seach on the given vm, for sample, you retrieve the vm and all of its backups (the ones started
by the job with its "old job name" and "new job name") but all listed under "Old job name" ...

I would expect that when backup job name to be renamed, that backups to be listed using NEW job name
and the OLD job name to disappear from "DISK" and "TAPE" sub-trees once removed from repository
or used tapes to be recycled.

Bug ? Feature ?

Th

[nitramd]

The SQL database that Veeam uses retains the old name. You'll need to update the Veeam SQL database to reflect the job new name.

Veeam Support can assist with this.

[ThierryF]

Thanks for the reply.

Even if Veeam Support can assist, I have pain to explain that case should be opened to support to rename a job ...

Just a question :
why allowing job rename if you have to manually update SQL db ?
The folder on the repository is neither renamed...
A new one should be created at next job run reflecting new backup job.

So, why allowing job rename ?
using object-ID in way of object-name should be more transparent ...
or simply not allow job rename anymore ...

Th

[veremin]

This is expected behaviour: we don't update names of backups, because names of already created backups stay intact - wait till they fall out of the specified retention and get removed by it.

And we do allow renaming backup jobs, so that, new backup files can have whatever names you'd like to.

Thanks!

[ThierryF]

Hello Vladimir,

It's the problem : not that the already created backup job names to stay unchanged nor even the new backups to still be stored in location reflecting OLD jobname
(In fact, I do believe the backup folder mapping is filled in at job creation with original job name and then never updated to reflect job name changes and,
by consequences, whatever the retention may be (14 days in my case), folder will never get removed/updated.
This, I believe because of backup chaining or you need to force a full cycle to new location.)
but from GUI, you have a de-sync between your job list (Job->Backup) and backups (Backups->Disk/Tape)

It can be confusing in env with lot of jobs.

Sample :
I create a job JOB_A with VM1. Once started, backup files will be stored in \\SCALEOUT\REPOSITORY\JOB_A folder.
I receive from VBR Email notification that JOB_A succeeded.
In Backup-> Disk, I see JOB_A with VM1 backup.

I now rename JOB_A to JOB_B and relaunch backup.
Email notification will refer to JOB_B.
In Backup->Disk, I always see JOB_A with VM1 and 2 backups.

If someone has to recover a backup refering to JOB_B, like operators for sample, no JOB_B in list.
And as over the time, jobs may have been renamed more than once ... Let's try to explain them to look for VM name
to retrieve backup job names or if a VM is defined in different jobs with different disk selection ...

I have a TapeCopy Job and both backups (from JOB_A and JOB_B) are registered using JOB_A name.

I expected to see a JOB_B entry with VM1 and, as you stated, see the JOB_A folder to be removed from GUI
as soon as retention to be expired but it isn't ...

How to retrieve backups from JOB_B ?

[veremin]

There are no immediate plans to change this behaviour, which has been working for our customers many years without disturbing them seriously.

Anyway, your vote has been taken into account.

Thanks for reaching us!

[jcavalear]

One method I've used to rename jobs and have the corresponding folders in the repository renamed is to clone the original job and then rename it something like "original _old" and then disable it. You can then rename the clone to the original job name and run it. Once you reach your retention goal you can then go back and delete the "_old" job and files from Veeam. It's not as easy as renaming the job and having everything follow suit but this is a pretty easy work around for what you're looking to do. Hope it helps.

[@IT_Guru]

Although the product has been "working" for years for customers, do not underestimate the desire for this feature to be included in the future.

When I rename a job say for example "SQL-4hourtransaction-1Y-4Q-2M-4W" to something like "SQL-1hourtransaction-0Y-4Q-1M-2W", I would EXPECT that the disk supporting this backup should be searchable on the OLD and the NEW name! This can be a management nightmare, as now I need to maintain a separate list/spreadsheet to document the old and new names.

Please reconsider this issue/feature/bug