Highlighted

NetBackup Volume Level Snapshot based backup using VMware?

Currently I have configured my VMware environment to snapshot virtual machines successfully.  However, there are some cases where I would like to snapshot at volume level (i.e snapshot the C: drive only).  Is this possible in NetBackup 7.5 and onwards.

I think I know the answer to this, but confirmation would be nice along with any suggestions on how I can get a volume level snapshot only.

Thanks.

1 Solution

Accepted Solutions
Highlighted
Accepted Solution!

Hi, In one particular case of

Hi,

In one particular case of mine there was a way to have the VMDK disk mode set to independant - persistent, and this made the drive not be included in the backup.

 

But this will exclude everything in this VMDK i.e. if you built a Windows VM with C: & D: in the beginning and wanted to exclude just the D: then this would not be possible as these drives would be in the same VMDK.

 

You would need to build a VM with just C: and then add the D: and set the disk mode to Independat - persistent.

Here's the guide to set the mode: https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc_50%2FGUID-E1D5...

I have no idea if symantec support this and what the consiquenses are for using this method. You would need to test this.

Hope this helps

View solution in original post

6 Replies
Highlighted

My question : Can you do that

My question : Can you do that using vSphere Client GUI? I guess the answer is NO, right?
Highlighted

Marianne, Thanks for

Marianne,

 

Thanks for pointer.  I have just sat down wioth our VMware guys and discussed this further and found some interesting bits on the VMware site.  You're correct in that we can't seperate the snapshots at volume level.  However, for extra info, it can be done if the vm disks we didn't want snapshotted, if that's a word, are configured as independant consistent volumes.  The down side to that is the virtual machine needs to be offline to accomplish this using VMware 5.

 

Thanks for help.

Highlighted
Accepted Solution!

Hi, In one particular case of

Hi,

In one particular case of mine there was a way to have the VMDK disk mode set to independant - persistent, and this made the drive not be included in the backup.

 

But this will exclude everything in this VMDK i.e. if you built a Windows VM with C: & D: in the beginning and wanted to exclude just the D: then this would not be possible as these drives would be in the same VMDK.

 

You would need to build a VM with just C: and then add the D: and set the disk mode to Independat - persistent.

Here's the guide to set the mode: https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.vm_admin.doc_50%2FGUID-E1D5...

I have no idea if symantec support this and what the consiquenses are for using this method. You would need to test this.

Hope this helps

View solution in original post

Daniel, Good info thanks. 

Daniel,

 

Good info thanks.  The more I look into this, the more flags are raised.  I think this may be OK for certain scenarios, but If I add more info to my issue, you may see why it wouldn't work.

Because we want to backup SQL as well, we can pnly backup FULL, because NBU does not understand the incremental data in relation to a SQL db when it comes to restore.  So if I didn't snapshot the SQL drive(vmdk), then when it comes to the rebuild of a server, there will be no folder structure with correct permissions to recover any database to, so there would have to be manual intervention to rebuild the SQL drive from scratch, if that makes sense.

Thanks.

Highlighted

Aha, Yes this is a common

Aha,

 

Yes this is a common thing though have you not looked into VMware backup with SQL protection configured + VMware accelerated backups? This would pretty much be like an incremental backup and you can configure it to delete the transaction logs after the full backup is complete

That way you are covered.

The alternative is to get your SQL DBA's to configure their own SQL dumps of the databases. Then if the original database gets corrupted they can use the dump and longer term retention, rely on your backup of the dump. I know its rather crude this way but some DBA's prefer this rather than raising tickets to a helpdesk for you to do restore.

Cheers

 

Highlighted

Daniel, A couple of options

Daniel,

A couple of options there which I'd thought of, but current infrastructure won't allow.  Dedupe, Accelerator and all that nice stuff is out of reach at the moment, so it's looking like standard backups as if they were physical or else I need to look at lots of disk space if I do a full snap every day for SQL.

Again, thanks for suggestions.  This is my first post and impressed at the speed of response from people.

Thanks.

 

Geoff.