Other NetBackup restore performance issues — NetBackup 10.3 | Cohesity Documentation

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

Other NetBackup restore performance issues — NetBackup 10.3 | Cohesity Documentation

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?

Feedback

Was this page helpful?