Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  3. NetBackup™ Deduplication Guide
  5. Appendix B. Migrating from Cloud Catalyst to MSDP direct cloud tiering
  7. About direct migration from Cloud Catalyst to MSDP direct cloud tiering
  9. Placing the Cloud Catalyst server in a consistent state
NetBackup™ Deduplication Guide

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

  1. Deactivate all backup policies that write to the Cloud Catalyst storage server.
  2. Deactivate all storage lifecycle policies that write to the Cloud Catalyst storage server.
  3. Verify all active jobs that use the Cloud Catalyst storage server have stopped.
  4. Run a catalog cleanup on the master server using the bpimage -cleanup command..

    Location: /usr/openv/netbackup/bin/admincmd/bpimage -cleanup -allclients -prunetir

  5. 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

    See Processing the MSDP transaction queue manually.

  6. Repeat step 5 to verify that all images have been processed.
  7. Monitor /usr/openv/netbackup/logs/esfs_storage log on the Cloud Catalyst server for at least 15 minutes (at a minimum) to ensure that all delete requests have processed.
  8. 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.

  9. 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.

  10. 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.

    See About beginning the direct migration.

  11. After sync_to_cloud has 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 Readonly field 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:

    See About beginning the direct migration.

  12. 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.

Feedback

Was this page helpful?
Previous

About beginning the direct migration

Next

About installing and configuring the new MSDP direct cloud tier server

Feedback

Was this page helpful?