Symantec Corp.'s Backup Exec is a popular data backup program for desktop and networked storage systems. However, as with any software, there are things that can be set incorrectly or things that can go wrong that will slow performance. In the case of a backup program, a slipup can significantly increase the time it takes to complete your backup jobs. If you're using Backup Exec and your performance isn't what it should be, some troubleshooting may be in order. Here's a list of potential things to look out for.
Get a baseline: Look at old backup logs
Start by looking at your old backup job logs and note both the total time required to back up, the size of the backups, and the overall speed. (Go to the "job monitor" tab in Backup Exec and select "job history.") Compare this to the current speed and total time it takes to complete the job. If there's a significant slowdown, you'll need to look more closely for possible causes.
Break the process down and examine the speed of each disk or agent being backed up. To do this, set up separate jobs for each disk or agent being backed up and back them up separately. If one disk or agent seems unusually slow, drill down to determine the cause by examining the job in detail.
Check that the data is not being redirected elsewhere. Some file systems allow a directory to include data from a file on another server in the backup. This can slow down the entire backup process.
If you are backing up over a network, you can test the system throughput by comparing the Backup Exec logs with the logs of Windows backup (NTBackup) If the Backup Exec logs reflect a lot of conditions that don't show up in the NTBackup logs, further analysis is called for. If remote backups aren't working, try backing up from one drive to another on the remote server. Compare the logs of the Backup Exec backup and the Windows backup. (This assumes you're examining a drive rather than an agent for a program like Microsoft Exchange.)
Check for disk fragmentation
You should also check that there aren't a lot of small files or directories on the disk. This will slow down backups in much the same way fragmentation does by requiring a lot of reads to get the information off the disk for backup.
Disk fragmentation can slow performance of Backup Exec significantly. Check to see how fragmented your disks are and defragment if necessary.
Turn compression on
Tell the Backup Exec to compress any files which can be compressed. Some files, like mpegs and jpegs, can't be compressed. If you suspect the problem may be in the compression, try switching from hardware to software compression, or vice versa.
Make sure your backup software isn't getting in the way
Antivirus software can be a particular problem in Backup Exec. Checking every file being backed up for viruses is unnecessary and slows backup performance. For more on the interaction between Backup Exec and Norton Antivirus, see Symantec's Backup Exec Forum. Also, the newer versions of Backup Exec have a feature called Tamper Protection that can cause problems with antivirus software.
Tape backup with Backup Exec
If you're backing up to tape, power cycle the tape drive or library and the server. This should clear up temporary problems. This re-initializes the tape system and resets the tape system's state. This may remedy everything from a problem caused by a power glitch to some incorrectly set parameters.
The SCSI part (controllers, cables, terminators, etc.) of your backup system can sap performance if the parameters are set incorrectly when backing up to tape. Check the documentation and compare the values there with your settings. The verify option should give you a good overall picture of the condition of the SCSI system. They can do the same thing when backing up to disk, but because of the random write nature of disk, it doesn't have the problem to the same degree tape does. Tape needs data fed at a nice even speed that matches the speed of the tape unit for best performance. Disk can handle intermittent slowdowns in the data rate better than tape can because it writes randomly.
Use the "verify" option to check the health of the SCSI system
The verify operation is generally limited by the speed of the SCSI system. Check the performance by examining the logs of jobs with verify operations in them. If the verify speeds are low, check the SCSI subsystem for possible bottlenecks.
Make sure your controller is rated for the speed of your tape drive. For example, an LTO-3 tape drive requires a SCSI 320 network. Check that your tape drives are not connected to a SCSI RAID controller.
Among the other possible problems with SCSI are improper cabling, loose or bad termination and incorrect SCSI BIOS settings. Also make sure the "initiate wide negotiation" option is set to "yes" if you are using a 68-pin cable connector to your tape drive.
If you're backing up to disk, test the Backup to Disk (B2D) folder. The B2D folder's main use is to prevent the loss of data if a device fails, but it provides a benchmark for Backup Exec against another device. You need at least 2 Gb of data to allow for caches and such. It tends to eliminate problems with the software and the server being backed up as possible causes. Test the B2D speed by copying at least 2 Gb of data to the B2D disk by dragging and dropping the file(s). Compare that with the speed of backing up the same data. If the speed is about the same, the problem is most likely in the disk subsystem, including the controller.
See Symantec's troubleshooting tip document for further Backup Exec troubleshooting tips.
About this author: Rick Cook specializes in writing about issues related to data storage and data storage management.
