Restore a workspace safely

Before recoveryCopy Anchor Link

Identify the affected installation, incident, target recovery time and actual resource names. Obtain the encrypted backup, decryption identity, protected Worker keys and required R2 evidence objects.

Do not import over the live D1 database.

Restore sequenceCopy Anchor Link

1. Decrypt and restore into an isolated local or new D1 database.
2. Apply the migrations required by the selected application release.
3. Check tables, row counts, append-only triggers, audit checkpoints and retained evidence hashes.
4. Compare the restored result with the rehearsal fingerprint.
5. Update the API binding to the verified database and deploy through the approved operator procedure.
6. Verify managed sign-in, roles, checklist, evidence retrieval and report generation.

Keep the previous database and incident evidence until the recovery is accepted.

Source-managed toolingCopy Anchor Link

The repository's backup restore and verify scripts support a local rehearsal followed by a named new database. Configure their environment against your installation before running them.

A database restore does not restore Worker secrets, R2 objects or authenticators. Reconcile integrity leaves newer than the restored checkpoint before resuming checkpoint jobs; do not silently overwrite conflicting history.

See backup dependencies.