V5 VBK file names

[Gostev]

In a couple of weeks.

[PapaSmurf]

same issues here, we are using rsync. Yes, Gostev's script will work but we'd then have to import any remote jobs in order to restore?

ETA on 5.0.1 would be nice, as we'll also be reverting to 4.1 if it's some way off.......

EDIT: Sorry Gostev just saw your "couple of weeks" reply....

[Gostev]

Yes, Gostev's script will work but we'd then have to import any remote jobs in order to restore?

No, VBK file is all you need to perform import and restore.

[mcwill]

I wish I had seen this post before updating to V5 yesterday

Our NAS based rysnc replication is now broken - it would take approx 20 hours of full bandwidth to replcate 1 nights backup instead of the usual 1.5 hours in the middle of the night.

I'm currently resigned to manually renaming the files before kicking off the replication, but this isn't as secure as the fully automated system we had with 4.1

[joergr]

I thought i wrote some example how to even tell rsync to only use certain files of certain age - but anyhow: i hear 5.0.1 will be out soon.

best regards,
Joerg

[mcwill]

I thought i wrote some example how to even tell rsync to only use certain files of certain age - but anyhow: i hear 5.0.1 will be out soon.

Unfortunately, this isn't an option for ourselves. Although our NAS <-> NAS replication uses rsync it doesn't provide any fine tuning of the rsysnc options. It purely replicates the contents of a folder full of vbk files to a target folder on the remote NAS box. A process that worked very well until now.

Now if Veeam were wondering what features to add to V6, can I suggest an offsite mirror feature that utilises a local Veeam server to construct the backup onsite which is stored locally but in addition sends the backup file deltas to a remote Veeam server which then constructs an offsite mirrored backup.

[mcwill]

Renaming my backup files was a stupid idea, because all of last nights backups have now failed

[Daveyd]

In a couple of weeks.

Any change in status? This is the main reason why I have not fully implemented 5.0 yet

[Gostev]

No changes.

[Lunddahl]

No changes.

Still no change ?

[Vitaliy S.]

Yes, still no change.

[Daveyd]

Yes, still no change.

How about now? j/k

As you can see, we are all eagerly awaiting this change

[Davd]

Yes, still no change.

Whats up with the delay of 5.0.1??

I have two (in my view big) problems related to Veeam 5 and Veeam support informed me both issues would be solved in 5.0.1. They also told me that 5.0.1 were to be released at end of November so i waited paitently. And nothing. Then I saw Gostevs reply in another thread (to another user) that it would be released in begging of this week so once again... I was hoping to finally get hold of it to get my Veeam to work as expected. Today its tuesday...

[Vitaliy S.]

David,

5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon

[Davd]

David,

5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon

Woow!! that´s really good news

Thanks for the info Vitaliy

[Daveyd]

David,

5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon

Awesome news!! This will address the naming convention of the Veeam backup files, correct?

[Gostev]

Technically, 5.0.1 does have the registry hack enabling legacy naming convention for reversed incremental backup mode. However, because final testing uncovered some issues with changing naming behavior (as I forecasted on the first page), we want to wait until the first hotfix before giving away the registry key.

Specifically, changing VBK naming behavior affects two things:

1. Performing active (real) full backup manually or on schedule messes up backup set. The hotfix will disable active fulls altogether when this registry key is enabled, to make sure no one can initiate active full accidentally.

2. Import Backup does work when you are importing produced VBK alone, but does not work if you are importing whole backup set (i.e. VBK with one or more VRBs next to it). This is not a problem if you are syncing VBK alone to DR site, but it will pose problems if you are syncing the whole backup set with things like NAS replication. The hotfix will make sure import works well in any scenario.

Overall, I still do highly recommend adopting new naming convention, and only fall back to legacy naming convention as a last resort, when it is simply impossible to adjust your process to the new convention. Just to remind, I have already provided tools and workaround for many typical use cases earlier in this topic:

a) Example of setting up tape backup solution to work with legacy settings (using BackupExec as a sample). New naming convention is actually great for tape backup, as you no longer have to wonder when specific VBK file stored on tape was created, and additionally you will get ability to quickly search tape catalog for required Veeam backup file. Previously, all backup files had the same name, and this was making it nearly impossible to find the required one.

