# Backups and recovery

Automated snapshots, retention tiers, and restoring a snapshot into a new instance.

Instances are backed up for you: snapshots run on a schedule and are kept under a retention policy.

There is nothing to install or script, and the same mechanism applies on Start and Scale. A restore creates a new instance from a chosen snapshot.

Snapshots live inside the platform. They are not files you can download, copy to your own object storage, or open locally. For a portable copy, see [Import and export](/docs/manage/instances/import-and-export.md).

## Where backups are managed

Open the instance in [SurrealDB Studio](https://app.surrealdb.com), then go to **Instance settings → Backups**.

![The Backups tab of instance settings in SurrealDB Studio, listing one automatic backup taken on 17 August 2026 at 5:58 PM with a Create from selected button, a Backup frequency section set to once a day with a note that configurable frequency is available on Scale instances, and a Retention policy section listing daily, weekly, and monthly snapshot tiers.](~/assets/img/surrealdb/manage/instance-backups.webp)

The tab has three parts:

- **Available backups:** the list of snapshots you can restore from.
- **Backup frequency:** how often a new snapshot is taken.
- **Retention policy:** how long each snapshot is kept.

## Frequency and retention

Automated snapshots run daily by default. Configurable backup frequency is available on Scale instances. On other instance types the schedule is fixed.

Retention is tiered, and each tier is kept for its own period.

| Tier | When the snapshot is taken | Retention setting |
| --- | --- | --- |
| **Daily** | Every day | The number of days of daily snapshots kept |
| **Weekly** | Each Sunday | The number of weeks of weekly snapshots kept |
| **Monthly** | The first of each month | The number of months of monthly snapshots kept |

Which tiers you can change depends on the instance type. Tiers that are fixed on your plan are shown but not editable.

Longer retention lets you recover from further back and increases storage cost. Set it against your actual recovery objectives rather than taking the maximum. If you need more retention than the plan allows, [contact support](/docs/manage/organisations/support.md).

## Taking a backup before a risky change

Take an on-demand snapshot before anything you might want to undo, such as a major version upgrade, a schema migration, or a bulk delete. On-demand snapshots appear in the same list as scheduled ones and follow the same retention.

`surrealctl instance backup` triggers one from a terminal, which is what you want in a deployment pipeline that runs a migration. See [surrealctl instances](/docs/manage/surrealctl/instances.md).

## Restoring from a snapshot

A restore produces a **new instance**. The original is left untouched, and there is no in-place restore.

1. Open **Instance settings → Backups** on the source instance.
2. Select the snapshot you want.
3. Select **Create from selected**.

That opens the [deploy flow](/docs/manage/instances/create.md) with the snapshot already chosen as the starting data. You can reach the same result from the other direction: start a new deploy and pick **Restore from backup** as the data source.

Because the result is a new instance, cutting over is an application change. The new instance has its own name and endpoint. Verify the data before you repoint traffic, then [delete](/docs/manage/instances/configure.md#delete-an-instance) or [pause](/docs/manage/instances/configure.md#pause-an-instance) the old instance.

Three constraints apply to a restore:

- The new instance must be in the **same region** as the source.
- Its **storage size** must be at least as large as the size of the source.
- Its **SurrealDB version** must be compatible with the snapshot. The deploy form only offers versions that are.

## What backups do not cover

- **They are not portable.** You cannot download a snapshot. It is not an archival format, not a way to seed a local development database, and not a route to another provider. Use [`surreal export`](/docs/reference/cli/surrealdb-cli/commands/export.md) for those cases. See [Import and export](/docs/manage/instances/import-and-export.md).
- **They are not cross-region disaster recovery.** A snapshot restores into the region it was taken in. Recovering into a different region needs a logical export and import.
- **They are not a substitute for testing a restore.** Restore into a throwaway instance periodically and check that the data is what you expect. That is the only way to know the recovery path works.

## Related pages

- **[Import and export](/docs/manage/instances/import-and-export.md):** portable data with `surreal export` and `surreal import`.
- **[Versions and upgrades](/docs/manage/instances/versions-and-upgrades.md):** snapshot first, then upgrade.
- **[High availability](/docs/manage/instances/high-availability.md):** what redundancy covers and what backups cover.