NetBackup™ Backup Planning and Performance Tuning Guide
- NetBackup capacity planning
- Primary server configuration guidelines
- Media server configuration guidelines
- NetBackup hardware design and tuning considerations
- About NetBackup Media Server Deduplication (MSDP)
- MSDP tuning considerations
- MSDP sizing considerations
- Accelerator performance considerations
- Media configuration guidelines
- How to identify performance bottlenecks
- Best practices
- Best practices: NetBackup AdvancedDisk
- Best practices: NetBackup tape drive cleaning
- Best practices: Universal shares
- NetBackup for VMware sizing and best practices
- Best practices: Storage lifecycle policies (SLPs)
- Measuring Performance
- Table of NetBackup All Log Entries report
- Evaluating system components
- Tuning the NetBackup data transfer path
- NetBackup network performance in the data transfer path
- NetBackup server performance in the data transfer path
- About shared memory (number and size of data buffers)
- About the communication between NetBackup client and media server
- Effect of fragment size on NetBackup restores
- Other NetBackup restore performance issues
- About shared memory (number and size of data buffers)
- Tuning other NetBackup components
- How to improve NetBackup resource allocation
- How to improve FlashBackup performance
- Tuning disk I/O performance
Note on log file creation
When you run multiple tests, you can rename the current log file. Renaming the file causes NetBackup to create a new log file, which prevents you from erroneously reading the wrong set of values.
Deleting the debug log file does not stop NetBackup from generating the debug logs. You must delete the entire directory. For example, to stop bptm from logging, you must delete the bptm subdirectory. NetBackup automatically generates debug logs at the specified verbose setting whenever the directory is detected.
Use care when manipulating the bptm log files if the backup or restore is part of a multiplex (MPX) group that includes unrelated operations. In those instances, the bptm parent process opens the log file once at startup and receives a file descriptor from the operating system. The parent process and child processes write to that file descriptor until all current (and future) jobs that join the MPX group have completed. Unexpected consequences may result if the log file is renamed or deleted while the MPX group is still active.
If the log file is renamed, the file descriptor remains open against the renamed file. And if the next test job joins the same MPX group the new log entries appear in the renamed log file. If the log file is deleted, the file is no longer visible in the directory but the file descriptor remains open. If the next test job joins the same MPX group, the new log entries are written to the open file. Note that the user can no longer access the open file.
This behavior also applies to the MPX groups that have been running for multiple days. If the test job joins an MPX group that became active two days ago, the log entries are in the log from two days ago. If the bptm log directory did not exist two days ago, the bptm processes handling the backup do not generate any log entries.
If the bptm log directory did not exist two days ago, do one of the following:
Wait for the MPX group to complete before starting the test job.
Change either the storage unit, volume pool, or retention for the backup. The job is assigned to a drive and to media that is not already in use, and a new bptm parent process is started.