NetBackup™ Backup Planning and Performance Tuning Guide

Configuring universal shares

To optimize the use of this feature, it is important to consider some key points directly related to configuration. How the shares are configured directly affects scalability and performance.

As a guideline, it is recommended that no more than 50 shares be created per NetBackup media server or NetBackup Flex Instance. This recommendation is a guideline only and not a hard limit. That said, significant performance testing has revealed that performance can be affected when surpassing more than 50 concurrent shares. For clarity, the term "concurrent" in this context refers to active executing read and write operations. It was also observed that performance tends to peak at 25 concurrent shares.

To provide the most flexibility, leveraging the NetBackup Flex Appliance provides a way to create multiple MSDP instances, with the optimal 50 shares per MSDP instance.

As with all solution design, it is important to be mindful of the amount of compute and I/O resources available on the target hardware. Furthermore, all best practice recommendations around optimizing MSDP performance still apply here as the underlying technology on the storage target is MSDP. The recommendation of 1 GB of memory for 1 TB of MSDP storage still applies here as well.

When leveraging Flex Appliances with universal shares, the same principles to avoiding I/O bottlenecks apply. For example, avoid sharing LUNs across MSDP instances.

Best practices for Flex Appliances, traditional NetBackup Appliances, and BYO still apply as the universal share feature leverages the same underlying MSDP technology.

Universal share size is limited to 960 TB.

Each individual share can be used by multiple hosts. However, it is recommended that one share not be assigned to more than a few host clients, especially if each host client is frequently dumping data to the share. A share that is mapped to many host clients can experience performance bottlenecks that affect the success of universal share backups and secondary operations that are executed thereafter. For very busy environments, a 1:1 ratio of share to host client is optimal.

Any data that is ingested into the universal share resides in the MSDP storage pool that is located on the appliance-based or BYO media server hosting the universal share. While any data ingested into the universal share is deduplicated and located in MSDP immediately, that data will not be referenced in the NetBackup catalog and no retention enforcement enabled before running a universal share backup. Without a universal share backup, the data that is placed in the universal share is not searchable and cannot be restored using standard NetBackup procedures. Before the backup, control of the data in the share is entirely managed by the host that is mounting the share. If the owner of the share deletes the share data or if the share itself is removed, the data that used to exist in the share is not recoverable by NetBackup. Therefore, the universal share protection point backup, a special backup type, was designed to facilitate management and restorability through traditional NetBackup methods.

For clarity, references to a universal share backup and a universal share protection point are the same in that they both refer to the special NetBackup policy type that indexes the data in the share and sets the retention enforcement, making it available for other activities like secondary operations.

A single NetBackup policy can be configured to protect every universal share within a NetBackup domain or multiple NetBackup policies can be configured to protect each individual universal share. When a protection point is executed, no data movement occurs. Furthermore, the performance of this special backup is not based on the size of the file data. It is more closely correlated with the number of files in the specific universal share. As part of the special backup activity, each file in the share is indexed within the NetBackup catalog, and retention enforcement is set.

Running a universal share protection point backup during the quiet period when no dumps are occurring on the share helps to ensure that the complete dump is captured, as well as avoiding I/O contention between extensive read and write activities.

In reference to the recommendation of the optimal 1:1 ratio of host client to share mapping and scheduling the backup and any secondary operations during a quiet period, the 1:1 ratio helps prevent a scenario where there are too many host clients hitting a specific share, thus making it difficult to find a quiet period, as well as creating inevitable I/O contention.

The results of extensive testing where each NetBackup protection point policy backs up a small number of shares, for example, ~10 shares, and where each host client is mapped to one share, were favorable and allowed time for secondary operations.

It is also important to note that the NetBackup Accelerator feature does not apply here, nor is it supported.

Any functionality that is available with storage lifecycle policies (SLP) can be applied to data managed by a universal share protection point backup. This functionality includes transitioning data to tape, cloud, optimized duplication (opt-dup) to other media servers, and replication to other NetBackup domains via Auto Image Replication (A.I.R.).

The maximum 50 concurrent universal share guideline includes read and write activities, including secondary operations.

To optimize performance of secondary operations, schedule these activities when no other read and write activities to the same share are occurring. For example, after the dump and the backup are completed.

As previously highlighted, the data characteristics that affect deduplication efficacy also apply here as the underlying technology is MSDP. If a DBA chooses to use third-party encryption with their database dumps, the deduplication rate will be affected negatively. Data leveraging third-party encryption doesn't deduplicate well. Furthermore, certain types of database dump compression can also negatively affect deduplication efficacy. In both cases, decreased deduplication efficacy negatively affects space optimization, and it will also affect the speed requirements and the storage requirements of secondary operations.

It is also important to note that data characteristics where the dumps universal share consist of millions of tiny files will also be affected due to the overhead in read and write activities.

For all the aforementioned data characteristics, it is important run some real performance benchmark tests to measure speed and deduplication efficacy before moving the solution into a production state.

For clarity, the deduplication occurs at the time of dump, and not during the time of the universal share protection point backup.