Clarification on individual vm backup chain behavior?

[kkuszek]

I changed an existing v8 job after upgrading to v9 over to the setting for individual vm backup chains.
Maybe my understanding of what that means is wrong.
Should I now have a chain of files for each vm within that backup job in the backup destination folder? or does this only impact how the files are packaged within the vib?

I was under the impression that instead of backup123.vib I would see backup123vm1.vib backup123vm2.vib, etc. in the file system.
Was I incorrect or have I experienced a bug? Active full has been run since switching to v9.

[foggy]

Active full needs to be performed after enabling the per-VM chain setting for it to take effect. Until that, backup files will continue to be created for the entire set of VMs.

[kkuszek]

Hi Foggy,
I have enabled this setting and then performed active full however I have seen no change in file creation.
Was I correct in the expected behavior?

[foggy]

Yes, your expectations are correct. Please contact technical support to verify your configuration.

[I.Makaryev]

Hello, Kurt!
One note: old backup files will remain unchanged.

As example, you had this situation:
JobName.vbk -> JobName.vib -> JobName.vib

Then changed to per-VM backup in repository settings and made Active Full. After that you will have to see something like that:
JobName.vbk -> JobName.vib -> JobName.vib -> VM1.vbk, VM2.vbk -> VM1.vib, VM2.vib -> etc.

[kkuszek]

Thanks I. Makaryev,
That was my expectation of behavior, it just wasn't the result of my change. Because of that I opened a flurry of tickets for my different issues including 01671498 for this one.

[neilmacneil]

Hi,

I've also had this happen to me. I've updated one of my repositories to per-vm and scheduled an active full for my backup job. This morning I'm only seeing a one new .vbk. I had some backup Copy jobs that I've deleted and recreated and they switched over to per-vm no problem. Please post any updates here if possible. Thanks.

-Neil

[foggy]

Neil, OP's case is currently escalated for a closer investigation. I recommend you opening your own case to verify your particular setup and be notified in case there are any solutions discovered.

[kkuszek]

Yep, what he said.
I thought it was only me, nice to see it's not just me. If you open a ticket your logs could help my case and vise versa so they figure it out.

[foggy]

Guys, have you performed active full manually using the job's shortcut menu or by the job schedule? Looks like per-VM chain doesn't take effect in the latter case - we were able to reproduce this and plan to fix in the next update.

[neilmacneil]

Hi,

I did a scheduled active full last night. I will try a manual tonight and confirm in the morning.

Thanks

[kkuszek]

I already have had unexpected active full job's run so I don't have the space to run another out of scope active full. What I will probably do is just kick one off this weekend right before the scheduled one would normally run.

I'm curious Neil to see how that pans out for you tonight.

[veremin]

What I will probably do is just kick one off this weekend right before the scheduled one would normally run.

Or you can temporarily disable the scheduled full and run it manually instead or via PowerShell. After that, enable periodic full schedule again. Thanks.

[neilmacneil]

Hi, running active full as opposed to a scheduled active full worked. Thanks.

[foggy]

Thanks for confirmation, Neil, and Kurt for the heads up. We're planning to address this in the next update.

[kkuszek]

Great,
thanks for the updates and ideas everyone. I think I am going to use powershell for mine.

[veremin]

The active full backup can be executed on demand via the following PS script:

Code: Select all

$Job = Get-VBRJob -name "Name of your backup job"
Start-VBRJob -Job $Job -FullBackup

Thanks.

[ChuckS42]

I am seeing this too.

Dumb question - how did this not get found and fixed during testing? Seems like a pretty basic bug. Makes me worry there will be more basic bugs.

[Gostev]

You are right to be worried. It's a major release, so of course there will be even more, and more basic bugs. This is normal, as all software in the world is created and tested by humans. I am sure you too can remember situations when you could not find something sitting right in front of you, while the location was obvious for your family member? That's just how human brain works, basic things are just as likely to get overlooked.

Also, the bigger the product gets - the harder it becomes to test due to the sheer number of dependencies (and so test scenarios), which are growing exponentially with every feature added. For example, this scenario may have been tested a few weeks before the release - but then, some change elsewhere unexpectedly impacted this scenario too, but it was not re-tested because no impact was expected (needless to say, re-testing every possible scenario after each change is simply not feasible). This is usually the main reason for this kind of obvious bugs... "fixed one thing, broke another one" - it happens all the time.

