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
rooton 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
_cryptdthen 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
_rawdthen check theKMSOptionssection ofcontentrouter.cfgon Cloud Catalyst server. Verify if KMS is enabled and then locate the KMS key group name. If theKMSOptionssection does not exist, then KMS is not enabled. If theKMSOptionssection does exist, then theKMSEnableentry isTrueif enabled andFalseif 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
dummyand 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 Cohesity 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 Cohesity 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.