NetBackup™ Deduplication Guide
- Introducing the NetBackup media server deduplication option
- Quick start
- 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
- About MSDP stream handlers
- 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 NetBackup 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
- About NetBackup WORM storage support for immutable and indelible data
- MSDP cloud support
- About MSDP cloud support
- About the disaster recovery for cloud LSU
- About Image Sharing using MSDP cloud
- About MSDP cloud immutable (WORM) storage support
- 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
- Configuring and using universal shares
- Troubleshooting
- About unified logging
- About legacy logging
- Troubleshooting MSDP installation issues
- Troubleshooting MSDP configuration issues
- Troubleshooting MSDP operational issues
- Trouble shooting multi-domain issues
- Appendix A. Migrating to MSDP storage
- Appendix B. Migrating from Cloud Catalyst to MSDP direct cloud tiering
- About direct migration from Cloud Catalyst to MSDP direct cloud tiering
- Appendix C. Encryption Crawler
About postmigration configuration and cleanup
A successful migration results in a new disk pool for the MSDP cloud tier. If you want to use this new MSDP cloud tier server as the destination for new protection plans, policies, or duplication jobs, create a new storage unit. You must create a new storage unit for this new disk pool using the NetBackup web UI, NetBackup Administration Console, or storage API. The storage unit is not created automatically by the migration process.
Use the new storage unit as the destination for your protection plans, policies, and SLPs. You must activate any existing policies and SLPs that previously wrote to the migrated Cloud Catalyst server as the migration process disables them.
After a successful migration, you may want to clean up any obsolete objects that Cloud Catalyst created. Doing so can free up a relatively small amount of space in the cloud that is no longer needed by the MSDP cloud tier server. Veritas recommends waiting a few days or weeks to run the cacontrol --catalog cleanupcloudcatalystobjects command until you are certain that the migration has been successful. After this command is run, there is no longer any possibility of reverting to Cloud Catalyst to access your data. This step is an optional and no functionality is affected if it is never done.
Run the following command to clean up the obsolete objects:
/usr/openv/pdde/pdcr/bin/cacontrol --catalog cleanupcloudcatalystobjects <lsuname>
During migration, the nbdecommission command asks you the following question:
Do you wish to skip migrating CloudCatalyst image sharing information? (y/n) [n]:
You can answer y to this question if you are certain that you do not use the image sharing feature in your NetBackup environment.
You should leave the default answer of n in place for all other situations or if you are unsure if your environment does not use image sharing.
You must run an additional command on the image sharing server before you can access any images that were uploaded to the cloud by Cloud Catalyst. This command should only be run if you use image sharing. Run the following command on the image sharing server:
/usr/openv/pdde/pdcr/bin/cacontrol --catalog buildcloudcatalystobjects <lsuname>
After running the cacontrol --catalog buildcloudcatalystobjects <lsuname> command, restart the NetBackup services on the image sharing server.
If backups are written directly to the Cloud Catalyst server and you have the NetBackup Accelerator option enabled on your policies, there is a special consideration for Cloud Catalyst migration. The accelerator option uses the storage server name for optimization and that storage server name changes because of migration. Therefore, the first backup job that is written to the migrated MSDP cloud tier server has no accelerator optimization. Also, for accelerator enabled multiple stream policies that write directly to the migrated MSDP cloud tier server, the deduplication rate may be zero for the first backup job. Subsequent backup jobs return to normal accelerator optimization and deduplication rates.
The migration has no effect on NetBackup Accelerator enabled policies if those policies write to MSDP and then use a duplication job to write to Cloud Catalyst.
The nbdecommission command sets MachineState to administrative pause (13) for some servers. When a server has MachineState set to administrative pause (13), no jobs run, and the server may appear down.
You can display MachineState with the following command:
/usr/openv/netbackup/bin/admincmd/nbemmcmd -listhosts -display_server -machinename myserver.test.com -machinetype media -verbose
If you need to clear the administrative pause MachineState for a server, run the following command:
/usr/openv/netbackup/bin/admincmd/nbemmcmd -updatehost -machinename myserver.test.com -machinetype media -machinestateop clr_admin_pause -masterserver mymaster.test.com