Veritas NetBackup™ Deduplication Guide
- Introducing the NetBackup media server deduplication option
- Planning your deployment
- About MSDP storage and connectivity requirements
- About NetBackup media server deduplication
- About NetBackup Client Direct deduplication
- About MSDP remote office client deduplication
- About MSDP performance
- MSDP deployment best practices
- Provisioning the storage
- Licensing deduplication
- Configuring deduplication
- Configuring the Deduplication Multi-Threaded Agent behavior
- Configuring the MSDP fingerprint cache behavior
- Configuring MSDP fingerprint cache seeding on the storage server
- About MSDP Encryption using KMS service
- Configuring a storage server for a Media Server Deduplication Pool
- Configuring a disk pool for deduplication
- Configuring a Media Server Deduplication Pool storage unit
- About MSDP optimized duplication within the same domain
- Configuring MSDP optimized duplication within the same NetBackup domain
- Configuring MSDP replication to a different NetBackup domain
- About NetBackup Auto Image Replication
- Configuring a target for MSDP replication to a remote domain
- Creating a storage lifecycle policy
- Resilient Network properties
- Editing the MSDP pd.conf file
- About protecting the MSDP catalog
- Configuring an MSDP catalog backup
- Configuring deduplication to the cloud with NetBackup CloudCatalyst
- Using NetBackup CloudCatalyst to upload deduplicated data to the cloud
- Configuring a CloudCatalyst storage server for deduplication to the cloud
- Monitoring deduplication activity
- Viewing MSDP job details
- Managing deduplication
- Managing MSDP servers
- Managing NetBackup Deduplication Engine credentials
- Managing Media Server Deduplication Pools
- Changing a Media Server Deduplication Pool properties
- Configuring MSDP data integrity checking behavior
- About MSDP storage rebasing
- Managing MSDP servers
- Recovering MSDP
- Replacing MSDP hosts
- Uninstalling MSDP
- Deduplication architecture
- Troubleshooting
- About unified logging
- About legacy logging
- Troubleshooting MSDP installation issues
- Troubleshooting MSDP configuration issues
- Troubleshooting MSDP operational issues
- Troubleshooting CloudCatalyst issues
- CloudCatalyst logs
- Problems encountered while using the Cloud Storage Server Configuration Wizard
- Disk pool problems
- Problems during cloud storage server configuration
- CloudCatalyst troubleshooting tools
- Appendix A. Migrating to MSDP storage
About seeding the MSDP fingerprint cache for remote client deduplication
Veritas provides a method for seeding the fingerprint cache for a new client. The use case that benefits the most from seeding is the first backup of a remote client over a high latency network such as a WAN. The performance of the first backup is then similar to the performance of an existing client.
An important consideration is the client from which to seed the cache. When you choose a similar client, consider the following:
If most of the information is the operating system files, use any client with the same operating system.
If most of the information is data, finding a client with the same data may be unlikely. Therefore, consider physically moving a copy of the data to the datacenter. Back up that data on a similar client, and then use that client and policy for the seed.
The more similar the clients are, the greater the cache hit rate is.
Two methods exist to configure cache seeding. You can use either method. The following table describes the seeding configuration methods.
Table: Seeding configuration methods
Host on which to configure seeding | Description |
---|---|
On the client | Configure seeding on the client for one or only a few clients. See Configuring MSDP fingerprint cache seeding on the client. |
On the storage server | The use case that benefits the most is many clients to seed, and they can use the fingerprint cache from a single host. See Configuring MSDP fingerprint cache seeding on the storage server. |
To ensure that NetBackup uses the seeded backup images, the first backup of a client after you configure seeding must be a full backup with a single stream. Specifically, the following two conditions must be met in the backup policy:
The Attributes tab attribute must be unchecked.
The backup selection cannot include any
directives.
If these two conditions are not met, NetBackup may use multiple streams. If the Attributes tab is set to a number less than the total number of streams, only those streams use the seeded images to populate the cache. Any streams that are greater than the value do not benefit from seeding, and their cache hit rates may be close to 0%.
After the first backup, you can restore the original backup policy parameter settings.
The following items are example of informational messages that show that seeding occurred:
Activity Monitor Job Details | 1/2/2015 2:18:23 AM - Info nbmaster1(pid=6340) StorageServer=PureDisk:nbmaster1; Report=PDDO Stats for (nbmaster1): scanned: 3762443 KB, CR sent: 1022 KB, CR sent over FC: 0 KB, dedup: 100.0%, cache hits: 34364 (100.0%) 1/2/2015 2:18:24 AM - Info nbmaster1(pid=6340) StorageServer=PureDisk:nbmaster1; Report=PDDO Stats for (nbmaster1): scanned: 1 KB, CR sent: 0 KB, CR sent over FC: 0 KB, dedup: 100.0% |
Deduplication plug-in log ( | 01/02/15 02:15:17 [4452] [4884] [DEBUG] PDSTS: cache_util_get_cache_dir: enter db=/nbmaster1#1/2, scp='', bc=opscenter1, bp=seedfinal, bl=4096 01/02/15 02:15:17 [4452] [4884] [DEBUG] PDSTS: cache_util_get_cache_dir: new backup, using existing client seeding directory 01/02/15 02:15:17 [4452] [4884] [DEBUG] PDSTS: cache_util_get_cache_dir: exit db=/nbmaster1#1/2, scp='', bc=opscenter1, bp=seedfinal, bl=4096, cachedir_buf='/nbmaster1#1/2/#pdseed/opscenter1' err=0 |
Deduplication proxy server log ( | 02:15:17.417[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDSTS: cache_util_get_cache_dir: enter db=/nbmaster1#1/2, scp='', bc=opscenter1, bp=seedfinal, bl=4096 02:15:17.433[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDSTS: cache_util_load_fp_cache_nbu: enter dir_path=/nbmaster1#1/2/#pdseed/opscenter1, t=16s, me=1024 02:15:17.449[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDSTS: cache_util_load_fp_cache_nbu: adding 'nbmaster1_1420181254_C1_F1.img' to cache list (1) 02:15:17.449[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDSTS: cache_util_load_fp_cache_nbu: opening /nbmaster1#1/2/#pdseed/opscenter1/nbmaster1_1420181254_C1_F1.img for image cache (1/1) 02:15:29.585[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDVFS: pdvfs_lib_log: soRead: segment c32b0756d491871c45c71f811fbd73af already present in cache. 02:15:29.601[4452.4884][DEBUG][dummy][11:bptm:6340:nbmaster1][DEBUG] PDVFS: pdvfs_lib_log: soRead: segment 346596a699bd5f0ba5389d4335bc7429 already present in cache. |
For more information about seeding, see the following Veritas tech note: