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_storagelog 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_cloudhas 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
Readonlyfield 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.