Disaster recovery

Disaster recovery (DR) answers the question: if something serious happens, how long does it take us to come back, and how much data could we lose?

Two key metrics

RPO (Recovery Point Objective) — how much data you could lose: depends on the type of data. For the database we have point-in-time recovery (PITR), which allows restoring to a specific instant, not just the latest full backup. The file system (documents and attachments) is backed up periodically, so its recovery point is the latest available backup.
RTO (Recovery Time Objective) — how long it takes to restore the service.

How we approach it

flowchart TB
    DB[("Your environment's<br/>database")] ==> CB["Continuous backup<br/>restores to an exact instant (PITR)"]
    FS[("File system<br/>documents and attachments")] ==> PB["Periodic backup<br/>restores to the latest copy"]
    CB ==> ST[/"Independent storage · Spain"/]
    PB ==> ST
    ST ==> REC["Recovery<br/>reproducible rebuild of the environment (as code)<br/>+ data restoration"]
    REC ==> NEW["Restored environment"]

Backups separate from the environment: backups reside in independent storage, in Spain (see Backups).
Reproducible rebuild: since the infrastructure and configuration are defined as code, an environment can be rebuilt repeatably and reload its data from the latest valid backup.
Self-healing for everyday component failures, with no intervention needed (see High availability).

Point-in-time recovery (PITR)

This capability applies to the database: in addition to backups, its state can be restored to a specific moment before the incident, minimizing data loss.

The file system (documents and attachments) is backed up periodically, so it's restored to the latest available backup, not an arbitrary instant.

Pending validation

The specific RPO and RTO targets applicable to your service are agreed in your contract. We don't publish generic figures, so as not to misrepresent a commitment that depends on your plan and your needs.