I would seriously consider you update to NetBackup 6.5.2, out on 9th June 2008. There are a number of fixes for VCB and better implementation within the policy to visibly choose you storage transfer type, and also to choose whether an optimized vmdk file or not is used, also there is a new type of Virtual Machine backup introduced in 6.5.2:
type 3-FullVM and file for incremental: A combination of options 2 and 0.
6.5.2 has fixed a number of errrors/issues I had under 6.5.1:-
Error#1 VM backup method type 2-Mapped FullVM, backup detail status reported:
Error bpbrm(pid=4380) from client barney.bedrock.org: ERR - Unable to retrieve volumes from virtual machine, error = 2059
Error#2 VM backup method type 0-File Level
Error bpbrm(pid=1796) from client barney.bedrock.org: ERR - Unable to add to excluded file list error = 11
Issue #1 Although errors above appeared backup completed Status 0, but could not restore.
requested restore job and backup tape mounted and just hung, had to cancel.
Furthermore my VCB proxy/Media Server was Windows 2003 R2 Standard Edition 64BIT (Service Pack2).
So 2003 R2 works and using 64BIT
Here are some snippets from the ETRACK document for 6.5.2 specific to VCB
Etrack Incident = ET1187873
Description:
VMware fullvm backups would not have an incremental capability. For Windows
clients, where a file-level snapshot could be used for incremental backups,
there is now a capability to specify that a fullvm snapshot is used for full
schedules and a file-level snapshot for incremental backups.
Etrack Incident = ET1232059
Description:
VMware backups were not looking in the correct location for VCB installed
components on Windows X64 platforms.
[The VCB framework installer placed components in Program Files (x86) but then had to be moved to Program Files]
Etrack Incident = ET1232066
Description:
A media server must be licensed to backup remote clients to be used for a
Vmware backup. A SAN media server should not be used.
[This might explain the type of license needed, as we needed a TIER 3 type license for it to work.]
Etrack Incident = ET1186143
Description:
The VMware full VM restore now has the ability to control an identity
restore and strip all network information from a restored VM.
The script provided by VMware to complete the restore of a virtual
machine to the ESX server has command line options to force an identity
restore, and to strip all network information form the restored VM. The
user interface now enables you to control these options and to pass them
on in the flags for the restore.
Etrack Incident = ET1187875
Description:
VMware Windows backups can now do a file-level snapshot for incremental
backups and a fullvm snapshot for full backups.
Etrack Incident = ET1214026
Associated Primary Etrack = ET1207687
Titan cases: 290-944-881 311-813-162
Description:
VMware FullVM and Mapped FullVM backups would fail if multiplexing was
turned on. In addition, Snapshot client VMware FIM backups would fail
with with an error code 229 if the VM type is set to FullVM or mapped
FullVM.
[Do not use multiplexing]
Etrack Incident = ET1250942
Description:
The mount point that was being passed on the backup x using y command line
was causing bpbkar32 to attempt to get a lock on the volume. This caused
the VMWare backups to fail in many cases.
Message Edited by Stuart Green on
06-12-2008 08:22 AM
