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.

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

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.

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.

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:

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.

Dispel maintains both continuous protection and scheduled backups of our databases. Continuous protection maintains a rolling 7 day backup.

Dispel's SaaS system maintains the following retention schedules:

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.

Client data belongs to clients; Dispel data belongs to Dispel. For more information on how Dispel handles client data please review our Privacy Policy.