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
  2. Cohesity Cloud Scale Technology Manual Deployment Guide for Kubernetes Clusters
  3. Section IV. Maintenance
  4. Cloud Scale Disaster Recovery
  5. Cloud Scale recovery
Cohesity Cloud Scale Technology Manual Deployment Guide for Kubernetes Clusters

Cloud Scale recovery

Perform the following procedure to recover Cloud Scale with the preserved configuration when there is an availability zone failure or cluster corruption.

There is a difference in term of subnet span for Azure and Amazon as follows:

  • Azure: The subnet spans all availability zones in a region. So, for deploying in different availability zone same subnets can be used.

  • Amazon: A subnet must live within a single availability zone. So, different subnet must be used corresponding to the availability zone being recovered.

Note:

As part of recovery, volumes would be deleted and hence NetBackup logs that existed before disaster recovery would not be available in the fluent bit collector pod.

To recover Cloud Scale

  1. Disaster recovery of Infra:

    Perform the following steps for disaster recovery of Infra:

    • For deployment done using Terraform script: Run the Terraform script for base and addon again with same inputs which was saved during successful deployment. For post deployment modifications done, update the additional infra details manually.

      Note:

      If deploying in EKS and in different availability zone, then use subnet corresponding to the new availability zone but ensure that FQDN remains same even though IP may be different.

    • For manual deployments or upgrade from previous deployments: Perform the following steps:

      • Recover from the saved template or information:

        For AKS: Modify the template and then recover AKS cluster from the template.

        For EKS: Perform the EKS cluster recovery steps.

        See Cluster recovery.

      • Install cert-manager (refer to the following section) and ensure that the prerequisites listed in the following section are met:

        See Preparing the environment for NetBackup installation on Kubernetes cluster.

    Note:

    If user needs to destroy the setup created, user must verify if the required permissions are provided to the key vault created during cluster creation phase. If the required permissions are not provided then the destroy command will display the following error:

    does not have secrets get permission on key vault

  2. Recovery of Cloud Scale:

    Start deployment and recovery using the steps from the following section:

    See Environment Disaster Recovery.

Feedback

Was this page helpful?
Previous

Cluster recovery

Next

Environment Disaster Recovery

Feedback

Was this page helpful?