How to disable VBK rename after maintenance task?

[Luke_TCX]

Hi,
we need VBK files, created by reversed incremental jobs, without timestamp in the file name.
Registry key DisableVBKRename=1 did the trick for us, until i add maintenance
(defragment and compact task) to the jobs.

Every time, after maintenance, VBK files got standard file name, with a timestamp,
and if i want back to short name, a have to remove current files and create new ones.
It doesn’t matter, if backup job is imported from Veeam 8, or created new in v9.

We have Veeam Backup v9, and last update didn’t help (9.0.0.1491).

Is it known problem, or i should do something else to get short VBK file names?

[foggy]

Not a known problem, as far as I can tell. I've discussed this with R&D and we'll look at the issue closer. Thanks for the heads up.

[Luke_TCX]

Thanks for replay. I hope you could reproduce this issue in your environment.

We have plans to expand our Veeam Backup system on new servers
and static VBK names will be very important for us.

[Gostev]

Hmm, we stopped supporting this key as soon as we added Backup Copy jobs to the product. The key was only needed before Backup Copy jobs existed, because the only way to copy backups efficiently was using rsync or alike. What is your use case for using this key?

[Luke_TCX]

I used static names on VBK files for “Files to Tape” jobs.

But now i see, i overlooked something.

Before maintenance option was added, i did full backups periodically on reversed
incremental jobs, and i had two VBK files in one folder sometimes.

But now, with maintenance, instead of single file, i can add to job whole
folder with *.vbk mask, and this should work.
I'll have one VBK file in one folder most of the time, and that’s fine for me.

I think, this is end of case, thanks for your time and help

[veremin]

Correct. You can select the whole folder and by specifying corresponding file mask make a files to tape job copy only full backup files. Thanks.

[fika]

Hi,

Is registry key DisableVBKRename=1 supported again in Veeam Backup v9.5 ?
I would have liked my .vbk files not to be renamed, in my forever forward incremental job, even with maintenance tasks (corruption guard & defrag) activated.

Thank you very much !

[fika]

Sounds like it still works in 9.x : https://www.veeam.com/kb1076
But is it now compatible with maintenance tasks ?
Thank you again !

[foggy]

They registry value works, but not in case of compact operation. Could you please clarify your use case for using this key?

[fika]

Thank you very much Foggy for your answer.

My use case is the following.
I use rsync to sync the forever incremental repository to an offline location.

Let's imagine we are Monday night, the generated .vib is quite huge.
It is merged to the .vbk.
Then sync to offline location starts.
As the modification made to the .vbk file is very big, unfortunately, the sync did not complete in its allowed time frame.
The partial uploaded .vbk file is however kept offsite.

We are now Tuesday night.
Let's imagine the generated .vib is quite small.
It is merged to the .vbk.
Then sync to offline location starts.
Unfortunately, as the .vbk filename has changed, the offsite partial .vbk file is not considered, and sync restarts uploading all blocks from the huge Monday backup.

If .vbk filename had remained the same, sync would have restarted from where it stopped on Monday night, thanks to the offsite partial .vbk file.
And it would certainly have properly finished.

If the registry value still works for jobs without compact operation, I think it should be quite easy to support it when compact operation is enabled ?
Would be really really nice to see this in the next update.

Foggy, thank you very much for your support !

[foggy]

Any reason why you're using rsync instead of backup copy? With backup copy you wouldn't see this issue.

[fika]

Because our offsite infrastructure does not include Windows / Veeam servers, so we can't use the "Backup Copy" feature to our offsite location.
This is why we use rsync, targeting UNIX servers.

[foggy]

You can use Linux server as backup repository as well.

[fika]

Thank you Foggy for the link.
I would have however liked to continue using rsync.
Could it then be possible to think about supporting DisableVBKRename=1 even if maintenance tasks are enabled ?
Thank you very much again !

[fika]

Foggy, one question, if I set DisableVBKRename=1 with a weekly maintenance task enabled, will rename of the .vbk file occur everyday, or only once a week after maintenance task ?
If I set this registry key for an already started job, do I need to launch a whole new full backup for the key to take effect ?

Thank you very much for your support !

[foggy]

Foggy, one question, if I set DisableVBKRename=1 with a weekly maintenance task enabled, will rename of the .vbk file occur everyday, or only once a week after maintenance task ?

Not sure it will work as you would like, since VBK will be renamed upon compact operation and to get back to the name without a timestamp, you would need to start anew (see below).

If I set this registry key for an already started job, do I need to launch a whole new full backup for the key to take effect ?

According to this KB, the value works for new jobs or jobs for which you first perform the "Remove from backups" command. Also don't forget to restart the backup server after making this registry change.

[fika]

Mmmmh so it should work one week, until the Saturday compact operation run.
Once compact will have run, the .vbk will be timestamped.
Then, will the .vbk name change everyday ? Or only the next Saturday, after the next compact operation ?
Thank you again Foggy !

[foggy]

VBK will be changed only upon compact operation, so it will remain the same (timstamped with the date of compact) during the week.

[fika]

Foggy, thank you very much for your answer !
This behavior could help me a tittle though

Btw, did you manage to get in touch with dev team to propose them to support DisableVBKRename=1 even after compact operation ?

Thank you again !

[foggy]

We have this filed in our issue/feature tracking system since the beginning of this thread, but there's no particular ETA for this at the moment.

[fika]

OK, since about 18 months then
Anyway, thank you very much for your confirmation, and let's then stay tuned !

[fika]

Foggy, I confirm the behaviour, VBK name changes only upon compact operation, otherwise it remains the same (timestamped with the date of compact).

I would really be glad if you could support DisableVBKRename=1 even after compact operation, in upcoming update 3 for Veeam Backup & Replication 9.5.
That would really be good news !
If we think about it, the fix should be quite tiny to write (compared to other ones), don't you think so ?

Thank you very much again to you and dev team for your support !

[foggy]

This will not be a part of U3.

[Dave T]

I think rsync will have a tough time finding out the bytes unless compression is disabled (which you probably don't want during your WAN transfer).

Currently testing in a home lab but had a similar case where I wanted to get my Veeam backups onto offline cloud storage and noticed that the file had a different name. My thoughts were that this shouldn't matter since the program that I was using (hashbackup) supports deduplication.

The trick to get it to work well (high deduplication with full files regardless of name/timestamp) was to disable compression entirely and keep on inline deduplication optimized for a lan target.

So flow is basically backup takes place with Veeam (no compression). Script runs to trigger hashbackup which compresses and deduplicates the files before putting them on the cloud. A Veeam backup directory of about 46GB would go down to around 6.5GB of files. If enabling any compression it would totally throw off hashbackups deduplication. I'm making some assumptions here but I don't see how rsync would work any better.

[fika]

@foggy, any news regarding this ?
Really looking forward to see this...
Many thanks !

[foggy]

No news, we haven't got resources for that, too few requests.

[fika]

OK @foggy, fingers crossed you'll find some time to work on this

[Radake]

@foggy, @Gostev, @veremin, Veeam dev team...
Do you have some news regarding full DisableVBKRename option support please, even after maintenance tasks ?
Thank you!

[veremin]

The request number haven't gone any further, since our last reply. So, no we haven't changed anything for this matter. Thanks!

[Radake]

Thank you @veremin for your prompt reply.
Here's a new request then

If we think about it, the fix should be quite tiny to write (compared to other ones), don't you think so ?

I tend to agree, especially thinking that DisableVBKRename is already implemented and functional, the only thing we need is to keep it enforced even when maintenance tasks run...

Would really be nice...
Thank you again for your support and understanding Veeam dev team !