Continuity and Backups

Version 1.0, approved 2026-09-21. This page is deliberately short. Backups and a timed restoration have been performed and are described below; decision D10 says the recovery targets are proposals to be demonstrated, not commitments, and this page keeps that distinction.

Where the service runs

Component	What it is	Where
Application	One container image, built and tested in CI, run behind a Caddy reverse proxy that terminates TLS and caps request size	Contabo (Contabo Inc.), US-East region — New York, United States
Database	PostgreSQL 17 — every record, and the job queue	Same host, in its own container; not a managed service
Object store	MinIO — every file	Same host, in its own container
Email, billing	Providers on the subprocessors page	Theirs

A staging environment exists that cannot reach production data, and a preflight check refuses to deploy if any shared resource is detected.

Encryption at rest

The application encrypts integration tokens itself (AES-256-GCM, key in the environment). The hosting provider does not encrypt this server's volumes, so the database and object store are not encrypted at rest beyond that application-level encryption; access to them is by the application's own credentials and the host's key-only SSH. Every backup bundle is encrypted before it leaves the host.

Backups

Once a day, the database, every stored file, the configuration that holds the encryption keys, and the signing certificate are written into a single bundle, encrypted with a key that is kept apart from the systems it protects, checksummed file by file, and copied to storage away from the host — Backblaze B2 object storage in Backblaze's US-East region, a different provider from the host. A backup that does not complete, or does not reach that storage, pages the on-call person.

How long backup copies are kept — which is also how long deleted data can persist in a backup — is published in the retention policy: 35 days for the off-host copy, 14 nightly copies on the host.

A restoration from a backup into an isolated environment has been performed and timed (2026-09-12). The restored copy was checked before being trusted: completed documents matched their recorded content hashes and their audit trails verified; signer links, templates and billing records were present; the copy held exactly the files and records the source held; and the copy was unable to send email or notifications.

Recovery targets

Proposed for the pilot, per decision D10:

Target	Proposed	Status
Recovery point (most data that could be lost)	24 hours	Demonstrated by the daily schedule; the drill restored a bundle minutes old
Recovery time (how long the service could be down)	4 hours	Demonstrated only at drill scale (seconds, on a small dataset). Not yet demonstrated at production size; not promised until it is

Decision D10's rule is that if a drill cannot meet a target, the target published here is revised — not the drill. Until a production-sized drill has run, the recovery time above is a target, not a promise.

Service continuity for signers

Signing links do not expire because the service was briefly unavailable; a recipient who could not sign during an outage can sign when it returns. Background work — sending, stamping, archiving, webhooks — is queued durably in the database, so an interrupted job resumes rather than being lost.

If eScryber ceased operating

Organisations would be given notice of at least 90 days to export their data using the export described in the deletion and export policy, after which data would be deleted as that policy describes.

Status

A service status notice is shown on the sign-in page during an incident; see the incident response policy.