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
Reverting back to Cloud Catalyst from a successful migration
The process to revert back to Cloud Catalyst assumes that a NetBackup catalog backup was performed for the master server catalog before the nbdecommission -migrate_cloudcatalyst command was run. If no such NetBackup catalog backup image is available, it is not possible to revert to Cloud Catalyst because the migration process modifies the NetBackup catalog.
The reversion process also assumes that the command /usr/openv/pdde/pdcr/bin/cacontrol --catalog cleanupcloudcatalystobjects has not been run on the migrated MSDP cloud tier server. The reason for that is because once that command has been run, it is not possible to revert back to Cloud Catalyst.
The images that Cloud Catalyst wrote and that have expired since the migration was completed, have been removed from the cloud storage. Reverting to Cloud Catalyst does not make these images available for restore as that data no longer exists.
All caveats and limitations of performing a NetBackup master server catalog recovery apply, see the section of the NetBackup admin guide that discusses catalog recovery in detail. Specifically, no data is written to the MSDP server or other storage servers after the point in time at which the catalog backup image was created is available. The data is not available for a restore after the NetBackup master server catalog recovery is performed.
You can use one of the following procedures to revert back to Cloud Catalyst:
The following procedure assumes that the Cloud Catalyst server has been left in the same state that it was in at the time of migration and all services are stopped.
Reverting back to Cloud Catalyst when the server is in the same state when the migration was performed
- Stop the NetBackup services on the new MSDP cloud tier server.
- Run the Recover the catalogs wizard in the NetBackup Administration Console.
In the NetBackup Administration Console, click NetBackup Management in the left pane and then Recover the catalogs in the right pane. The Catalog Recovery Wizard Welcome panel appears.
- Select the catalog backup image that was created before running the nbdecommission -migrate_cloudcatalyst command to migrate Cloud Catalyst to MSDP cloud tier server.
- Complete all steps in the wizard to recover the NetBackup catalog.
- Stop and restart the NetBackup services on the master server.
- On the Cloud Catalyst server, ensure that the
esfs.json
file has ReadOnly set to 0.If you only need to do restores and do not intend to run new backup or duplication jobs to Cloud Catalyst, then set ReadOnly to 1.
- Start the NetBackup services on the Cloud Catalyst server.
- Once the Cloud Catalyst storage server has come online, you can proceed with restores, backups, or optimized duplication jobs.
Backup or optimized duplication jobs require that ReadOnly is set to 0 in the
esfs.json
file. - If running a Cloud Catalyst version older than 8.2 (example: 8.1, 8.1.1, 8.1.2), you may need to deploy a new host name-based certificate for the media server. You can deploy the certificate by running the following command on the master server:
/usr/openv/netbackup/bin/admincmd/bpnbaz - ProvisionCert <CloudCatalyst host-name>
You must restart the NetBackup services on the Cloud Catalyst server.
- You may need to run the following command to allow Cloud Catalyst to read from the bucket in the cloud storage:
/usr/openv/esfs/bin/setlsu_ioctl <cachedir>/storage/proc/cloud.lsu <bucketname>
No harm is done if you run this command when it is not needed. If you do run the command, you can see the following output:
return code: -1 File exists.
- (Optional) Remove the entire MSDP cloud sub-bucket folder in cloud storage to avoid wasted space and avoid any problems with future migration to MSDP cloud tier server.
The following procedure assumes that the Cloud Catalyst server was reused and or reinstalled as an MSDP cloud tier server or is unavailable for some other reason.
Reverting back to Cloud Catalyst when the server was reused and or reinstalled when the migration was performed
- Stop the NetBackup services on the new MSDP cloud tier server.
- Run the Recover the catalogs wizard in the NetBackup Administration Console.
In the NetBackup Administration Console, click NetBackup Management in the left pane and then Recover the catalogs in the right pane. The Catalog Recovery Wizard Welcome panel appears.
- Select the catalog backup image that was created before running the nbdecommission -migrate_cloudcatalyst command to migrate Cloud Catalyst to MSDP cloud tier server.
- Complete all steps in the wizard to recover the NetBackup catalog.
- Stop and restart the NetBackup services on the master server.
- Reinstall the Cloud Catalyst server using the same NetBackup version and EEB bundles that were active when migration was performed.
- Then contact Veritas Technical Support to use the rebuild_esfs process to recover that Cloud Catalyst server from the data in cloud storage. (The rebuild_esfs process supersedes the old drcontrol method of recovering a Cloud Catalyst server. The drcontrol method is deprecated.)
- (Optional) Remove the entire MSDP cloud sub-bucket folder in cloud storage to avoid wasted space and avoid any problems with future migration to MSDP cloud tier server.