Troubleshooting backup performance

Last published : Apr 02, 2026
You can perform several steps to identify the causes of any Backup Exec job performance issues that you encounter. This section examines performance troubleshooting for the following job types:
  • Local backup to disk
  • Remote Backup to disk
  • Local backup to tape
  • Remote Backup to tape
Local backup to disk
  1. Get a baseline. Review previous jobs in the Job History window of the Job Monitor tab. Note both the speed of previous jobs and the overall duration of these backups. Observe the total time that jobs take to complete, rather than the actual byte count rates. If current jobs take longer to complete than previous jobs, or do not meet speed expectations, continue troubleshooting.
  2. Narrow down the problem. If the backup job includes multiple drives or agents, split the job up into separate jobs for each of those drives and agents. You can then review the performance of each drive or agent separately. To split up a backup job, click on the Backup Exec button, select the C$ drive, schedule the job, and click Submit. If performance is slow only for a particular job, continue troubleshooting that job.
  3. If a particular job still shows slow performance, split the job again to further determine which part of the data most affects the job's performance.
A section of data with many small files and directories will negatively impact performance. This performance impact is normal behavior.
Check whether the data is redirected somewhere else. Some file systems allow a directory to remotely mount data. The files in these directories can be located on remote servers, which may degrade performance for the entire backup.
  1. Test backup-to-disk (B2D) throughput. Use Windows to copy at least 2 GB of data in the backup job to the B2D disk. Compare the performance of the Windows copy to the performance of the backup. If the performances of both are comparable, the performance bottleneck is likely in the disk subsystem in which the B2D folders reside. Move the B2D folders to a faster disk subsystem, or continue troubleshooting.
  2. Test system throughput. If your job is file-based, instead of based on an Exchange, SQL, or other type of database backup, create a similar backup in NTBackup (Windows Backup) and perform a backup to disk. Compare the performance of the NTBackup job to the performance of the Backup Exec job.
If you need to back up an Exchange, SQL, or other database, create a backup-to-disk job in Backup Exec that backs up 2 GB of data to wherever that database agent resides. Perform the same test with NTBackup. Compare the performance of both backups. If performance rates are similar, then Backup Exec is performing at the capacity of the system.
Remote backup to disk
  1. Get a baseline. Review previous jobs in the Job History window of the Job Monitor tab. Note both the speed of previous jobs and the overall time that is required for these backups. Observe the total time that jobs take to complete, rather than the actual byte count rates. If current jobs take longer to complete than previous jobs, or do not meet speed expectations, continue troubleshooting.
  2. Narrow down the problem. If your job includes multiple drives or agents, split the job up into separate jobs for each of those drives and agents. You can then review the performance of each drive or agent separately. To split up a backup job, click on the Backup Exec button, select the C$ drive, schedule the job, and click Submit. If performance is slow only for a particular job, continue troubleshooting that job.
  3. If a particular job still shows slow performance, split the job again to further determine if any particular part of the data affects performance. A section of data with many small files and directories negatively affects performance. This performance impact is normal behavior.
Check whether the data is redirected somewhere else. Some file systems allow a directory to remotely mount data. The files in these directories can be located on remote servers, which may degrade performance for the entire backup.
  1. Test network throughput. Copy between 500 MB and 1 GB of data from the backup server to the remote server. Note how long the copy operation takes to complete. You can perform this copy by creating a path to another server. In the Windows command line, type <\\remote servername\c$>. When the drive is displayed, copy the data.
Follow this same procedure to copy data from the remote server to the backup server, and note how long the operation takes to complete.
Compare the speed of both of these network tests with Backup Exec's performance. If Backup Exec performance is slower than the file copy tests, the network is likely not the bottleneck.
If the network is not the bottleneck, consider performing the same test to a different remote server, or between two different servers. This can help determine if the performance issue is associated with the network in general, or a particular server on the network. If you do not find any network performance issues, continue to the next step.
  1. Test system throughput. Try to back up the remote server with NTBackup (Windows backup). If the remote server is not visible in NTBackup, create a mapped drive to the server's drive and try to back up at least 2 GB of data. Compare the NTBackup logs to the Backup Exec logs and identify any performance differences.
