> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/secure-and-govern/data-backup-and-recovery.md).

# Data Backup & Recovery

Dispel's approach to data storage, retention, and recovery is engineered to provide robust security and operational resilience. Utilizing a combination of encrypted storage solutions, automated backup mechanisms, and geographically distributed redundancy, we aim to protect your data against unauthorized access and data loss. This documentation outlines the technical details of how these systems work, the policies that govern them, and the procedures to follow in case of data recovery needs.

## Data Locations <a href="#h_65e00cfeb6" id="h_65e00cfeb6"></a>

Dispel clients can choose from one of two data residency locations:

| Dashboard Type | Location      | Plans               |
| -------------- | ------------- | ------------------- |
| Dispel - US    | United States | SaaS                |
| Dispel - EU    | Europe        | SaaS, Private Cloud |

## Data Backup

<figure><img src="https://3566323743-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5T5Fo32wwisEqZbODG7j%2Fuploads%2Fgit-blob-64aef062f19766817be7bdcc6cbf28d5d073c2c0%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

Dispel performs automatic backups of all customer and system data to protect against catastrophic loss due to unforeseen events that impact the entire system. An automated process will back up all data to storage that is resilient against events that impact an entire availability zone. By default, data will be backed up at least once every 24 hours. The backups are stored in an encrypted data storage archive. Backups are monitored and alerted.

All databases managed by Dispel provide continuous protection by persisting snapshots, base backups and WAL files to object store. Also, fork and follower databases are implemented by fetching snapshots or persistent base backups and WAL files and replaying them on a fresh Postgres installation. Storing these physical backups in a highly available object store also enables us to recover entire databases in the event of hardware failure, data corruption or a large scale service interruption. By default, Dispel sub-processor object stores provides durable infrastructure to store important data and is designed for durability of 99.999999999% of objects.

### Backup Types

Dispel makes complete database backups. Transactions committed to the database are recorded as WAL files, which are able to be replayed on top of the snapshots or base backups, providing a method of completely reconstructing the state of a database. Snapshots are stored directly in object store. Base backups and WAL files are pushed to the object store through an application called WAL-E as soon as they are made available by Postgres.

## Data Restoration <a href="#h_29cc3a5682" id="h_29cc3a5682"></a>

Databases can be restored from backups from a cold state or synced with an existing database. These are known, respectively, as *fork* and *following* processes. Dispel can also rollback to an earlier database backup.

In all cases, a new database instance (N2) is created, brought in parallel to the existing database (N1), and then promoted to the primary database for the API. This is demonstrated in the following process diagram showing a database fork data restoration:

<figure><img src="https://3566323743-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F5T5Fo32wwisEqZbODG7j%2Fuploads%2Fgit-blob-ef090b32a2d4a60e1c730676b42d898dfdfb5665%2Fimage.png?alt=media" alt=""><figcaption></figcaption></figure>

### Disaster Recovery / Business Continuity <a href="#h_2c98034406" id="h_2c98034406"></a>

Our platform automatically restores Postgres databases in the case of an outage. The Dispel platform is designed to dynamically deploy applications within the cloud, monitor for failures, and recover failed platform components including customer applications and databases.

## Backup Retention Limits <a href="#h_ae062a7b1d" id="h_ae062a7b1d"></a>

Production databases run on Amazon Aurora (RDS) with automated backups configured for a rolling 30-day retention window, providing continuous point-in-time recovery (PITR) to any second within the most recent 30 days. Automated backups include daily snapshots and transaction logs stored in Amazon S3, all KMS-encrypted with access restricted to authorized operators. Logs may be retained up to one year or longer to support compliance, auditing, and forensic investigation requirements.

## Data Export / Archival

Clients may request a copy of their data for export and archival. Dispel uses the native `pg_dump` PostgreSQL tool to create its backup files, making it easy to export to other PostgreSQL installations. The resulting backup file uses the custom format option in `pg_dump`. As compared to the plain-text format, the custom format options result in backup files that can be much smaller.

## Data Ownership

Client data belongs to clients; Dispel data belongs to Dispel. For more information on how Dispel handles client data please review our [Privacy Policy](https://legal.dispel.com/policies/privacy-policy).


---

# 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.dispel.com/secure-and-govern/data-backup-and-recovery.md?ask=<question>&goal=<user_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.