Configuring Disaster Recovery Plan

Last published : Jun 12, 2026
With a Disaster Recovery Plan (DR Plan) you can enable disaster recovery for a particular namespace. For a more granular control, you can selectively label components in the namespace and create a DR Plan with namespace and labels. A DR Plan cannot span multiple namespaces. DR Plan must be created only on the primary cluster. DR Plan is automatically created and synchronized on all peer clusters after its creation on the primary cluster. Migration and other operations on the namespace can be triggered by updating certain attributes.
To enable a non-kubeadmin user (any user other than infoscale-admin) access custom resources on a secondary cluster after applying Disaster Recovery Plan (DR Plan) custom resource on primary cluster, a role and role-binding must be created . After a DR Plan custom resource is created on the primary cluster, an application namespace is automatically created on the secondary cluster. The role and role-binding on the primary cluster can then be saved and applied on secondary cluster in the same namespace.
Note: Clusterwide (across namespaces) RBAC permissions are granted to the service account ofinfoscale-dr-managerpod as required. As a Storage Administrator, ensure that a non-privileged user does not havekubectl execpermissions on the infoscale-dr-manager pod.
  1. Edit /infoscale-yamls-v8.0.410/DR/SampleDisasterRecoveryPlan.yaml as under to create DR plan for application components in a given namespace.
    Note: Ensure that this resource is applied in the same namespace as that of data replication configuration resource.
    apiVersion: infoscale.veritas.com/v1
    kind: DisasterRecoveryPlan
    metadata:
      name: <Name of the Disaster Recovery Plan>
      \#namespace: <Enter the namespace>
    spec:
      \# Name of cluster that should be treated as primary for this DR plan
      primaryCluster: <ID of the cluster you want to back up>

      \# (optional) Set force to True if peer cluster(s) is not reachable
      \# and local cluster needs to perform takeover
      force: false

      \# List of member cluster(s) where this DRPlan can failover.
      \# Sequence of MemberCluster specified in this list denotes
      \# relative preference of member cluster(s)
      \# Must be subset of Global Cluster Membership
      preferredClusterList: ["<ID of the cluster you want to back up>",
                           "<ID of the cluster where you want to back up>"]

      \# Kind of corrective action in case of disaster
      \# default value will be "Manual" if not specified
      clusterFailOverPolicy: Manual

      \# Specify namespace and optionally labels to decide what
      \# all needs to be part of the disaster recovery plan
      selector:
        namespace: mysql
        \#labels:
        \#  - "app=db,env=dev"

      \# (optional) Pointer to manage data replication
      \#dataReplicationPointer: test-datareplication

      \# (optional) Pointer to manage DNS endpoints
      \#dnsPointer: test-dns
    Note: dataReplicationPointeris needed only if you have stateful applications that require data replication across peer clusters.
    1. Run the following command on the master node:
    kubectl apply -f /infoscale-yamls-v8.0.410/DR/SampleDisasterRecoveryPlan.yaml
    1. Wait till the command run is successful and the following message appears:
    disasterrecoveryplan.infoscale.veritas.com/
                      \<Name of Disaster recovery plan\> created
  2. Run the following command on the master node:
kubectl get drplan
  1. Review the output similar to the following:
    NAME     PREFERREDCLUSTERLIST SPEC.PRIMARYCLUSTER
    <Name of("ID of the cluster  "ID of cluster
    Disaster you want "           where you want
    recovery  to back up          to back up")
    plan>    STATUS.PRIMARYCLUSTER DATAREPLICATION DNS
    ID of the current     ID of the current
    cluster               cluster
Related information