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
Placing the Cloud Catalyst server in a consistent state
To ensure data integrity and consistency, it is important that there are no active jobs using the Cloud Catalyst server during migration. Perform the following procedure to stop all jobs and to ensure that the Cloud Catalyst server is in a consistent and a stable state before starting the migration process.
Note:
Any errors that are seen in the following procedure should be addressed before you begin the final migration. Read the full procedure and text following the procedure before you begin this process in your environment.
To place the Cloud Catalyst server in a consistent state
- Deactivate all backup policies that write to the Cloud Catalyst storage server.
- Deactivate all storage lifecycle policies that write to the Cloud Catalyst storage server.
- Verify all active jobs that use the Cloud Catalyst storage server have stopped.
- Run a catalog cleanup on the master server using the bpimage -cleanup command..
Location: /usr/openv/netbackup/bin/admincmd/bpimage -cleanup -allclients -prunetir
- Once the catalog cleanup completes, process the MSDP transaction queue manually on the Cloud Catalyst server using the crcontrol - - processqueue command and wait for the processing to complete.
Location: /usr/openv/pdde/pdcr/bin/crcontrol - - processqueue
- Repeat step 5 to verify that all images have been processed.
- Monitor
/usr/openv/netbackup/logs/esfs_storage
log on the Cloud Catalyst server for at least 15 minutes (at a minimum) to ensure that all delete requests have processed. - On the Cloud Catalyst server run the /usr/openv/pdde/pdcr/bin/cacontrol --catalog recover all_missing command.
Warning:
If this step reports any errors, those errors must be addressed before you continue to the next step. Contact Veritas Support if assistance is needed in addressing the errors.
- On the Cloud Catalyst server run the /usr/openv/pdde/pdcr/bin/catdbutil --list command and redirect the output to a temporary file.
Monitor this file for errors and contact Veritas Technical Support if any errors are reported.
- When the previous steps have been completed without error, run the sync_to_cloud utility and wait for it to complete. Running this utility may take time depending on environment.
- After
sync_to_cloud
has finished successfully, shut down services on the Cloud Catalyst server.You can leave the services down on the Cloud Catalyst server. Or, if you plan to use a different MSDP server to migrate Cloud Catalyst, you can change the
Readonly
field to 1 in<CloudCatalyst cache directory>/cache/etc/esfs.json
. Then restart the services on the Cloud Catalyst server. If the services are running on the Cloud Catalyst server at the time of migration certain configuration items like cloud bucket name are determined automatically. If not, you need to enter those configuration items you gathered in the following section: - Run a manual backup of the catalog backup policy (policy type: NBU-Catalog).
Do not skip this step as it is very important to run this manual backup. This backup establishes a point in time to return to if the migration does not complete successfully.
If possible, it is preferable to use a new MSDP direct cloud tier server for migration. Using a new server keeps the existing Cloud Catalyst server intact and usable if the migration unexpectedly fails. If you plan to reuse the Cloud Catalyst server as the new MSDP direct cloud tier server, you need to uninstall and or reimage the server at this time. Be sure to remove all of NetBackup and the contents of the Cloud Catalyst cache directory. If reusing a Cloud Catalyst appliance you may need to do a storage reset to remove the Cloud Catalyst cache, see the appliance documentation for details.
See Planning your MSDP deployment.
Note:
Although not usually recommended, in some special circumstances Cloud Catalyst is running on the master server. Since you cannot uninstall, reimage the master server, and you cannot upgrade it with Cloud Catalyst configured, you need to run the /usr/openv/esfs/script/esfs_cleanup.sh script to remove Cloud Catalyst. Then you can upgrade the master server and proceed with migration.