> 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 How you switch services to the Recovery site when needed and how you return to the original environment without losing your work 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` 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 what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.