> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Set up disaster recovery

## Set up DR on a new cluster

You can enable DR when creating a new dedicated cluster through the Astro UI. See [Create a dedicated Astro cluster](/docs/astro/create-dedicated-cluster) for configuration steps and field descriptions. After the cluster is created, complete the [required steps after enabling DR](#required-steps-after-enabling-dr) before triggering a failover.

<Info>
  Terraform support for DR cluster creation are planned for general availability (GA).
</Info>

<Note>
  DR cluster creation is also supported using the [Astro API](https://www.astronomer.io/docs/astro/api).
</Note>

## Set up DR on an existing cluster

To enable DR on an existing dedicated cluster, submit a support request through the Astro UI. Astronomer processes the request during your specified maintenance window.

#### Prerequisites

* Organization Owner role with `organization.clusters.update` permission
* A dedicated AWS or GCP cluster that is not already DR-enabled

#### Submit a DR enablement request

<Steps>
  <Step title="Open the support request form">
    You can open the form in two ways:

    * From the **Disaster Recovery** tab: In the Astro UI, go to **Settings** > **Clusters** (**Organization Settings** > **Clusters** in the legacy UI), select your cluster, open the **Disaster Recovery** tab, then click **Enable Disaster Recovery**. The form opens for your cluster's cloud provider.
    * From the support menu: In the Astro UI, open **New Support Request** and select the request type for your cloud provider, either **Enable AWS Data Plane Disaster Recovery** or **Enable GCP Data Plane Disaster Recovery**.
  </Step>

  <Step title="Configure the request">
    Complete the following fields. The required network ranges depend on your cluster's cloud provider:

    <Tabs>
      <Tab title="AWS">
        * **Cluster**: Select the AWS cluster to enable DR on. Only eligible clusters appear. The cluster must be an AWS dedicated cluster that isn't already DR-enabled.
        * **Failover Region**: Select the AWS region for the secondary cluster.
        * **DR VPC Subnet Range**: (Optional) Specify a VPC subnet range for the secondary cluster. Leave blank to use the same range as the primary cluster.
        * **DR Pod CIDR Range**: (Optional) Specify a Pod CIDR range for the secondary cluster. Leave blank to use the same range as the primary cluster.
        * **Task Logs Replication SLA**: Enable to guarantee a 15-minute RPO for task logs. Additional charges apply. See [Task Logs Replication SLA](/docs/astro/disaster-recovery-prepare#task-logs-replication-sla).
        * **Maintenance Window**: Select a date and time for the maintenance window. The date must be at least 5 days from today. Weekends are not available.
        * **Additional Details**: (Optional) Include any additional context or requirements.
        * **CC Emails**: (Optional) Add email addresses to copy on the support ticket.
      </Tab>

      <Tab title="GCP">
        * **Cluster**: Select the GCP cluster to enable DR on. Only eligible clusters appear. The cluster must be a GCP dedicated cluster that isn't already DR-enabled.
        * **Failover Region**: Select the GCP region for the secondary cluster. Only regions compatible with your primary region appear, based on supported GCP dual-region pairings.
        * **DR VPC Subnet Range**: Specify the VPC subnet range for the secondary cluster. This range is required and must not overlap with the primary **VPC Subnet Range**.
        * **DR Pod CIDR Range**: Specify the Pod range for the secondary cluster. This range is required and must not overlap with the primary **Pod Subnet Range**.
        * **DR Service Subnet Range**: Specify the Service range for the secondary cluster. This range is required and must not overlap with the primary **Service Subnet Range**.
        * **DR Service Peering Range**: Specify the Private Service connection range for the secondary cluster. This range is required and must not overlap with the primary **Service Peering Range**.
        * **Task Logs Replication SLA**: Enable to guarantee a 15-minute RPO for task logs. Additional charges apply. See [Task Logs Replication SLA](/docs/astro/disaster-recovery-prepare#task-logs-replication-sla).
        * **Maintenance Window**: Select a date and time for the maintenance window. The date must be at least 5 days from today. Weekends are not available.
        * **Additional Details**: (Optional) Include any additional context or requirements.
        * **CC Emails**: (Optional) Add email addresses to copy on the support ticket.
      </Tab>
    </Tabs>
  </Step>

  <Step title="Submit the request">
    Click **Submit Support Request**. Astronomer confirms the maintenance window and contacts you before beginning the conversion.
  </Step>
</Steps>

<Warning>
  Running, scheduled, and event-triggered tasks are affected during the maintenance window. Tasks may fail and require a retry. Plan for 1-2 hours of downtime during the maintenance window.
</Warning>

The conversion process depends on your cluster's cloud provider:

<Tabs>
  <Tab title="AWS">
    * **Database migration**: Migrates the metadata database. This phase requires no downtime.
    * **Infrastructure switch**: Enables cross-region replication. This phase requires approximately 1-2 hours of maintenance downtime.
  </Tab>

  <Tab title="GCP">
    * **Configuring the DR region**: Astro copies your cluster's storage buckets to a dual-region configuration. This phase requires no downtime.
    * **Enabling DR**: Astro finalizes the storage relocation and enables cross-region replication. Each bucket has a brief write outage as its location changes.
  </Tab>
</Tabs>

Enabling DR incurs additional Astro credits. Secondary cluster resources and data replication incur ongoing charges based on your cluster configuration.

## Disable DR

Disabling DR deprovisions the secondary cluster and deletes all compute and data stores in the secondary region. This stops data replication and can't be undone without re-enabling DR.

<Warning>
  You can disable DR only while the cluster is running from its primary region. If the cluster has failed over to the secondary region, Astro blocks the request until you [fail back to the primary region](/docs/astro/disaster-recovery-failover#trigger-failback).
</Warning>

<Note>
  Disabling DR is also supported using the [Astro API](https://www.astronomer.io/docs/astro/api).
</Note>

#### Prerequisites

* Organization Owner role with `organization.clusters.update` permission

<Steps>
  <Step title="Open the DR tab">
    In the Astro UI, go to **Settings** > **Clusters** (**Organization Settings** > **Clusters** in the legacy UI), select your DR-enabled cluster, and open the **Disaster Recovery** tab.
  </Step>

  <Step title="Disable DR">
    On the **Disaster Recovery** tab, click **Disable**. Alternatively, open the cluster's actions menu (**⋯**) at the top right of the page and select **Disable Disaster Recovery…**. Enter the cluster name to confirm, then click **Disable Disaster Recovery**.
  </Step>
</Steps>

<Warning>
  This action is irreversible without re-enabling DR. Ensure you no longer need cross-region failover capability before disabling DR.
</Warning>

## Required steps after enabling DR

After Astronomer creates the secondary cluster, complete the following steps before triggering a failover:

1. **Networking and DNS**: Configure all required networking and DNS customizations for the secondary cluster. See [Networking considerations](/docs/astro/disaster-recovery-prepare#networking-considerations).
2. **imagePullSecrets**: If your Deployments use Kubernetes Pod Operators (KPOs), configure `imagePullSecrets` on the secondary cluster. See [Pull images from a private registry](/docs/astro/kpo-private-registry).
3. **Customer-managed workload identity**: If your Deployments use customer-managed workload identities, configure the appropriate workload identity and update the trust relationships for the secondary cluster. See [Workload identity](/docs/astro/disaster-recovery-prepare#workload-identity).
4. **Dag logic**: Update your Dag logic to handle the `ASTRONOMER_IS_DR_ENV` environment variable for secondary-specific connections or configurations. See [Prepare Dags for disaster recovery](/docs/astro/disaster-recovery-prepare#prepare-dags-for-disaster-recovery).