Finally, this bug is actually upgrade-related. And these kind of bugs are actually most common. Thing is, upgraded installations naturally get much less of raw testing time than clean installs, as for almost a year QC performs clean installs of new builds, while upgraded installs testing is only performed closer to the actual release, when everything else is ready.

So, bugs of all sorts in major releases are simply the fact of life... the only thing that matters is how quickly the software vendor can address those bugs. And we are usually good at that

[kkuszek]

Thanks guys.
I have confirmed that a manual active full does in fact create per vm chains while the scheduled did not for me as well.

[lightsout]

I'm on the enterprise version of v9, and I've just upgraded from v8.

My backup job repositories, and my backup copy job repositories both have been switched to 'per-vm backup files'. However, when I look on the file system, I am still only seeing large monolithic VBKs as per before. My jobs are all Active Full & incrementals and even the active full still has one large file.

Is there anything else I need to configure? Or something else that can block this? My jobs are not showing any errors.

Thanks!

[foggy]

You need to run active full for the setting to take effect. Please note that currently you should trigger it manually, since scheduled full doesn't enable this option (will be addressed in the next update).

[the_mentor]

Hi everyone,

After upgrading from v8 to v9 recently I changed the repository setting of an existing repository to Per-VM Backup files.
It seems like this change is not taking affect since i dont see a per backup file files being created.

Any ideas on how to resolve this issue?

[poulpreben]

Hi there,

It is required to trigger an Active Full in order to activate the feature. Did you already try that?

Thanks,
Preben

[lightsout]

Thanks all.

I saw the same behaviour on a backup copy job too. Until the source repository had an active full ran, the backup copy job didn't do per VM files either.

[veremin]

Starting from version 9 there is an option to create an active full backup for backup copy jobs as well. Might be worth giving it a try. Thanks.

[readie]

I have hesitated to move to per-VM backup chains, as your explanations here (manually doing a full backup) seems to imply that I will need almost twice the space on my repositories, in order to create the full backups? eg one backup job has a vbk of 2.2TB, and increments of around 30GB. I presume I will need around 2.2TB free space in order to start the per-VM backup chain (with a full backup?)? And in fact I have two other jobs on that repository with vbks of 2TB and 7TB,
And I can't do it a job at a time, as I have to switch the whole repository to per-VM backup chains?

[dellock6]

This is only partially true.
The option on the repository enables it to "receive" per-vm chains, but it's not mandatory to do so. As long as you don't run the active full, the same job using a repository with per-vm enabled will keep sending incrementals.

Indeed, the move to per-vm requires a full backup of each vm, but you can plan to move VMs to this new model one by one, or per groups. You can think about for example creating a new job, that as such will be per-vm, then out of say 500 VMs, move into this new job only 20 VMs. Only these VMs will have two full backups (one in the old backup, one in the new). At the same time, the VM is removed from the old backup, so as soon as retention kick in (say the 14 days per defualt) data is removed from the old backup file. Then you can even use the compact operation (new too in v9) and regain the free space of the old backup, and have again only one full related to that VM.

In large environments you can obviously automated this movement, and I see for example vSphere tags to be leveraged: a tag is inclusive in the new backup job, and becomes an exclusion in the old backup job.

And finally, you can think about leveraging also Scale-out Backup Repository to temporarily add an additional extent as spare free space, complete the conversion to per-vm for all your jobs, and then decommission this additional extent.

[readie]

Thanks Luca (for the reply at the weekend!), I thought I had seen some suggestions along those lines, but your explanation is very helpful. I think we'll try to leverage an additional repository, to go for Scaled Out repositories at the same time . . . then wait to see how much space is eventually used and reclaim space if we need to.

[readie]

Any chance of some documentation on this and other new features in V9, specifically for users upgrading from V8? 'Best practices to implement the new features of V9'? (Or if this already exists, can you point me to it please?)
I am now in a position to implement Scaled out Repositories, and am just wondering whether to create a new one with my existing two repositories, plus a new blank repository (to allow more space for creating per-VM chains etc). Do I just leave B&R to sort out its own preferences for where to put full backups and where to put incrementals . . , or do I really need to make some decisions myself?