Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  3. NetBackup™ Backup Planning and Performance Tuning Guide
  5. Tuning the NetBackup data transfer path
  7. NetBackup server performance in the data transfer path
  9. Other NetBackup restore performance issues
NetBackup™ Backup Planning and Performance Tuning Guide

Other NetBackup restore performance issues

Table: Issues that affect NetBackup restore performance

Restore issues

Comments

NetBackup catalog performance

The disk subsystem where the NetBackup catalog resides has a large effect on the overall performance of NetBackup. To improve restore performance, configure this subsystem for fast reads. NetBackup binary catalog format provides scalable and fast catalog access.

See About the primary server NetBackup catalog.

NUMBER_DATA_BUFFERS_ RESTORE setting

This parameter can help keep other NetBackup processes busy while a multiplexed tape is positioned during a restore. An increase in this value causes NetBackup buffers to occupy more physical RAM. This parameter only applies to multiplexed restores.

Index performance issues

Refer to Indexing the Catalog for Faster Access to Backups in the NetBackup Administrator's Guide, Volume I.

Multiplexing set too high

If multiplexing is too high, needless tape searching may occur. The ideal setting is the minimum needed to stream the drives.

Restores from multiplexed database backups

NetBackup can run several restores at the same time from a single multiplexed tape, by means of the MPX_RESTORE_DELAY option. This option specifies how long in seconds the server waits for additional restore requests of files or raw partitions that are in a set of multiplexed images on the same tape. The restore requests received within this period are executed simultaneously. By default, the delay is 30 seconds.

This option may be useful if multiple stripes from a large database backup are multiplexed together on the same tape. If the MPX_RESTORE_DELAY option is changed, you do not need to stop and restart the NetBackup processes for the change to take effect.

When the request daemon on the primary server (bprd) receives the first stream of a multiplexed restore request, it triggers the MPX_RESTORE_DELAY timer. The timer starts counting the configured amount of time. bprd watches and waits for related multiplexed jobs from the same client before it starts the overall job. If another associated stream is received within the time-out period, it is added to the total job: the timer is reset to the MPX_RESTORE_DELAY period. When the time-out has been reached without bprd receiving an additional stream, the time-out window closes. All associated restore requests are sent to bptm. A tape is mounted. If any associated restore requests arrive, they are queued until the tape that is now "In Use" is returned to an idle state.

If MPX_RESTORE_DELAY is not high enough, NetBackup may need to mount and read the tape multiple times to collect all header information for the restore. Ideally, NetBackup would read a multiplexed tape and collect all the required header information with a single pass of the tape. A single pass minimizes the restore time.

See Example of restore from multiplexed database backup (Oracle).

More Information

About shared memory (number and size of data buffers)

Feedback

Was this page helpful?
Previous

Fragmentation and checkpoint restart

Next

Example of restore from multiplexed database backup (Oracle)

Feedback

Was this page helpful?