Local backup to tape
  1. Get a baseline. Review previous jobs in the Job History window of the Job Monitor tab. Note both the speed of previous jobs and the overall duration of these backups. Observe the total time that jobs take to complete, rather than the actual byte count rates. If current jobs take longer to complete than previous jobs, or do not meet speed expectations, continue troubleshooting.
  2. Clear any temporary hardware glitches. Turn off the power to the server, tape drive, or tape library, then turn it on again. Turn off the backup server first, then the tape drive or library. Wait a few seconds, then turn on the tape drive or tape library. When the tape drive or tape library is ready, turn on the server. Run the backup job again and examine its performance. If the performance issue persists, continue troubleshooting.
  3. Check the SCSI subsystem. Slow performance can be caused by the disk drive, the tape drive, the disk controller, the SCSI bus, or improper cabling or termination. Ensure that the following are true:
    • The controller is rated for the tape backup hardware.
    • The SCSI BIOS Settings are set properly.
    • Initiate Wide Negotiation is set to Yes when the tape device is connected to a 68-pin-wide SCSI Cable Connector.
    • Tape drives are not connected to a SCSI Raid Controller.
The performance of the verify operation shows the health of the SCSI subsystem. Because the verify operation only reads data and performs in-memory operations on the media server, the speed of the SCSI subsystem limits the verify operation's performance. You can examine the performance of the verify operation by examining the job logs of any jobs which include a verify operation. If the verify speeds are slow, the SCSI subsystem is likely the performance bottleneck.
  1. Split the job up into smaller jobs to identify which agents or features might affect performance. If any of the smaller jobs show performance issues, continue troubleshooting that job.
  2. If a particular job still shows slow performance, split the job again to further determine if any particular part of the data negatively affects performance. A section of data with many small files and directories negatively affects performance. This performance impact is normal behavior.
Determine whether the data is redirected somewhere else. Some file systems allow a directory to remotely mount data. The files in these directories can be located on remote servers, which may degrade performance for the entire backup.
  1. Test system throughput. Try to back up the remote server with NTBackup (Windows backup). If the remote server is not visible in NTBackup, create a mapped drive to the server's drive and try to back up at least 2 GB of data. Compare the NTBackup logs to the Backup Exec logs and identify any performance differences.
  2. Successful compression can increase the tape drive's data transfer rate to twice the native rate. Compression performance can be highly variable depending on the input data. Image files can compress at a ratio of 4.5:1 or more. Binary files may compress at only a 1.5:1 ratio. Data that has already been compressed or encrypted may expand by about five percent if you attempt to compress it further. This expansion can reduce drive throughput.
If hardware or software compression does not perform as expected, switch to the other type of compression. You can switch compression types by editing the backup job properties, clicking on General under Settings, then selecting a different type of compression under the Compression Type menu.
Remote backup to tape
  1. Perform any of the troubleshooting steps for Local backup to tape given above. You can also perform the following steps.
  2. Test network throughput. Copy between 500 MB and 1 GB of data from the backup server to the remote server and note the duration of the copy operation. To do this, create a path to another server. In the Windows command line, type <\\remote servername\c$>. When the drive is displayed, copy the data.
Follow this same procedure to copy data from the remote server to the backup server, and note how long the operation takes to complete.
Compare the speed of both of these network tests with Backup Exec's performance. If Backup Exec performance is slower than the file copy tests, the network is likely not the bottleneck.
If the network is not the bottleneck, you can perform the same test to a different remote server, or between two different servers. This may help you determine if the performance issue is associated with the network in general, or with a particular server on the network. If you do not find any network performance issues, continue to the next step.
  1. Test system throughput. Try to back up the remote server with NTBackup (Windows backup). If the remote server is not visible in NTBackup, create a mapped drive to the server's drive and try to back up at least 2 GB of data. Compare the NTBackup logs to the Backup Exec logs and identify any performance differences.
    Note: If remote backups are not possible with NTBackup, open NTBackup locally on the remote server and run a local backup job there. Use Backup Exec to back up the same data to disk, and compare the performance of both backups. In most cases, Backup Exec jobs which back up to disk run faster than those that back up to tape.
Related information