> For the complete documentation index, see [llms.txt](https://docs.plenit.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.plenit.com/docs-en/productos/disaster-recovery/how-to/how-to-perform-a-failback.md).

# How to Perform a Disaster Recovery Failback

After a failover, you work temporarily at the backup site. Failback is the way back to the original environment, and depending on your situation you have three ways to do it: keeping the backup changes, switching back quickly without replicating, or reconfiguring the replica from scratch.

This guide helps you choose and carry out the right one.

> #### 👍 What you get
>
> The operation returned to your original subscription after a failover, with the appropriate failback method for your scenario and the replica ready for the next incident.

### Choose your option

* **Option 1 — Return without losing changes**: if you have kept working at the backup site and need to preserve that data before returning to the origin.
* **Option 2 — Return quickly to the origin**: if the failover was a test or a mistake, or you can already resume normal operation without rebuilding the configuration.
* **Option 3 — Reconfigure the replica**: if you want to completely redefine the direction of the replica or create a new destination.

### Before you start

* Access the administration panel at [admin.plenit.com](https://admin.plenit.com) with permissions on the environment.
* Have a protected Servers or Remote Desktop subscription, and its **Disaster Recovery**.
* That the Disaster Recovery subscription is **in failover state**.

> #### ❗️ Overwriting deletes the destination data
>
> In the replication steps you can choose **overwrite** the destination subscription. 
>
> If you do, any data in it is lost. That is the usual thing when redoing the replica, but make sure the destination is correct before confirming. 
>
> Activating servers and replication may take time depending on the disk volume and infrastructure load.

Throughout the guide, an example is used with **Madrid** as the primary site and **Paris** as the backup site (Recovery site), so the direction of replication can be seen at each moment.

### Option 1. Return to the original site without losing changes

Use it when you have worked on the backup and want to return to the origin with that data. The path is: replicate from the backup to the origin, perform failback, and then leave replication from the origin to the backup again.

#### 1.1 Reconfigure replication from the backup to the origin

In **My Plans**, check that the **Recovery Site** is **active** and the **Primary Site** is **inactive**, and click **Reconfigure** to open the replication wizard. Select as **source** the backup subscription (in the example, Paris) and click **Next**.

{/\* 📸 CAPTURE 1 · My Plans · active/inactive states · Reconfigure button \*/}

![Site status and replication reconfiguration](https://REEMPLAZA-URL/disaster-recovery-failback-01.png)

Select as **destination** the source subscription (in the example, Madrid) and click **Next**.

{/\* 📸 CAPTURE 2 · selection of replication source and destination \*/}

![Replication source and destination for the rollback](https://REEMPLAZA-URL/disaster-recovery-failback-02.png)

Set the **frequency** of the replicas, **how many** are kept and the **Failover mode** (DNS or IP), and click **Finish**. The replica starts and you can follow the progress in the front end until it becomes **active**.

{/\* 📸 CAPTURE 3 · frequency, restore points and type of failover \*/}

![Frequency, retention, and failover configuration](https://REEMPLAZA-URL/disaster-recovery-failback-03.png)

#### 1.2 Start the failback

With the replica active and the data up to date at the origin, click **Failback**. Select the **restore point** to return to and click **Confirm**; confirm again for it to take effect.

{/\* 📸 CAPTURE 4 · Failback · selection of restore point \*/}

![Failback and restore point selection](https://REEMPLAZA-URL/disaster-recovery-failback-04.png)

You will see the notice that failback is in progress and the operation updating on the Primary Site. When finished, the **Primary Site** becomes **active** and the **Secondary Site** is **inactive**.

#### 1.3 Leave the replica ready for the next incident

To protect the environment again, click **Reconfigure** and create the replica from the origin to the backup (in the example, from Madrid to Paris): select source and destination, set the frequency, first replica, restore points and **Failover mode**, and click **Finish**. With that, DR is operational again.

{/\* 📸 CAPTURE 5 · reconfiguration of the origin → backup replica \*/}

![Replica reconfiguration to leave DR protected](https://REEMPLAZA-URL/disaster-recovery-failback-05.png)

### Option 2. Return quickly to the origin after a test or error

Use it when the failover was temporary and you do not need to replicate changes from the backup before returning.

In **My Plans**, check that the services are active on the secondary subscription and that the primary one is inactive. Click **Activate** on the primary subscription and accept the startup. The servers start (this may take some time depending on the volume) until the service becomes active.

{/\* 📸 CAPTURE 6 · activation of the primary subscription \*/}

![Activation of the servers of the primary subscription](https://REEMPLAZA-URL/disaster-recovery-failback-06.png)

Then, return the traffic to the origin: click **Switch DNS** on the primary subscription. A notice reminds you that traffic changes direction and that some connections may be lost; click to continue. Traffic passes through the original subscription again.

{/\* 📸 CAPTURE 7 · Switch DNS · traffic change notice \*/}

![Switch DNS to return traffic to the origin](https://REEMPLAZA-URL/disaster-recovery-failback-07.png)

> #### 🚧 The backup remains active: close it with the replica
>
> After Switch DNS, the backup subscription (in the example, Paris) remains active as well as the origin one. 
>
> To make it inactive again and return to the protected scheme, configure the replica from the origin to the backup, as in Option 1.3.

### Option 3. Fully reconfigure the replica

Use it when you need to redefine the source and destination of the replica after failover. Open the full replication wizard from **Reconfigure** and decide which direction the protection should be in:

* **Paris as source and Madrid as destination**: if you are still operating on the backup and replicating back to the origin.
* **Madrid as source and Paris as destination**: if you have already returned to the main environment and are restoring the usual scheme.

Select the **source** and click **Next**. Choose the **destination**, where you can:

* **Overwrite** the current copy: replaces the destination data (the most common option).
* **Create a new destination subscription**: keeps the current one, but adds an associated cost.

If you overwrite, a warning appears that the destination data will be lost. Click **Next**.

{/\* 📸 CAPTURE 8 · destination selection · overwrite or new subscription \*/}

![Selection of the replication destination](https://REEMPLAZA-URL/disaster-recovery-failback-08.png)

Set the **frequency** (from 1 to 24 hours), **when** the first replica is launched, the number of **restore points** (from 1 to 24, 12 by default) and the **Failover mode** (DNS or IP). Click **Finish** to start the replica.

{/\* 📸 CAPTURE 9 · frequency, retention and failover type of the new replica \*/}

![New replica configuration](https://REEMPLAZA-URL/disaster-recovery-failback-09.png)

### Conclusion

Failback has three paths and the key is to choose well according to your case: if you worked on the backup and do not want to lose anything, first replicate to the origin (Option 1); if it was a test or an error, switch back quickly by activating the origin and changing the DNS (Option 2); and if you need to redefine protection, reconfigure the entire replica (Option 3).

In all cases, two precautions: confirm the destination carefully before overwriting, and finish by leaving the replica from the origin to the backup so the environment is protected again against the next incident.

### Next steps

* Review how failover is activated in [Failover and failback.](/docs-en/productos/disaster-recovery/concepts/failover-and-failback.md)
* Adjust frequency and restore points in [Replication settings.](/docs-en/productos/disaster-recovery/detalles/replication-parameters.md)
* Test the plan without affecting production with a [drill.](/docs-en/productos/disaster-recovery/concepts/drills.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.plenit.com/docs-en/productos/disaster-recovery/how-to/how-to-perform-a-failback.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.