> 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/cortex-xsoar-8-on-prem/8.9/onboard-cortex-xsoar/back-up-and-restore-cortex-xsoar/back-up-data/backup-guidelines-and-best-practices.md).

# Backup guidelines and best practices

Follow these recommendations to optimize your Cortex XSOAR backup strategy and avoid data corruption, latency issues, or management overhead.

#### Manage target folders

To prevent data corruption and backup interference, maintain dedicated target folders for each cluster and backup task. A target folder is the combination of your external storage (for example, S3 bucket or NFS path) and the relative path configured in the backup settings.

| Storage Type  | Target Folder Components                      |
| ------------- | --------------------------------------------- |
| S3            | bucket name + relative path                   |
| S3-Compatible | URL + bucket name + relative path             |
| NFS           | server address + storage path + relative path |

Follow these guidelines for effective folder management:

* **Isolate cluster data:** Use a unique target folder for each cluster to ensure backup components do not interfere with or corrupt each other's data.
* **Maintain flat directory structures:** Use separate, non-nested folders for each one-time backup or scheduled task to prevent directory conflicts.
* **Isolate incident export folders:** When exporting incidents, ensure the target folder is distinct from any folder occupied by backups.

#### Implement NFS external storage best practices

When using NFS as your external storage:

* **Preserve metadata:** If you need to manually copy backup files to another share or folder, copy both the `backups` and `kopia` folders and ensure file ownership is preserved.
* **Restrict external modifications:** Do not manually create folders inside the target folder externally.
* **Avoid reserved names:** Do not name folders `panw` or `cortex`. The system automatically creates a `panw/cortex` directory structure when a new NFS storage is added.

#### Configure retention and scheduling

* **Optimal retention:** Use a retention period of at least **30 days**. This provides sufficient time to act if a backup failure occurs or if a recovery is needed due to unforeseen issues.
* **Performance impact:** Avoid unnecessarily large retention periods, as accumulating too many resources can eventually affect cluster performance.
* **Version naming logic:** Scheduled backups are named based on the Cortex XSOAR version active at the time the schedule was created. For example, a schedule created on version 8.10 will retain the prefix `schedule-8-10-0-X-` even after the cluster is upgraded to 8.11.
* **Updating schedule names:** If you require backup names to reflect a major version upgrade,  delete the old schedule and recreate it from scratch.

#### Execute DC-DR drills

A drill is a scheduled practice exercise where you simulate a disaster recovery scenario to verify that your backup and restore procedures work correctly before an actual emergency occurs.

For Data Center (DC) and Disaster Recovery (DR) drills, we recommend creating separate target folders for each backup and restore operation: **DC Storage** and **DR Storage**.

* **Minimize latency:** Place the DC storage in the same region as your DC cluster and the DR storage in the same region as the DR cluster to minimize downtime during restore operations.
* **Storage cleanup:** If using NFS, delete the external storage configuration via the Cortex XSOAR UI before shutting down clusters during the drill.
* **Post-restore configuration:** External storage and backup schedule configurations are not retained after a restore operation on a new cluster. You must manually reconfigure them once the restore is complete.


---

# 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/cortex-xsoar-8-on-prem/8.9/onboard-cortex-xsoar/back-up-and-restore-cortex-xsoar/back-up-data/backup-guidelines-and-best-practices.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.