NetBackup™ Backup Planning and Performance Tuning Guide
- NetBackup capacity planning
- Primary server configuration guidelines
- Size guidance for the NetBackup primary server and domain
- Factors that limit job scheduling
- More than one backup job per second
- Stagger the submission of jobs for better load distribution
- NetBackup job delays
- Selection of storage units: performance considerations
- About file system capacity and NetBackup performance
- About the primary server NetBackup catalog
- Guidelines for managing the primary server NetBackup catalog
- Adjusting the batch size for sending metadata to the NetBackup catalog
- Methods for managing the catalog size
- Performance guidelines for NetBackup policies
- Legacy error log fields
- Media server configuration guidelines
- NetBackup hardware design and tuning considerations
- About NetBackup Media Server Deduplication (MSDP)
- Data segmentation
- Fingerprint lookup for deduplication
- Predictive and sampling cache scheme
- Data store
- Space reclamation
- System resource usage and tuning considerations
- Memory considerations
- I/O considerations
- Network considerations
- CPU considerations
- OS tuning considerations
- MSDP tuning considerations
- MSDP sizing considerations
- Cloud tier sizing and performance
- Accelerator performance considerations
- Media configuration guidelines
- About dedicated versus shared backup environments
- Suggestions for NetBackup media pools
- Disk versus tape: performance considerations
- NetBackup media not available
- About the threshold for media errors
- Adjusting the media_error_threshold
- About tape I/O error handling
- About NetBackup media manager tape drive selection
- How to identify performance bottlenecks
- Best practices
- Best practices: NetBackup SAN Client
- Best practices: NetBackup AdvancedDisk
- Best practices: Disk pool configuration - setting concurrent jobs and maximum I/O streams
- Best practices: About disk staging and NetBackup performance
- Best practices: Supported tape drive technologies for NetBackup
- Best practices: NetBackup tape drive cleaning
- Best practices: NetBackup data recovery methods
- Best practices: Suggestions for disaster recovery planning
- Best practices: NetBackup naming conventions
- Best practices: NetBackup duplication
- Best practices: NetBackup deduplication
- Best practices: Universal shares
- NetBackup for VMware sizing and best practices
- Best practices: Storage lifecycle policies (SLPs)
- Best practices: NetBackup NAS-Data-Protection (D-NAS)
- Best practices: NetBackup for Nutanix AHV
- Best practices: NetBackup Sybase database
- Best practices: Avoiding media server resource bottlenecks with Oracle VLDB backups
- Best practices: Avoiding media server resource bottlenecks with MSDPLB+ prefix policy
- Best practices: Cloud deployment considerations
- Measuring Performance
- Measuring NetBackup performance: overview
- How to control system variables for consistent testing conditions
- Running a performance test without interference from other jobs
- About evaluating NetBackup performance
- Evaluating NetBackup performance through the Activity Monitor
- Evaluating NetBackup performance through the All Log Entries report
- Table of NetBackup All Log Entries report
- Evaluating system components
- About measuring performance independent of tape or disk output
- Measuring performance with bpbkar
- Bypassing disk performance with the SKIP_DISK_WRITES touch file
- Measuring performance with the GEN_DATA directive (Linux/UNIX)
- Monitoring Linux/UNIX CPU load
- Monitoring Linux/UNIX memory use
- Monitoring Linux/UNIX disk load
- Monitoring Linux/UNIX network traffic
- Monitoring Linux/Unix system resource usage with dstat
- About the Windows Performance Monitor
- Monitoring Windows CPU load
- Monitoring Windows memory use
- Monitoring Windows disk load
- Increasing disk performance
- Tuning the NetBackup data transfer path
- About the NetBackup data transfer path
- About tuning the data transfer path
- Tuning suggestions for the NetBackup data transfer path
- NetBackup client performance in the 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)
- Default number of shared data buffers
- Default size of shared data buffers
- Amount of shared memory required by NetBackup
- How to change the number of shared data buffers
- Notes on number data buffers files
- How to change the size of shared data buffers
- Notes on size data buffer files
- Size values for shared data buffers
- Note on shared memory and NetBackup for NDMP
- Recommended shared memory settings
- Recommended number of data buffers for SAN Client and FT media server
- Testing changes made to shared memory
- About NetBackup wait and delay counters
- Changing parent and child delay values for NetBackup
- About the communication between NetBackup client and media server
- Processes used in NetBackup client-server communication
- Roles of processes during backup and restore
- Finding wait and delay counter values
- Note on log file creation
- About tunable parameters reported in the bptm log
- Example of using wait and delay counter values
- Issues uncovered by wait and delay counter values
- Estimating the effect of multiple copies on backup performance
- Effect of fragment size on NetBackup restores
- Other NetBackup restore performance issues
- About shared memory (number and size of data buffers)
- NetBackup storage device performance in the data transfer path
- Tuning other NetBackup components
- When to use multiplexing and multiple data streams
- Effects of multiplexing and multistreaming on backup and restore
- How to improve NetBackup resource allocation
- Encryption and NetBackup performance
- Compression and NetBackup performance
- How to enable NetBackup compression
- Effect of encryption plus compression on NetBackup performance
- Information on NetBackup Java performance improvements
- Information on NetBackup Vault
- Fast recovery with Bare Metal Restore
- How to improve performance when backing up many small files
- How to improve FlashBackup performance
- Veritas NetBackup OpsCenter
- Tuning disk I/O performance
Methods for managing the catalog size
To manage the catalog size, consider the following:
Why are long-running catalog backups an issue?
Leverage Differential/Incremental Backups
Enable Catalog Compression
In general, large catalogs are the result of long-term retention (LTR) requirements or data sets with large numbers of files. (Typically, NAS filers can have millions of files.) The combination of these two situations can increase the catalog size requirements significantly. Preplanning and creating multiple NetBackup domains in such situations may be an option in very large environments.
However, defining a domain based upon retention is not a common practice. Clients with large NetBackup environments often plan their domains based upon the workload type groupings rather than upon LTR. Additionally, more backups with LTR are being directed to Access or Cloud S3.
NetBackup has no hard limit on catalog size. However, Veritas recommends as a best practice that you keep the catalog size under 4 TB to ensure good catalog backup and recovery performance. Depending on the size of the environment and the length of backup image retention, catalogs may grow in excess of 4 TB. This size is not an issue for NetBackup, but it can result in operational issues for the environment regarding the time it takes to perform catalog backups and recoveries. This directly impacts the ability to recover the environment in the event of a disaster.
Several methods can be implemented to help mitigate this issue:
Move the catalog to flash storage.
Implement incremental or differential schedules for daily backups. This approach can reduce the time required to perform these backups. It can however negatively affect catalog recovery times, and regular full backups are still recommended.
Implement database compression. This method shrinks the size of the catalog and improves performance of catalog backups.
Implement catalog archiving. This method shrinks the size of the active catalog, however, it can increase the time that is required to perform restores from archived images.
Create a separate NetBackup domain for long-term retention. In many cases, excessive catalog size is a result of long-term retention of backup images.
If catalog backups do not complete within the desired backup window, consider moving the catalog to higher performance storage. This method most directly improves catalog backup and recovery performance.
Daily differential or incremental backups can be used to ensure that regular catalog protection can be completed within the desired window. For more information on catalog schedules, refer to the NetBackup Administrator's Guide, Volume I.
If catalog backups do not complete within the desired backup window, consider the use of catalog archiving.
Catalog archiving reduces the size of online catalog data by relocating the large catalog files to secondary storage. NetBackup administration continues to require regularly scheduled catalog backups, but without the large amount of catalog data, the backups are faster.
For more information on archiving the catalog, refer to the NetBackup Administrator's Guide, Volume I.
When the image database portion of the catalog becomes too large for the available disk space, you can do either of the following:
Compress the image database.
Move the image database.
For details, refer to "About image catalog compression" " and "Moving the image catalog in the NetBackup Administrator's Guide, Volume I.
Note that NetBackup compresses the image database after each backup session, regardless of whether any backups were successful. The compression happens immediately before the execution of the session_notify script and the backup of the image database. The actual backup session is extended until compression is complete. Compression is CPU-intensive. Make sure that primary server has enough free CPU cycles to handle the compression.
Long-term retention (LTR) of backup data for multiple years can result in very large catalogs. One method to reduce the effect of LTR is to use NetBackup replication and perform LTR in a separate dedicate domain. This method has the advantage of keeping the catalog for the primary production domain more manageable in size. The catalog in the LTR domain can still become large, however, this problem is of lesser operational effect because rapid recovery of LTR data is generally not required.