In March, 2009, Symantec provided a security update to NetBackup. Reportedly, this update fixes a vulnerability with vnetd and also addresses issues with calendar based scheduling and DST. The entire bulletin describing the fixes and known issues can be found here.

The 6.5.3.1 binaries can be downloaded from the6.5.3.1 download page.

In NetBackup 6.x, the Resource Broker (nbrb) handles assignment of resources. A known bug exists, which was supposed to be fixed in 6.5.1, where media would not have this assignment released. Most times this is noticed during a restore when a particular tape is required, yet the restore details state that it is waiting on the media. To resolve this, do the following:

1. Verify NBU inventory and library inventory are synced
2. Verify NBU inventory shows tape as in library
3. Verify tape is not already mounted or stuck in a tape drive via robtest or some other method
4. If the above show the tape is in a normal, expected state, continue below; otherwise, resolve the issues above and retry the job
5. Note: running these commands will cancel any job you have running that is requesting this media; be sure to suspend/cancel them beforehand
6. Run /usr/openv/netbackup/bin/admincmd/nbrbutil -dump | grep <mediaID>
7. If nbrb still has an open assignment for this tape, you will see quite a few lines of information, but look for the line containing “MdsAllocation“
8. Next to this will be a number so that it looks like this: MdsAllocation allocationKey=4838
9. This is the assignment that needs to be released using this command: /usr/openv/netbackup/bin/admincmd/nbrbutil -releaseMDS 4838
10. Run the dump command again (step 6) to verify the assignment has been released from the tape
11. Resume/restart the job

NetBackup 6.5.4 is estimated to be released early June.

I was recently expiring some images that had failed to be expired on their own (due to the known bug in 6.5 that won’t expire old 5.1 images from disk) and it reminded me how very important it is to do your homework when taking drastic steps such as this. As we all know, once you use bpexpdate to get rid of an image, the only way to get it back is to import the tape(s). Before expiring those images, even if it is just one, use bpimmedia and bpimagelist to document what the images are and where they reside.

I find with this, as with most things, the old Murphy’s Law addage applies: If you don’t do the research and documentation, you’ll get burned; if you take care of it, then you will be in good shape (and if you aren’t, you have the necessary history to recover).

If your 6.x Java Admin Console GUI hangs when selecting Client Properties, never fear, you are NOT losing your mind! Symantec, in their infinite wisdom, decided that the GUI would most likely be used on a server in the local subnet of every client AND the user would want all the client properties info cached. Riiiiiiggghhht. Anyway, here’s how you turn off caching and save your sanity:

1. Close any open 6.x java consoles
2. Locate the Java admin console config file on the host where you are running the client from (typically a Windows workstation):

   1. Windows: <install location>\Veritas\NetBackup\java\setconf.bat
   2. Unix/Linux: /usr/openv/java/nbj.conf
3. Disable FORCE_IPADDR_LOOKUP

   1. add/change this line on Windows: SET FORCE_IPADDR_LOOKUP=0
   2. add/change this line on Unix/Linux: FORCE_IPADDER_LOOKUP=0

   Note: the difference in the spelling of the parameters is correct. Also, no spaces before or after the equal sign and SET is required on Windows.

4. Restart the console and confirm the problem is resolved.

Word on the street is that 6.5.3 will be out in the Fall 2008 time frame.

Update: Since it’s been released, I figured I provide a link to the 6.5.3 download page.

When vault fails to eject tapes, there could be a lock file that was not released. Depending on your configuration, the Vault session may error with a 290, 297, or 306 error code. Here are some steps to troubleshoot and resolve this issue:

1. Verify no vault sessions are running
2. If none running proceed or wait for jobs to complete
3. Empty the CAP if any tapes are present
4. Rename or remove /usr/openv/netbackup/vault/sessions/vlteject.mstr.lock on the Master
5. For ACS robots rename/remove any /usr/openv/volmgr/misc/EJECT_*.txt files on ALL media servers that use this robot
6. Eject tapes for the session(s) by either re-running vault or using vltopmenu to attempt to eject them again

It is important to note that if you have an ACS robot, you should check all media servers that can control the robot.

This blog is related to Veritas/Symantec’s enterprise backup product, NetBackup. Here you will find various tips, thoughts and ramblings related to NetBackup. I hope you’re able to find something useful.