01-28-2016 01:26 PM
01-28-2016 03:04 PM
Unfortunately that isn't possible. AFAIK it is not a NetBackup limitation. I suspect that it is a VMware VADP limitation in the APIs whereby an external third party program is unable to pass a list of file names for VMware to filter out (exclude) the blocks of the VMDK as it works it's magic.
If you think about it, what you're asking for is for the VMware VADP API to effectively implement some alogithms which would be somewhat similar to "accelerator" in so far as matching blocks to file names.
Such a feature would undoubtedly add a fair chunk of CPU, and RAM for hash-table lookups, and so I wouldn't expect to see VMware slug their VMDK driver/handlers. In short... it ain't gonna happen any time soon.
.
If it is a small DB, low intesity, low change rate, then just make sure that your VM backup runs after the MS SQL maintenance plans have run.
If it is a medium/large, and/or IO intensive/volatile VM, then read this:
https://www.veritas.com/community/forums/vm-snapshot-error
...and after you've read it, then maybe also consider backup type D), i.e. leverage NetBackup's integration in to calling a database agent style backup with the VMware backup.
01-28-2016 01:31 PM
How to exclude sql database when backing up through a VMWARE policy
01-28-2016 02:19 PM
Also see the term "ASC" (Application State Capture), here:
Limitations of using a VMware policy to protect SQL Server:
https://www.veritas.com/support/en_US/article.HOWTO85424
.
And see this previous question and solution re VMware integration with SQL:
https://www.veritas.com/community/forums/preferred-backup-method-vms-running-sql-databases
01-28-2016 03:04 PM
Unfortunately that isn't possible. AFAIK it is not a NetBackup limitation. I suspect that it is a VMware VADP limitation in the APIs whereby an external third party program is unable to pass a list of file names for VMware to filter out (exclude) the blocks of the VMDK as it works it's magic.
If you think about it, what you're asking for is for the VMware VADP API to effectively implement some alogithms which would be somewhat similar to "accelerator" in so far as matching blocks to file names.
Such a feature would undoubtedly add a fair chunk of CPU, and RAM for hash-table lookups, and so I wouldn't expect to see VMware slug their VMDK driver/handlers. In short... it ain't gonna happen any time soon.
.
If it is a small DB, low intesity, low change rate, then just make sure that your VM backup runs after the MS SQL maintenance plans have run.
If it is a medium/large, and/or IO intensive/volatile VM, then read this:
https://www.veritas.com/community/forums/vm-snapshot-error
...and after you've read it, then maybe also consider backup type D), i.e. leverage NetBackup's integration in to calling a database agent style backup with the VMware backup.
01-29-2016 04:41 AM
Hello,
imagine that en exclusion like this would be only "logical", not physical. Because VADP backup takes the whole image of VM machine. So the database is always physically included in this backup. "Exclusion" in this case would only mean that NetBackup wont create a reference (mapping) to this database. The size of backup remains the same..
Regards
Michal
01-29-2016 05:39 AM
Hi Penchala !
Like the other said. There is now way to exclude single files.
If it is a MS SQL database you may backup it too by vmware backup.
One chance is: Exclude datadisks from backup. So your VMware Backup will only take the OS Disk (vmdk) and the VM.
But this excludes all vmdks which represents datadisks. Your VM must be splitet in OS Disk( pagefile, swap OS) and datadisk.
ciao
Martin
01-29-2016 05:50 AM
If such a feature were to be implemented by VMware... then one would hope that the blocks wouldn't be read by VADP/VDDK from the VMDK, and so wouldn't be transfered to NetBackup, but then NetBackup would need to be modified to be able to handle all this too. It's all too complicated and would add quite a lot of overhead.
To me such a feature is non-sensical. If one doesn't want one's DB (which is live, open, raw, being writte to, and likely useless when restored) to be included in a VM style backup, and read from storage and transferred to NetBackup, then don't backup using VMware style... or exclude the entire disk/VMDK (which contains the live database files) from your VM style backup.
Remember, even the ASC type of backup of MS SQL will still result in any writes/updates (by MS SQL to its own DB files) being tracked and held in VMware's snapshot "write pending log"... and so this snapshot file has the potential to get very large even when using an ASC featured VM style backup, and all of these pending writes still have to be "rolled in / played back" at the end of the backup when NetBackup tells VMware to delete the snapshot.
01-29-2016 10:20 AM
FYI - a topic related question, here:
https://www.veritas.com/community/forums/are-all-vmdk-still-snapshotted-even-when-excluding-vmdk-vm-style-backup
01-29-2016 10:51 AM
Thanks a lot for expalining this i guess i will have to script the sql databases to exclude few of them.
01-29-2016 12:33 PM
01-29-2016 12:35 PM