OrthıD
Browse the docs
Operations

Backups & continuity

3verest backs up your sovereign cell for you: encrypted, in-region copies of everything durable, and restores that are rehearsed before you ever need them. With BYOK, those backups are encrypted with keys you control.

A backup is only as good as the last time it was restored. On the managed service, 3verest owns both halves: it captures your cell’s durable state on a schedule and regularly rehearses the restore so a real incident is a checklist, not an improvisation. You do not run any of it.

What is protected

Your sovereign cell has three pieces of durable state:

  • Database. The system of record - users, organisations, sessions, RBAC, and the tamper-evident audit log. Tenant boundaries are preserved by row-level security and carried through every backup.
  • Object storage. Larger blobs that do not live in the database: profile media, exported audit archives and signed document bundles.
  • Keys. The signing and encryption key material. With BYOKthis lives in your own KMS or HSM, under your control; otherwise OrthID’s managed keystore is captured alongside the database in the same window.
A data backup is useless without its keys
Records are encrypted at rest. A restore without the matching keys yields ciphertext no one can read. 3verest always captures key state in the same backup window as the database and stores it separately under stricter access. With BYOK, that key material stays in your provider. See BYOK.

Encrypted and in-region

Backups never leave your region. 3verest encrypts every copy and keeps it inside the same sovereign boundary as your cell, so residency holds for your backups exactly as it does for live data. Under BYOK, backups are encrypted with a key you control, which means even the backups are unreadable without your authorisation.

Retention

3verest keeps a sensible retention window as part of the service - for example nightly copies held for 30 days, with a weekly copy held longer for compliance. If your obligations call for a specific schedule, that is set with 3verest when your cell is provisioned.

Tested restores

Restore is the part that has to be rehearsed, so 3verest does it on a regular cadence against a throwaway environment, not against your live cell. Each drill restores the keys, then the database, then object storage, and verifies the result end to end:

  1. Provision a clean, isolated environment in the region.
  2. Restore the key state first, so decryption is available.
  3. Restore the most recent good database copy.
  4. Restore object storage to the matching bucket.
  5. Verify: sign in, verify a token, read the audit log, and confirm decrypted fields render correctly.
A backup nobody has restored is a guess
Because 3verest rehearses the restore on a fixed cadence and records the result, your continuity posture is something that has actually been exercised - not an untested assumption that fails when you need it most.

Next steps

  • Upgrades - a verified backup is taken before every upgrade.
  • BYOK - hold the encryption keys your backups depend on in your own KMS or HSM.
  • Regions - backups stay in the same sovereign region as your cell.