Disaster recovery policy
How we restore OBMr after losing systems or data.
Targets
| Measure | Target |
|---|---|
| Recovery point: most data we could lose | 24 hours, or less where the database provider offers point-in-time recovery |
| Recovery time: longest the app is down | 8 hours |
These targets depend on backups that Netlify, Inc. (Netlify Database) provides. They are not met until the backup setup is confirmed and a restore has been tested.
What can be rebuilt from where
| Part | Source of recovery |
|---|---|
| Application code, database schema, legal pages | The Git repository, which holds everything needed to rebuild and redeploy |
| Customer Data | Database backups from Netlify, Inc. (Netlify Database), backup frequency and retention |
| Secrets (database address, two-step encryption key) | The password manager. Losing the two-step encryption key means every administrator sets up two-step sign-in again; no customer data is lost |
| Domain and DNS | The registrar account, managed by two people |
Restoring
- Declare a disaster and name a lead. Tell customers.
- Create a new database from the latest good backup, in the same region.
- Apply the schema from the repository; it refuses to run if the database does not match what was recorded.
- Point the hosting environment at the new database and redeploy.
- Re-run erasures for any organization erased after the backup was taken, using the erasure register kept outside the database.
- Check sign-in, a read and a write for a test organization, and the activity log.
- Tell customers what was restored and the time of the backup used, so they can re-enter anything recorded after it.
Testing
A full restore into a separate environment is done before the first paid customer and then every 3 months, timed against the targets above, and recorded.