As a Netbackup admin, solving other problems may not be a stranger to you. Most seen is very bad backup performance. This article describe the test tool i use in my day to day work.
vxbench
A utility created by Symantec (previous Veritas). It’s splendid tool for finding bad disk performance, read or write. Works best on VXFS file system (obvious). Vxbench has different workload built in (seq read/write – random read/write) and you can specify block size as well. I always check new disk storage unit with vxbench before putting them in production. Vxbench is available for Solaris, AI, HP-UX and Linux – The package is called VRTSspt and can be downloaded from Symantec site.
Examples:
vxbench -w write -i iosize=128,iocount=262144 /diskstu4/dsu/testfile1
output:
total: 111.531 sec 300852.32 KB/s cpu: 48.65 sys 0.04 user
You can get VRTSspt package from here: http://www.symantec.com/docs/TECH27451
tcpdump
Whenever a firewall closes inn on you, tcpdump is you’re find. You don’t need to understand all the stuff, it’s reasonable easy to see connections in and out.
Netbackup only uses port 1556 and 13724 (for backward compatibility)
Here is a list of my most often used tcpdump commands. I always use the following arguments
-i To specify what interface to listen to e.g. eth6
-f Causes tcpdump to print internet addresses in numerical notation
-n Prevent service port to get translated into names (prints 1556 instead of VRTSpbx).
Listen for traffic for a entire network
# tcpdump -n -f -i eth6 net 10.10.10.0/24
Listen for traffic for just one host
# tcpdump -n -f -i eth6 host 10.1.1.1
Or just one service port.
# tcpdump -n -f -i eth2 port ssh
# You can also trace traffic for two host on a IP only layer.
tcpdump -n -f -i eth1 ip host 10.224.13.1 or 10.224.13.2
Listen for traffic but don’t clutter the picture with your’e own SSH traffic
# tcpdump -n -f -i eth5 ip and not port 22
Using Netbackup bpbkar as test tool
You can run bpbkar (the process responsible for reading from disk) by hand to see how performance is when network/tape drive layer is cut off. When issuing bpbkar by hand data is read from disk and thrown in the bit bucket. This will enable the admin to find out whether the problem is on the client side or server side.
# Windows
[INSTALL_PATH]\NetBackup\bin\bpbkar32.exe -nocont D:\ 1> nul 2> nul
# Unix
/usr/openv/netbackup/bin/bpbkar -nocont -nofileinfo -nokeepalives /var > /dev/null 2> /tmp/file.out
Make sure you have created the bpbkar debug directory in [INSTALL_PATH]\NetBackup\logs before starting. Command is return immediately, but the process will be visible in task manager, and the debug log will grow in size as well.
if running bpbkar manual takes the same time as a “real” backup to tape or disk you know the problem is on the client.
if bpbkar run by hand takes the same amount of time as a real backup, you know the problem is on the client and know where to chase the next bottleneck.
nbpercheck
Netbackup has a disk performance test tool included.
The tool is describe in this tech note:
http://www.symantec.com/docs/HOWTO94369