Solved! Go to Solution.
vcbMounter -h bc.vmware.com -u backup -p XXXXX -a \ipaddr:vm1.vmware.com -r d:\vtl\vm1-backup -t fullvm -L 6
1 snapshot per lun is a good rule of thumb, high activity on that LUN also needs to be assumed (aka, if its an application that writes and reads and locks hundreds of files every second, its one of those times where VCB will not work without the override patch --- again no gaurauntee by Symantec on that one).
We get 100% completion of backups... I am not comfortable with getting less than that. Currently here is my setup:
2 VCB Proxy servers - 1 per Host Group.
Seperate Policies depending on what I need:
VCB_VCBSERVERNAMEHERE_DayTime (Certain applications of ours are HEAVILY loaded at night time... you should always schedule snapshots away from critical points of use per application / per lun.)
VCB_VCBSERVERNAMEHERE_NightTime (same as above but ran at night for day heavy apps)
VCB_VCBSERVERNAMEHERE_ImageOnly (sometimes i have servers that i want to do flash snapshots on that i can't map simply out of the fact that they have 25,000,000 files, i sometimes get 156s on machines that try to map with that high of a file count)
VCB_VCBSERVERNAMEHERE_NTOnly (sometimes i want only specific directories, so i use this option.... nice to be able to do this without a netbackup license)
Inside the configuration, we find the following snapshot settings:
Snapshot Mount Point: E:\mnt (This is a dedicated drive meant only for snapshots, having your snapshot mount point on the vCB proxy server contain other accessed applications can slow down backups as well as cause issues as it needs all the "write" capability it can get.)
Virtual Machine Backup - option 3 (Full-Mapped with NT Incr)
trantype - option 3 (This means that it'll try over SAN first, but if that doesnt work it'll go across network.... this is nice just as a failover option)
VMDKType - option 0.
I currently limit the amount of jobs at a time to 3. Snapshots complete fairly fast so this is do-able. Symantec supports as a best practice the MAXIMUM of 4.
Also remember that the lun that you are writing to on the VCB Proxy needs to be actively responsive with the amount of writes/reads it needs to perform- i don't recommend sharing with anything else if you can.
Some Important items to note:
1. If you have regular backups running during the time of the snapshot that affects that lun, you can potentially see a 156 snapshot error from the timeout with the lun.
2. Do not attempt to do backups of anything with databases.... not only could it cause a crash on your VM, but the data is useless unless everything is stopped.
3. Be ameable to the size of your disks - remember snapshots have to copy the entire VMDK filesystem down to your proxy.... If you're attempting 2 TB of data, it WILL take awhile.
4. It is important for a quality VCB server - don't run as a VM.................... and don't find the latest trashed piece of hardware you could find otherwise.
5. Test different scenarios with your 156's. Does it work if you run it by itself? Does it run more efficiently at one time of day than another?
6. If a snapshot already exists on the VCB server and was not cleaned up that has the same name of the server, i've also seen 156's generated.
Also, attempt to do the same thing with the VCB Proxy only - if you remove the netbackup software out of the scenario and it still fails, then its something to bring to VMWare. Commandline information on how to do this is readily available on the net.