> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.14/onboard-cortex-xsoar/disaster-recovery-and-live-backup/configure-the-live-backup-environment/dr-scenario-testing-the-dr-environment.md).

# DR Scenario: Testing the DR Environment

Before you make the backup server the new production server, ensure the original production server is down (not live). If you make the backup server the new production server while the original production server is still live, you can experience significant issues.

After completing your test of the failover scenario (backup environment), you need to revert the server to its original state, which you can do through the UI or by modifying the configuration file.

{% hint style="info" %}

### Note

(Multi-tenant) - When using Live Backup in a multi-tenant deployment, each host machine has a backup server. When testing the disaster recovery environment, follow these steps to test each host machine separately, including the main account machine.
{% endhint %}

1. If you want to use Cortex XSOAR to backup the server, do the following:
   1. On the live production server, select Settings → Advanced → Backups → **Switch Hosts**.

      (Multi-tenant) - For a multi-tenant deployment, go to Settings → Account Management → **Hosts**. If you want to switch for the main host instead, go to Settings → Account Management → **Main Hosts**. Select the desired host, click the **Live Backup** button, and then **Switch Hosts**.
   2. When prompted, complete the online **Switch Hosts** instructions.

      Ensure that the production server is not live.

      (Multi-tenant) - Ensure that the production server for this machine is not live.
   3. Go to the backup server and follow the on-screen instructions to make the backup server the production server.
   4. In the backup server environment, go to Settings → About → **Troubleshooting**.
   5. For the **External Host Name** key, update the value to the host name of the backup server (the new production server).

      The backup server is unaware of its external host name.

      After a successful switch, the backup server is now live.
2. If you want to use a configuration file to test the DR environment, do the following:
   1. On the production server, stop the server:

      **`sudo service demisto stop`**
   2. Open the `/etc/demisto.conf` file on the production server. If the **`Server.dr.enabled`** property is in the file, change it to **`true`**. If it is not in the file, add **`Server.dr.enabled`** and set it to **`true`**.
   3. Start the server and verify it is in disaster recovery mode. You should see **This is currently the backup server**.
   4. On the backup server, stop the server:

      **`sudo service demisto stop`**
   5. Open the `/etc/demisto.conf` file on the backup server. If the **`Server.dr.enabled`** property is in the file, change it to **`false`**. If it is not in the file, add **`Server.dr.enabled`** and set it to **`false`**.
   6. Start the backup server.

      The original production server is now the backup server and the original backup server is now the production server. Access the new production server using its IP address to check that the server is up and running.
3. To revert to the original settings, repeat the steps above.

   When following the instructions, remember the backup server is now the production server and the production server is now the backup server.


---

# 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://cortex-docs.paloaltonetworks.com/xsoar-6-administrator-guide/6.14/onboard-cortex-xsoar/disaster-recovery-and-live-backup/configure-the-live-backup-environment/dr-scenario-testing-the-dr-environment.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.