b) PowerShell script that can trigger any executable in a post job script, providing it with the path to the latest backup file so that it can be archived to tape, shipped to some storage, or synced offsite into the existing file with tools like RSYNC.

c) Linux shell script that will RSYNC latest VBK (no matter of its name) into existing VBK in offsite location.

We do realize however that there is at least one use case when solutions suggested above cannot help. Specifically, I am talking about NAS based replication that syncs whole folder with complete backup set to another NAS in DR location. So we are still intended to eventually make the legacy naming convention option available as UI setting (unfortunately the changes required are too major to be made a part of maintenance bugfix release).

But again, most of you are very unlikely to be in situation that makes it impossible to adopt new backup file naming convention.

[murda]

a) Example of setting up tape backup solution to work with legacy settings (using BackupExec as a sample). New naming convention is actually great for tape backup, as you no longer have to wonder when specific VBK file stored on tape was created, and additionally you will get ability to quickly search tape catalog for required Veeam backup file. Previously, all backup files had the same name, and this was making it nearly impossible to find the required one.

Gostev, Backup exec holds its own catalog so it does not matter if you provide the date in the naming convention ...
Backup exec catalogs per date so ... what you're saying doesn't make any sense.

b) PowerShell script that can trigger any executable in a post job script, providing it with the path to the latest backup file so that it can be archived to tape, shipped to some storage, or synced offsite into the existing file with tools like RSYNC.

I' haven't got any succes with deltacopy and the ps1 script.

c) Linux shell script that will RSYNC latest VBK (no matter of its name) into existing VBK in offsite location.

We do realize however that there is at least one use case when solutions suggested above cannot help. Specifically, I am talking about NAS based replication that syncs whole folder with complete backup set to another NAS in DR location. So we are still intended to eventually make the legacy naming convention option available as UI setting (unfortunately the changes required are too major to be made a part of maintenance bugfix release).

But again, most of you are very unlikely to be in situation that makes it impossible to adopt new backup file naming convention.

I do not understand the idea behind the new naming convention. Please explain why this has been implented?
What are the benefits?

[Gostev]

Gostev, Backup exec holds its own catalog so it does not matter if you provide the date in the naming convention ...
Backup exec catalogs per date so ... what you're saying doesn't make any sense.

I am sorry that this does not make any sense for you, but BackupExec (which I referenced in conjunction with something else btw) is by far not the only solution our customers are using for tape backups. Some customers are even using Windows XP to write files to tape... but even more oftenly, customers simply dump files to removable hard disk and take those offsite. There is no catalog, and you end up with bunch of removable disks containing VBK files with the same names.

I do not understand the idea behind the new naming convention. Please explain why this has been implented? What are the benefits?

To be able to be easily distinguish when specific backup files was made. Having the date in its name enables to quickly search for required backup file, without messing up with creation/modification dates which may change some times depending on tools you are using to copy/move files around.
This functionality is also required for some next version features that did not make it into v5.

That said, as I already mentioned earlier in this topic I do agree that not keeping backward processes compatibility was a big miss on our part, which is why we are trying our best to address this now.

[mcwill]

Technically, 5.0.1 does have the registry hack enabling legacy naming convention for reversed incremental backup mode. However, because final testing uncovered some issues with changing naming behavior (as I forecasted on the first page), we want to wait until the first hotfix before giving away the registry key.

Specifically, changing VBK naming behavior affects two things:

1. Performing active (real) full backup manually or on schedule messes up backup set. The hotfix will disable active fulls altogether when this registry key is enabled, to make sure no one can initiate active full accidentally.

2. Import Backup does work when you are importing produced VBK alone, but does not work if you are importing whole backup set (i.e. VBK with one or more VRBs next to it). This is not a problem if you are syncing VBK alone to DR site, but it will pose problems if you are syncing the whole backup set with things like NAS replication. The hotfix will make sure import works well in any scenario.

If we acknowledge the limitations of 1 & 2, neither of which affect us. Is it possible to obtain the registry hack now?

We do realize however that there is at least one use case when solutions suggested above cannot help. Specifically, I am talking about NAS based replication that syncs whole folder with complete backup set to another NAS in DR location. So we are still intended to eventually make the legacy naming convention option available as UI setting (unfortunately the changes required are too major to be made a part of maintenance bugfix release).

I'm confused, will there be a hotfix shortly that enables legacy naming. Or do we have to wait until it is rolled into the UI?

