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 Key Management Server 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
- Running MSDP services with the non-root user
- MSDP cloud support
- About MSDP cloud support
- Cloud space reclamation
- About the disaster recovery for cloud LSU
- About Image Sharing using MSDP cloud
- About MSDP cloud immutable (WORM) storage support
- About immutable object support for AWS S3
- About bucket-level immutable storage support for Google Cloud Storage
- About object-level immutable storage support for Google Cloud Storage
- About AWS IAM Role Anywhere support
- About Azure service principal support
- About NetBackup support for AWS Snowball Edge
- S3 Interface for MSDP
- Configuring S3 interface for MSDP on MSDP build-your-own (BYO) server
- Identity and Access Management (IAM) for S3 interface for MSDP
- S3 APIs for S3 interface for MSDP
- Disaster recovery in S3 interface for MSDP
- 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
- Configuring universal share user authentication
- Using the ingest mode
- Enabling a universal share with object store
- Configure a universal share accelerator
- About the universal share accelerator quota
- Configuring isolated recovery environment (IRE)
- Configuring an isolated recovery environment using the web UI
- Configuring an isolated recovery environment using the command line
- Using the NetBackup Deduplication Shell
- Managing users from the deduplication shell
- About the external MSDP catalog backup
- Managing certificates from the deduplication shell
- Managing NetBackup services from the deduplication shell
- Monitoring and troubleshooting NetBackup services from the deduplication shell
- Managing S3 service from the deduplication shell
- Troubleshooting
- About unified logging
- About legacy logging
- 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 failed migration
Recovering the NetBackup primary server catalog to revert back to Cloud Catalyst is the safest approach for both successful and a failed migration attempts. However, it may be possible to revert to Cloud Catalyst from a failed migration attempt without recovering the primary server catalog.
If the failure occurred and the nbdecommission command exits before displaying the following message, then you may be able to revert back to Cloud Catalyst without recovering the primary server catalog. The following message is displayed in the output from the command or the admin
log file for the nbdecommission command:
Disk pool <new disk pool name> has been successfully created with 1 volumes
Migration failures that occur after the Disk pool
message is displayed require recovering the primary server catalog to revert to Cloud Catalyst.
If you do not recover the primary server catalog, you must manually delete the new disk pool, disk volume, cloud storage server, and the MSDP cloud tier server. You must delete these after reverting back to Cloud Catalyst.
The following procedure assumes that the migration fails before the Disk pool message appears in the output. The procedure also assumes that the Cloud Catalyst server is not reused as the MSDP cloud tier server for migration.
Reverting back to Cloud Catalyst after a failed migration
- Stop the NetBackup services on the new MSDP cloud tier 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 8.2 or earlier, 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 primary 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 migration fails on the Cloud Catalyst server that was reused and or reinstalled as an MSDP cloud tier server.
Reverting back to Cloud Catalyst after a failed migration when the Cloud Catalyst server was reused
- Stop the NetBackup services on the new MSDP cloud tier 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.