> 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/concepts/failover-and-failback.md). # Failover and Failback Failover and failback are two sides of recovery: switch to the backup when the primary environment goes down, and switch back to the original when it is restored. ### Failover: switch to the Recovery site When the Primary site becomes unavailable due to a serious incident, you activate the **failover**: the services move to the **Recovery site**, which already has the replicated environment ready to start. That is why recovery is fast: you do not rebuild anything, you activate what is already set up. Traffic is redirected to the Recovery site according to the **failover mode** you configured in the plan. | Failover mode | How it redirects | Status | | ------------- | -------------------------------------------------- | ----------- | | DNS | Changes the destination the service name points to | Available | | IP | Keeps the IP address at the backup site | Coming soon | > #### 🚧 You trigger the failover > > Disaster Recovery does not fail over by itself. You are the one who decides when to declare the disaster and switch to the Recovery site. > > This gives you control, but it also means the plan requires a decision; it is not triggered automatically. ### Failback: return to the Primary site When the Primary site is restored, you return with a **failback**. Here there is an important nuance: while you were in failover, you have been working in the Recovery site, so those changes are the good ones. That is why failback is not just "going back": first, replication is reconfigured in the opposite direction, from the Recovery site to the Primary site, to bring the recent changes back, and only then is the Primary site reactivated. This way you do not lose what you worked on during the contingency. > #### 📘 Practice the return path > > Failback is often the operation you will perform most often, because it is the return to normal. Having it clear in advance avoids surprises on the day it is needed. ### Where to continue * Testing failover without affecting production: [Drills.](/docs-en/productos/disaster-recovery/concepts/drills.md) * What is replicated and how often: [Replication.](/docs-en/productos/disaster-recovery/concepts/the-replica.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/concepts/failover-and-failback.md?ask=&goal= ``` `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.