> 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.13/learn-about-cortex-xsoar/onboarding-in-cortex-xsoar/disaster-recovery-and-live-backup/engines-and-disaster-recovery-troubleshooting.md).

# Engines and Disaster Recovery Troubleshooting

In the event of a failover between the Cortex XSOAR servers, engines are capable of dynamically failing over to the active node. This should happen automatically if the engine was deployed after DR was configured.

{% hint style="info" %}

### Note

Assuming all is configured and working properly, it should not be necessary to change the DNS to affect an engine failover when a server failover occurs.
{% endhint %}

If engine failover is not working when failing over between Cortex XSOAR servers (i.e., does not display as **Connected: false** in Settings → Integrations → **Engines**), it is likely due to one of the following causes:

* The file `/var/lib/demisto/d2_server.key` is not the same on each Cortex XSOAR server. This can sometimes happen if Live Backup was previously configured using Cortex SOAR (Demisto) 4.0 and this file did not exist at the time that Cortex XSOAR was first configured. Copy this file from the primary server to the backup server and restart the backup server service.
* On the engine, if the **`EngineURLs`** array property of `/usr/local/demisto/d1.conf` is missing the IP or host name of the backup Cortex XSOAR server, do the following:

  Simply redeploy the engine from Settings → Integrations → **Engines**. This should automatically include both servers in the d1.conf file.

  Modify the JSON in conf file manually, to add the other server to the **`EngineURLs`** array, and restart the engine. If a syntax error is detected in the JSON, the engine service refuses to start and may not log any error messages. The array should now look something like:

  ```programlisting
  EngineURLs": [
  "wss://cortex xsoarserver1:443/d1ws",

                  "wss://cortex xsoarserver2:443/d1ws"

          ],
  ```
* Host name resolution is broken from the engine to one of your servers. Use **`ping`** or **`nslookup`** to confirm that the engine host can resolve the backup server, and that the IP address of the server is correct. If not, it may require a change to your DNS environment or a network or host firewall is blocking connectivity from the engine to your backup Cortex XSOAR 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.13/learn-about-cortex-xsoar/onboarding-in-cortex-xsoar/disaster-recovery-and-live-backup/engines-and-disaster-recovery-troubleshooting.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.