# 21 Business continuity, disaster recovery and backup policy

| | |
| --- | --- |
| Version | 0.1 draft |
| Owner | Infrastructure Owner |
| Review | Yearly, and after every disaster recovery exercise |
| Applies to | Every in-scope service and its data |

## Recovery objectives

Set per service. Publish to customers only what the exercise has measured.

| Service | RTO (time to restore) | RPO (data loss accepted) | Measured in last exercise |
| --- | --- | --- | --- |
| Gate | [4 hours] | [24 hours] | [not yet] |
| Mail | [8 hours] | [24 hours] | [not yet] |
| Drive | [8 hours] | [24 hours] | [not yet] |
| Meet | [4 hours] | n/a (no stored state beyond recordings) | [not yet] |
| Writer, Sign, Bills | [8 hours] | [24 hours] | [not yet] |
| RM Cloud | per client contract | per client contract | [not yet] |

## Backups

1. Every in-scope database is backed up at least daily (AVL-03). Write-heavy databases add continuous archiving (WAL) where the RPO needs it.
2. Backups are encrypted before leaving the host and stored in **a separate account and a separate region** from production, with versioning and deletion protection. A backup that lives only on the machine it protects is not a backup.
3. Object storage (Drive files, uploads) is versioned or replicated to the backup account.
4. Retention: 30 daily, 12 monthly, consistent with the [retention defaults](/playbook/02-universal-baseline). Deletion requests propagate to backups within the stated window, or on restore.
5. Backup failure alerts a human (OPS-02).
6. The backup inventory lists each data store, its backup job, destination, encryption key reference and last successful run.

## Restore testing

1. Monthly, the latest backup of each in-scope database is restored into a scratch environment and verified by row counts against production and by booting the application against it (AVL-04). The record keeps the backup timestamp, restore duration, and result.
2. A backup that has never been restored is treated as untested and does not count toward the RPO.

## Disaster recovery

1. Scenarios planned for: loss of the production host or region, loss of the database, compromise of the cloud account, loss of the edge provider account, loss of the source host, loss of a key person.
2. Recovery runbooks per service: rebuild infrastructure from code, restore data from backup, re-point DNS, verify.
3. Yearly exercise: rebuild at least one service end to end in a clean environment and measure RTO and RPO (AVL-05).
4. Credentials needed during a disaster (cloud root, registrar, Cloudflare, backup account, break-glass) are reachable without the production systems, held by at least two people.

## Business continuity

- At least two people can deploy, restore and operate every in-scope service. Knowledge that exists only in one head, or only in an AI agent's memory files, is written into the runbooks.
- Customer communication during an outage uses a status page or channel that does not run on the affected infrastructure.