---
title: Setting Up and Restoring From Backups
summary: Turn on snapshots and off-site replication, issue and verify a Recovery Kit, and restore an instance step by step.
date: 2026-09-10
---

# Setting Up and Restoring From Backups

Turn on snapshots and off-site replication, issue and verify a Recovery Kit, and restore an instance step by step.

See [Backups That Survive Losing the Machine](/en/docs/features/backup-recovery) for what each piece is and why. This is the walkthrough for actually turning it on, and for restoring when you need to.

## 1. Take a snapshot

From **Settings → System**, create a snapshot. This alone is worth doing even before you set up anything below: it captures your database, configuration, and platform state as of that moment.

## 2. Turn on off-site replication (optional, recommended)

Still in **Settings → System**, under Off-site Replication:

1. Choose a provider and enter its endpoint, region, bucket, and access key ID and secret.
2. Run **Test connection** first. It writes and deletes a small marker object using the exact permissions replication needs; saving stays locked until this passes.
3. Enable replication after each snapshot.

Enabling replication automatically issues a Recovery Kit at the same time; you're not done until you've also completed step 3.

## 3. Download and verify the Recovery Kit

Downloading the kit is not enough on its own. Enter the verification code printed inside the downloaded file back into the settings page. Only a verified kit can actually restore a snapshot on different hardware, and only a verified kit unblocks a future key rotation. Store the file itself somewhere that survives losing the server: a password manager or a vault, not the machine it protects.

## 4. Restoring an instance

Restore runs from its own screen, reachable from the sign-in page ("Restore from backup"), in four steps:

1. **Confirm you're an administrator.** Restoring replaces the entire database, so it requires an instance administrator's email and password, not just any account.
2. **Select the snapshot file.**
3. **Add your Recovery Kit, if this backup came from a different machine.** A backup is normally only readable by the machine that made it. If you're restoring on new hardware, you need two files together, neither works alone: the `.keys` file that sits next to the archive in your bucket, and the Recovery Kit `.json` file you downloaded in step 3 above. Restoring on the same machine that made the backup doesn't need either.
4. **Review and confirm.** You have to explicitly confirm that this permanently replaces all current data with the snapshot's contents before it proceeds.

A failed restore aborts before anything is swapped in; the system you started with is untouched, and the previous database is retained until the next restore attempt. A successful restore signs you out; log back in with your credentials once it finishes.

### If the restore reports it was "degraded"

This means the restore itself finished, but some configuration files couldn't be reapplied, and the instance is still using its previous encryption keys, so previously-stored credentials may not decrypt correctly. You can still continue to sign in; reconnect any integration that fails afterward from **Settings → Integrations**.

### If you see "Database unreachable"

This means the instance can't verify its own state, so restoring over the network is deliberately disabled as a safety measure. Recovering from this requires an operator with direct host access, following the disaster-recovery runbook rather than the normal restore screen.

## Related

- [Backups That Survive Losing the Machine](/en/docs/features/backup-recovery): what snapshots, replication, and the Recovery Kit are
- [Self-Hosting](/en/docs/guides/self-hosting): where this matters most, on infrastructure you're responsible for keeping running