Netbackup Hyper V backups running Sharepoint, SQL

[Rizwan_Ahmed_1]

We are running NBU 7.0.1 in our envoirnment and we are backing up SQL EXCHANGE hyper v etc.

We want to know if we backup a hyper -V machine running sharepoint/SQL or any other application. In case of the disaster If we restore the Hyper V backup will it restore the sharepoint application in a consistent state at that point on which backup for Hyper V has been done. We are backing up its database instance running on MSSQL seperately.

[RiaanBadenhorst]

Hi,

The only supported way to protect an application or database is with a netbackup client installed inside the hyperv guest/child. And by using an agent to backup the data (if its online)

[Rizwan_Ahmed_1]

Thanks Riaan for the information

[Mouse]

Actually the Hyper-V backup does quesce of SQL server and Exchange. It just doesn't truncate logs (for that you need to have app-level backup).

So, if you have proper Hyper-V backup you should be able to recover apps in a consistent state.

IIRC, 7.1 will have this feature for VMware too

[RiaanBadenhorst]

True, but then you cant really run your apps with logging enabled. If you do, the logs will never get truncated, and you'll run out of space.

Running without logs increases your RPO.

[Mouse]

Courtesy to Mr. Curtis Preston: http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/287-vmware-and-apps.html/

[Mouse]

I did a mistake in my own post. Hyper-V backup does log truncation for VSS-aware applications without NBU agent inside VM

[Mouse]

Hyper-V snapshot does log truncation, it's even more sexy than I thought before

[RiaanBadenhorst]

Thanks for the link, found this as well. http://www.backupcentral.com/mr-backup-blog-mainmenu-47/13-mr-backup-blog/287-hyper-v-ahead-of-vmware-in-the-backup-race.html

Seems its possible with both hyperV and Vmware (except 2008 on Vmware). Thing that worries me is if the status of these VSS backups quescing the app will report any errors through to NetBackup. Will you get a 1 or something else if there is an error in backing up the DB (and clearing the logs). Could get into a situation where we don't really know who is responsible for which component.

And are Symantec supporting it?

[Mouse]

I have no information whether NetBackup knows about the DB inside the VM or not (I don't think it does).

However, if snapshot of VM won't succeed you'll get a code 156 that's pretty obvious.

[maj_rif]

Hi,

As Riaan said you have to take backup at applicaiton level to truncate the log files. I'll suggest you an alternative to schedule SQL database maintenance to truncate log files before hyperV backup. 

Backup Exec is supporting GRT backup of Hyper V and SQL server as well, that normally turuncate the log files but we have to install SQL server agent on the Media server to confgire the granular recovery of SQL data or truncate the SQL log files. 

I hope that feature would be available in NetBackup as well, normally NetBackup is less reactive for windows base features. 

I hope that will assist you.

[RiaanBadenhorst]

But what constititues a failure of snapshot creation? Not quescing the database, not truncating the logs, etc. Just wondering if any of those will trigger a 156. If they don't then you're not really sure what you're backing up. Suppose we'll see when (if) its adopted officially.

Cheers

[Mouse]

Indeed, this definitely needs clarification from Symantec

[Rizwan_Ahmed_1]

Guys what the conclusion .

hyper V supports snapshot backups with application consistency.

Does Netbackup supports it as well or we require the agent to install with in VM. I am still confused.

[RiaanBadenhorst]

Hi,

I'm going with its not supported. From the discussion you would have seen its possible but you're not guaranteed that you're going to be able to recover. At the moment I don't see any indication in NetBackup that a) a database inside a VM was backed up successfully, and b) that the transaction logs were truncated. Without this information would you really trust the backup?

It like asking a SQL admin to do a dump and you just perform a file level backup of the folder containing his dump. Well not exactly, but that is the just of it. You don't have any indication that the SQL admin's backup was successful, you're just picking up what ever he gives you. When it comes to recovery you might find out that his backup (VSS in your hyperv case) didn't work. So who is to blame?

I'd check with support to as this seems to be unclear as it can be done, but there is no mention of this in any netbackup guide.

[Mouse]

NBU is not aware of DB inside the VM

VM AND DB backup are consistent according to MS claims

When you need to recover DB you'd recover entire VM, not DB only, but if you recover VM, DB would be consistent.

NBU agent gives you more control and information about what's happening and more granular recovery.

Hope this helps

[Rizwan_Ahmed_1]

So its better to do application backups as well with in the VM.

As I have worked with Vmware not Hyper-V before if you clone it or just make a copy of running VM to some other ESX or Workstataion the application running on it is in stable form. But i dont think same can be considrered for the backup.

What do you say guys ???

[RiaanBadenhorst]

Hi,

Think of it this way. A HyperV or VM backup is used to backup the whole container (vmdk files in vmware terms). This backup should be used to recover the whole system.

Now you'll know that with the latest features you can do a single pass backups and also restore files from within side the VM. This is great when you want to restore a single file, you can, and when you want to restore the whole thing, you can. I'm only referring to files here,  not databases.

Now from whats been written above it would seem possible to be able to restore the VM + the DB in case of disaster. But what do you do when there is no disaster??? Do still recover the whole server just because a single database (could be one of many) has experienced an issue? Doesn't make sense to me.

So what you would/should be doing is using the client inside the vm, and backing up using the agent. This way you can restore individual components as and when necessary without having to rollback the entire server.

If one day the server does crash, or the site expires, you can try and recover the whole thing in one go using just the VM backup. If it works, great, if it doesn't, use your agent backups that you've been doing everyday.

So the point you have to see here is that even though it might be possible to protect the DB using the VM backup, you wont be able to restore just the DB using that backup. Granularity like that doesn't exist at the moment.... As far I know.

[Rizwan_Ahmed_1]

You are absolutely right about this.

And thanks for clearing my doubts.