Persistence and backups
Durability on Valkey is a property of the instance's purpose, set at creation:
Durability on Valkey is a property of the instance's purpose, set at creation:
- Cache instances keep data in memory only. A restart starts empty. This is the honest shape for data you can rebuild — there is nothing to back up.
- Store instances persist to disk and can be backed up. The rest of this page is about them.
How a store persists
A store instance writes both a periodic snapshot and an append-only log of writes to its storage volume. After a restart, the node replays them and comes back with its data — this is what makes a single-tier store viable, and what replicas on the HA and sharded tiers recover from.
You size the volume with the storage setting (in GB, per node, billed per region). Size it comfortably above your memory setting — the snapshot and the append-only log together need room to grow between compactions.
Backups
Store instances can take scheduled backups. They are free — enabled with a toggle, no separate charge:
- Schedule — a cron expression; the default takes one snapshot daily at 02:00.
- Retention — the last seven days of snapshots are kept.
- Scope — each region's copy is backed up independently, like everything else about a multi-region instance.
Backups are snapshots, not a continuous log: the recovery point is your backup interval. There is no point-in-time recovery — with the default daily schedule, a restore returns the instance to some point in the last 24 hours.
Every snapshot is listed on the instance's Backups tab in the console — snapshot time, region and size — and from the CLI with reis valkey:backups <instance-id>.
Restoring
Restores are self-service, from the console or the CLI. Pick a snapshot on the instance's Backups tab and choose Restore, or run:
reis valkey:restore <instance-id> --region falkenstein-1 --snapshot 2026-08-13T03:00:04ZWhat to know before you restore:
- A restore overwrites. The region's current data is replaced with the snapshot; writes made since that snapshot are lost. The console asks you to confirm for exactly that reason.
- Same region. A snapshot restores into the region it was taken in — each region's copy is independent, so restoring one region leaves the others untouched.
- Sharded instances need a matching shard count. A snapshot taken at three shards restores into three shards. If you have grown the instance since, raise a support ticket instead.
- Restores run one at a time, in order, and briefly restart the region's nodes. Progress appears in the project's deployments.
If you need anything beyond this — a cross-region restore, or a snapshot from an instance that no longer exists — raise a support ticket and our team will help.
What deletion means
Deleting an instance deletes its data and its volume. For store instances, backups taken before deletion are the recovery path — which is why the console asks you to confirm, and why noeviction is the store default: the platform never silently discards store data, whether by eviction or by teardown.
Sizing guidance
| Setting | Guidance |
|---|---|
| Memory | The working set plus headroom. From 256 MB to 16 GB per node. |
| Storage | At least a small multiple of memory, so persistence never competes with your data for space. |
| Backups | Turn them on for anything you would mind losing. They are free — the only reason to leave them off is data you could rebuild anyway, and that data probably belongs in a cache instance. |