Hopfully the answer is still a hotfix, and then of course the obvious questions are..

a) Is there an ETA on the hotfix?
b) How will the availability of the hotfix be communicated?

Thanks,
Iain

[Gostev]

If we acknowledge the limitations of 1 & 2, neither of which affect us. Is it possible to obtain the registry hack now?

Hi Iain - yes, you can obtain it through support today. I just highly recommend to wait for a few more days for a hotfix addressing the issues I have described above. Just because it is too easy to start full backup accidentally. Plus, this specific scenario will receive extra testing during patch sign-off (always a good thing).

I'm confused, will there be a hotfix shortly that enables legacy naming. Or do we have to wait until it is rolled into the UI?

No, you do not need to wait for when it is rolled in UI. The registry hack is already there in 5.0.1 - I just do not recommend using it without having the patch applied.

Hopefully the answer is still a hotfix, and then of course the obvious questions are..
a) Is there an ETA on the hotfix?

As far as I know, devs are planning to release the code tomorrow. Then, it typically takes a few business day for QC to test and sign off.

b) How will the availability of the hotfix be communicated?

You should open a support case to be notified. We will not redistribute it via forum before or after hotfix is available, in order to track all customers who applied this patch.

[aqualityplace]

I have requested the hotfix via support but they say it isnt available - is there a hotfix ID I can request?

[Gostev]

The patch is not available yet indeed.

[mcwill]

Any news on the patch?

[Gostev]

Hi, release of this patch was postponed to mid-January because of holidays and inclusion of additional bug fixes. Thanks!

[SecondCity]

Thanks for your work on all of this, Gostev. Can I please request that Veeam notify its user community of this new feature when it comes available? Unfortunately, I don't check these forums all that often, and would hate to miss an announcement like this. Though we've gotten around this issue, it certainly would be nice for our small shop to continue using non-datestamped names (we only have 6 VMs backing up).

Thanks once again!
John

[Gostev]

Hi John, I will try to remember to do this, but it would be best if you open support case to be notified. This way you can be sure you will be notified

[mcwill]

I received the long awaited hotfix this morning - but I can't see an option to enable legacy naming.

Has anyone here received the same and been able to figure out how to switch it on?

[Vitaliy S.]

Iain, you should create a registry key to enable legacy VBK naming convention. Please contact our support to get the key. Thanks!

[jftuga]

For you guys using rsync, I would like to make several suggestions from the rsync man page.
http://www.samba.org/ftp/rsync/rsync.html

-y, --fuzzy
This option tells rsync that it should look for a basis file for any destination file that is missing. The current algorithm looks in the same directory as the destination file for either a file that has an identical size and modified-time, or a similarly-named file. If found, rsync uses the fuzzy basis file to try to speed up the transfer.
Note that the use of the --delete option might get rid of any potential fuzzy-match files, so either use --delete-after or specify some filename exclusions if you need to prevent this.

----

Batch mode can be used to apply the same set of updates to many identical systems. Suppose one has a tree which is replicated on a number of hosts. Now suppose some changes have been made to this source tree and those changes need to be propagated to the other hosts. In order to do this using batch mode, rsync is run with the write-batch option to apply the changes made to the source tree to one of the destination trees. The write-batch option causes the rsync client to store in a "batch file" all the information needed to repeat this operation against other, identical destination trees.

Generating the batch file once saves having to perform the file status, checksum, and data block generation more than once when updating multiple destination trees. Multicast transport protocols can be used to transfer the batch update files in parallel to many hosts at once, instead of sending the same data to every host individually.

Batch mode can be really awesome. If you have 2 VBK files stored locally from yesterday and today & you have yesterday's VBK file offsite (or at muliple backup locations), then this method will create binary diff file between the 2 VBK files which will be very small. This rsync aware diff file can then be applied to the remote locations to create a true copy of today's VBK file. You might need to be careful with compression, as this may cancel out the usefulness of this option.

----

If you use the cwRsync (google for this) version or can compile your own version from source, then you may also be interested in this option:

--stop-at=y-m-dTh:m Stop rsync at year-month-dayThour:minute

If your offsite copy process sometimes run too long, then you can encounter locking issues when trying to run the next Veeam backup. With this option you can stop the offsite backup process so that the current backup will run correctly. While not ideal, I still wanted to mention this.

-John