-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
In a couple of weeks.
-
- Influencer
- Posts: 12
- Liked: 1 time
- Joined: Nov 16, 2009 8:09 am
- Full Name: Ben Richardson
- Contact:
Re: V5 VBK file names
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....
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....
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
No, VBK file is all you need to perform import and restore.PapaSmurf wrote:Yes, Gostev's script will work but we'd then have to import any remote jobs in order to restore?
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
I wish I had seen this post before updating to V5 yesterday ![Sad :-(](https://forums.veeam.com/images/smilies/icon_sad.gif)
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
![Sad :-(](https://forums.veeam.com/images/smilies/icon_sad.gif)
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
-
- Veteran
- Posts: 391
- Liked: 39 times
- Joined: Jun 08, 2010 2:01 pm
- Full Name: Joerg Riether
- Contact:
Re: V5 VBK file names
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
![Wink ;-)](https://forums.veeam.com/images/smilies/icon_wink.gif)
best regards,
Joerg
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
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.joergr wrote: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.
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.
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
Renaming my backup files was a stupid idea, because all of last nights backups have now failed ![Sad :-(](https://forums.veeam.com/images/smilies/icon_sad.gif)
![Sad :-(](https://forums.veeam.com/images/smilies/icon_sad.gif)
-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
Re: V5 VBK file names
Any change in status? This is the main reason why I have not fully implemented 5.0 yetGostev wrote:In a couple of weeks.
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
No changes.
-
- Influencer
- Posts: 19
- Liked: 3 times
- Joined: Jul 21, 2010 8:29 am
- Full Name: Ulrik Lunddahl
- Contact:
Re: V5 VBK file names
Still no change ?Gostev wrote:No changes.
-
- VP, Product Management
- Posts: 27267
- Liked: 2768 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: V5 VBK file names
Yes, still no change.
-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
Re: V5 VBK file names
How about now?Vitaliy S. wrote:Yes, still no change.
![Mr. Green :mrgreen:](https://forums.veeam.com/images/smilies/icon_mrgreen.gif)
As you can see, we are all eagerly awaiting this change
![Very Happy :D](https://forums.veeam.com/images/smilies/icon_biggrin.gif)
-
- Enthusiast
- Posts: 44
- Liked: 4 times
- Joined: Mar 19, 2010 12:36 pm
- Full Name: David Hirsman
- Contact:
Re: V5 VBK file names
Whats up with the delay of 5.0.1??Vitaliy S. wrote:Yes, still no change.
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...
-
- VP, Product Management
- Posts: 27267
- Liked: 2768 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: V5 VBK file names
David,
5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon![Wink :wink:](https://forums.veeam.com/images/smilies/icon_wink.gif)
5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon
![Wink :wink:](https://forums.veeam.com/images/smilies/icon_wink.gif)
-
- Enthusiast
- Posts: 44
- Liked: 4 times
- Joined: Mar 19, 2010 12:36 pm
- Full Name: David Hirsman
- Contact:
Re: V5 VBK file names
Woow!! that´s really good newsVitaliy S. wrote:David,
5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon
![Very Happy :D](https://forums.veeam.com/images/smilies/icon_biggrin.gif)
Thanks for the info Vitaliy
-
- Veteran
- Posts: 283
- Liked: 11 times
- Joined: May 20, 2010 4:17 pm
- Full Name: Dave DeLollis
- Contact:
Re: V5 VBK file names
Awesome news!! This will address the naming convention of the Veeam backup files, correct?Vitaliy S. wrote:David,
5.0.1 will be available in next 24 hours , so you'll be able to start using it very soon
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
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.
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.
-
- Enthusiast
- Posts: 38
- Liked: never
- Joined: Dec 18, 2009 10:05 am
- Full Name: murda
- Contact:
Re: V5 VBK file names
Gostev, Backup exec holds its own catalog so it does not matter if you provide the date in the naming convention ...Gostev wrote:
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.
Backup exec catalogs per date so ... what you're saying doesn't make any sense.
I' haven't got any succes with deltacopy and the ps1 script.Gostev wrote: 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.
![Neutral :|](https://forums.veeam.com/images/smilies/icon_neutral.gif)
I do not understand the idea behind the new naming convention. Please explain why this has been implented?Gostev wrote: 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.
What are the benefits?
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
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.murda wrote: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.
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.murda wrote:I do not understand the idea behind the new naming convention. Please explain why this has been implented? What are the benefits?
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.
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
If we acknowledge the limitations of 1 & 2, neither of which affect us. Is it possible to obtain the registry hack now?Gostev wrote: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.
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?Gostev wrote: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).
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
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
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).mcwill wrote:If we acknowledge the limitations of 1 & 2, neither of which affect us. Is it possible to obtain the registry hack now?
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.mcwill wrote: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?
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.mcwill wrote:Hopefully the answer is still a hotfix, and then of course the obvious questions are..
a) Is there an ETA on the hotfix?
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.mcwill wrote:b) How will the availability of the hotfix be communicated?
-
- Influencer
- Posts: 19
- Liked: 1 time
- Joined: Dec 11, 2009 8:58 am
- Full Name: MC
- Contact:
Re: V5 VBK file names
I have requested the hotfix via support but they say it isnt available - is there a hotfix ID I can request?
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
The patch is not available yet indeed.
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
Any news on the patch?
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
Hi, release of this patch was postponed to mid-January because of holidays and inclusion of additional bug fixes. Thanks!
-
- Enthusiast
- Posts: 36
- Liked: never
- Joined: Aug 03, 2010 9:20 pm
- Full Name: SC IT Admin
- Contact:
Re: V5 VBK file names
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
Thanks once again!
John
-
- Chief Product Officer
- Posts: 31419
- Liked: 6992 times
- Joined: Jan 01, 2006 1:01 am
- Location: Baar, Switzerland
- Contact:
Re: V5 VBK file names
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 ![Smile :)](https://forums.veeam.com/images/smilies/icon_smile.gif)
![Smile :)](https://forums.veeam.com/images/smilies/icon_smile.gif)
-
- Enthusiast
- Posts: 64
- Liked: 10 times
- Joined: Jan 16, 2010 9:47 am
- Full Name: Iain McWilliams
- Contact:
Re: V5 VBK file names
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?
Has anyone here received the same and been able to figure out how to switch it on?
-
- VP, Product Management
- Posts: 27267
- Liked: 2768 times
- Joined: Mar 30, 2009 9:13 am
- Full Name: Vitaliy Safarov
- Contact:
Re: V5 VBK file names
Iain, you should create a registry key to enable legacy VBK naming convention. Please contact our support to get the key. Thanks!
-
- Enthusiast
- Posts: 26
- Liked: 2 times
- Joined: Oct 22, 2010 7:02 pm
- Full Name: John Taylor
- Location: Athens, GA
- Contact:
Re: V5 VBK file names
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
----
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:
-John
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 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.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.
----
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:
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.--stop-at=y-m-dTh:m Stop rsync at year-month-dayThour:minute
-John
Who is online
Users browsing this forum: AdsBot [Google] and 52 guests