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
- 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 immutable object support for AWS S3 compatible platforms
- About immutable storage support for Azure blob storage
- About immutable storage support for Google Cloud Storage
- 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
- Monitoring deduplication activity
- 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
- Using the ingest mode
- Enabling a universal share with object store
- Configuring isolated recovery environment (IRE)
- Using the NetBackup Deduplication Shell
- Managing users from the deduplication shell
- 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 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 beginning the direct migration
Determine a maintenance window during which the existing Cloud Catalyst server and the new MSDP server can be offline for the duration of the migration process. In most environments this process takes less than a day. For some very large environments or for environments with low available upload bandwidth to the cloud, the process may take longer.
Before beginning the direct migration, gather the following information:
The Cloud Catalyst server name (hostname of Cloud Catalyst appliance or BYO server).
The logon credentials for
root
on the Cloud Catalyst server. If the Cloud Catalyst server is an appliance, the credentials to log on and elevate the appliance to maintenance mode.The Cloud Catalyst storage server name (NetBackup cloud storage server that is used for Cloud Catalyst).
The Cloud Catalyst bucket or container name.
The KMS configuration, specifically the KMS key group name (only if KMS is configured).
If the Cloud Catalyst storage server type ends with
_cryptd
then KMS is enabled and<CloudCatalyst storage server name>:<bucket/container name>
is the KMS key group name.If the Cloud Catalyst storage server type ends with
_rawd
then check theKMSOptions
section ofcontentrouter.cfg
on Cloud Catalyst server. Verify if KMS is enabled and then locate the KMS key group name. If theKMSOptions
section does not exist, then KMS is not enabled. If theKMSOptions
section does exist, then theKMSEnable
entry isTrue
if enabled andFalse
if disabled.You can use the /usr/openv/pdde/pdcr/bin/keydictutil - - list command on the Cloud Catalyst server to view these KMS settings (version 8.2 and later of Cloud Catalyst).
You can use the /usr/openv/netbackup/bin/admincmd/nbkmsutil -listkgs command on the NetBackup primary server to list the KMS key group names. Verify that the KMS key group name you have gathered exists and is correct.
The name to be used for the new disk volume for the migrated MSDP direct cloud tier storage server.
The name to be used for the new disk pool for the migrated MSDP direct cloud tier storage server.
Any cloud credentials (if using AWS IAM role, plan to use the access key
dummy
and the secret access keydummy
).All other cloud-specific configuration information.
A list of all NetBackup policies and SLPs that currently write to the Cloud Catalyst storage server.
After you have gathered the previous list of information, download the sync_to_cloud
utility from the Veritas Download Center and make it available on the Cloud Catalyst server for use during the premigration procedure.
Verify that the MSDP data selection ID (DSID) used for Cloud Catalyst is 2
. Review the contents of the <CloudCatalyst cache directory>/storage/databases/catalog
directory. There should be one subdirectory and the name of that subdirectory should be 2
. If there are more subdirectories or if the subdirectory 2
does not exist, contact Veritas Support for assistance as this issue must be corrected before continuing.
On the primary server, ensure a catalog backup policy (policy type:
) exists and it has a policy storage destination other than the Cloud Catalyst storage server to be migrated. A manual backup of this catalog backup policy is initiated at certain points in the migration process to enable rollback recovery from a failed migration. If a catalog backup on storage other than the Cloud Catalyst server does not exist, recovery from a failed migration may be difficult or impossible.