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
Cloud tier sizing and performance
Sizing and performance of data in the cloud is based on customer need and will vary from customer to customer, which makes providing exact sizing and performance information difficult.
To get data to the cloud, customers can use a simple internet connection if the data to be transmitted is less than the amount of available bandwidth.
Cloud providers may provide a direct connection service. Customers can get a dedicated link to their cloud provider with performance similar to LAN bandwidth inside a data center. They can compress data at the data center before being sent across the network to the cloud provider or use MSDP Cloud (MSDP-C) to optimize the data being sent before it is stored in the cloud. They can also throttle bandwidth, if desired, to prevent over-saturation of the network pipe.
Public cloud providers use a regional model in which it has configured various regions across the globe. Each region can have zones that are similar to data centers within the region that communicate with each other over high-bandwidth connections. This setup is similar to a customer having multiple physical data centers in a geographical region that are close enough for low-latency connectivity, yet far enough apart to not be affected by the same natural or artificial disaster.
Data within the region will typically stay within the region, but customers have the option to select a geographically dispersed region that is available for regional DR. Data can be replicated between zones to provide high availability within the cloud for the customer's data. The loss of a single zone does not affect the operations of the others. Customers typically choose to operate within the region that is closest to provide optimized bandwidth for moving data in and out of the Cloud and have the option to select a geographically dispersed region to provide regional DR.
One of the many benefits of the cloud storage model is the ability to quickly add storage to environments. Customers don't pay for the storage until it is provisioned. This model is much different from a traditional data center where racks of disks may sit idle until needed, thus increasing total cost of ownership (TCO). If the disk is spinning and generating heat, additional cooling and power could be needed to keep the disk spinning even if it is not currently in use. Although next-generation SSD arrays require less cooling and power, idle disks still increase TCO.
Once data is in the cloud, cloud providers uses various types of storage including block and object storage. Other options include Network-Attached Storage (NAS) services. Sizing of the environment is based on the needs of the customer and the workloads placed in the cloud. Pricing is based on the type of storage chosen and is typically priced per GB. For example, standard object storage typically runs approximately $0.023/GB per month, whereas archive storage currently runs about $0.004/GB per month and even less for archive storage tiers. Cost also depends on the region where the data is stored. (See the cloud provider's price list for current costs.) Archive tiers are typically used as long-term archive storage targets whereby data is moved there automatically using a variety of methods, and a restore from storage could take hours to access versus seconds for a restore from object storage.
The following sample sizing guidelines are based on the assumptions listed and were created using the standard NetBackup Appliance Calculator to determine the storage required for each type of workload. This guideline applies to back up in the cloud workloads only.
The following assumptions were used to size this environment:
Data assumptions:
Data split - 80% FS / 20% DB [ no hypervisor level in the cloud]
Daily retention 2 weeks / weekly - 4 weeks / monthly 3 months
Daily change rate 2%, and year-over-year (YoY) growth 10% [ sizing for 1 year only]
Instance Type workload descriptions:
Small - FETB <=100 TB <= 100 concurrent jobs
Medium - FETB <=500 TB <= 500 concurrent jobs
Large - FETB <=1,000 TB <= 1,000 concurrent jobs
Extra-Large - FETB = 1 PB >1,000 concurrent jobs. For mixed object and block storage, total maximum capacity is 1.2PB
For more information, see About the Media Server Deduplication (MSDP) node cloud tier in the NetBackup Deduplication Guide.
The architecture is based on a single NetBackup domain consisting of a NetBackup primary server and multiple MSDP media servers in the cloud.
Typically, backups are written directly to local MSDP block storage for an immediate copy, then opt-duped to a cloud tier to send deduplicated data to object storage. However, there is no requirement that backups must go to standard MSDP before sending to cloud. If the solution doesn't require MSDP data to be "local" on block storage, then MSDP-C enables backup data to be sent directly to a cloud tier.
With MSDP-C or MSDP in general, data is deduplicated in the plug-in (source side) layer before writing to the storage server. The storage server assembles 64MB containers in memory and writes them to object storage. If the number of streams x 128MB exceeds the memory limits, disk is used as cache to assemble the containers.
Requirements consist of the following:
Data assumptions:
NetBackup primary server
A single NetBackup primary server can be on any supported operating system.
NetBackup MSDP media server's block storage
MSDP media servers receive the initial backups from clients and perform deduplication.
NetBackup MSDP media server's cloud tier
MSDP can have one or more targets on the same storage server that takes the deduplicated backup images from the MSDP media server's block storage and stores them in object storage.
The MSDP cloud tier is dedicated to performing NetBackup deduplication writes to object storage. It is a dedicated high-end Red Hat server that meets the minimum requirements for the MSDP cloud tier. It takes the deduplicated backup images from the MSDP media servers and stores them in object storage.
Backup Workloads (Clients/Agents)
These are the systems or applications that are being protected.
The NetBackup primary server should be sized according to the standard Veritas guidelines depending on the load placed on the complete NetBackup domain. Plan accordingly for the initial needs of the environment. Cloud providers offer the added benefit of being able to scale up the systems as workloads grow. The solution can scale out by adding additional media server nodes.
Primary Server Memory and CPU Requirements
For details about the recommended memory and CPU processor requirements for the various environment sizes:
These estimates are based on the number of media servers and the number of jobs the primary server must support. You may need to increase the amount of RAM and number of processors based on other site-specific factors.
Primary Server Recommendations
Table: Primary server recommendations
Small | Medium | Large | Extra Large |
|---|---|---|---|
32 GiB / 8 vCPU | 64 GiB / 8 vCPU | 64 GiB / 16 vCPU | 128 GiB / 16 vCPU |
Install 500 GB Catalog 5 GB | Install 500 GB Catalog 5 GB | Install 500 GB Catalog 10 GB | Install 500 GB Catalog 10 GB |
NetBackup MSDP storage can reside on either a NetBackup Appliance, a Virtual Appliance or a build-your-own (BYO) virtual or physical host, including a cloud-based virtual instance. This section outlines MSDP in a public cloud Infrastructure-as-a-Service (IaaS) deployment.
The host computer's CPU and memory constrain how many jobs can run concurrently. The storage server requires sufficient capability for deduplication and for storage management. Processors for deduplication should have a high clock rate and high floating-point performance. Furthermore, high throughput per core is desirable. Each backup stream uses a separate core.
Table: Recommended specifications for MSDP media servers
Hardware component | MSDP media server specification |
|---|---|
CPU |
|
RAM |
|
Storage |
|
Operating system |
|
As the amount of data protected by a server increases, the load requirements on that host will increase. In that scenario, there is a simple solution. You can easily expand any virtual instance or add volumes. Refer to your cloud provider's documentation for information about resizing instances and adding storage to them.
Running traditional MSDP in a cloud environment requires specific resources to be available such as a 10G network and volumes with provisioned IOPS. The recommendations below have been formulated using cloud provider kits that address MSDP pools of different sizes. These are just recommendations and specific customer environments may have different needs. Depending on the footprint, any of the environments below would work based on the sizes.
MSDP Considerations
An example MSDP storage pool size is up to 96 TB on Linux:
Can be a direct backup target, use Fingerprinting Media Servers or a client-side deduplication target.
MSDP will be storing all data on managed disks.
The pool will be able to use optimized deduplication or Automated Image Replication (A.I.R.) to send images to any Veritas deduplication-compatible target, including MSDP-C.
Storage considerations
Although multiple deduplication storage servers can exist in a NetBackup domain, storage servers do not share their storage. Each storage server manages its own storage. Deduplication within a storage server is supported, including between different block and cloud Disk Pools. Optimized deduplication is supported between different storage servers in the same primary domain. Automated Image Replication (A.I.R.) is supported for replicating data and image metadata between primary domains. For a small 32 TB MSDP storage pool performing a single stream read or write operation, storage media 250 MB/sec is recommended for enterprise-level performance. Scaling the disk capacity to 250 TB recommends a performing 500 MB/sec transfer rate. Multiple volumes may be used to provision storage; however, each volume should be able to sustain 250 MB/sec of IO. Greater individual data stream capability or aggregate capability may be required to satisfy your objectives for simultaneous writing to and reading from disk. The suggested layout to use in a cloud infrastructure is a striped RAID0 or RAID1 configuration. More complex RAID configurations are not cost-efficient.
Table: Recommended media server sizing guidelines shows recommended NetBackup media server sizing guidelines based on the size of the intended deduplication pool.
Table: Recommended media server sizing guidelines
Deduplication Pool | Storage | Cores | RAM in GB | Network in Gbps | IOPS |
|---|---|---|---|---|---|
10 TB (Small) | 1x160 SSD 1x16 TB SSD | 8 | 64 | ||
1 - 20 TB (Small) | 1x80 SSD 1x16 TB SSD | 8 | 32 | 10 | |
32 TB (Medium) | 1x80 SSD 2x16 TB SSD | 16 | 32 | 10 | |
1x160 SSD 2x16 TB SSD IOPs - 12,000 | 36 | 64 | 12,000 | ||
32 - 64 TB (Large) | 1x80 SSD 2-4x16 TB SSD | 16 | 64 | 10 | |
1x80 SSD 2-4x16 TB SSD | 36 | 64 | 10 | ||
1x160 SSD 2x16 TB SSD IOPs - 12,000 | 40 | 160 | 12,000 | ||
32 - 64 TB (X-Large) | 1x80 SSD 2-4x16 TB SSD | 32 | 144 | 10 | |
2x320 SSD 2-6x16 TB SSD IOPs -12,000 | 40 | 160 | 10 | 12,000 |
Table: Recommended initial NetBackup MSDP-C sizing guidelines
Role | Storage | CPUs | RAM |
|---|---|---|---|
MSDP-C Small | 250 GB SSD 1+TB | 4 | 16 GB |
MSDP-C Large | 500 GB SSD 1+TB | 8 | 32 GB |