How to back up a Valkey Docker container (2026)
Backing up Valkey safely means one rule: dump, don't copy. `valkey-cli SAVE # then capture the resulting dump.rdb` produces a consistent, restorable dump from the running container, which restic then encrypts off-site. a SAVE/BGSAVE forks a point-in-time RDB snapshot to disk, so you back up the finished dump.rdb (plus the AOF if enabled) rather than volatile in-memory state. Anything that copies /data live risks an unrestorable backup.
What Dockstash detects
| Env keys detected | VALKEY_PASSWORD, VALKEY_ARGS, REDIS_PASSWORD |
|---|---|
| Default port | 6379 |
| Live data paths (never copied live) | /data, /data/dump.rdb, /data/appendonly.aof |
| Example images | valkey/valkey:8, valkey/valkey:7, valkey/valkey |
Back up Valkey with Dockstash, step by step
Create your Dockstash account and open the dashboard
Sign up free at app.dockstash.com/register. The one-time setup wizard asks for your storage VPS (the machine that will hold the encrypted backups) and generates an encryption password — save that password in a password manager immediately, it is shown exactly once.
Add the Docker project that runs Valkey
On the Projects screen Dockstash auto-detects every Compose project folder on the server (by default under /var/www). Pick the project that contains your Valkey service. Nothing is backed up yet — you are just telling Dockstash where the project lives.
Check that Valkey was detected
Open the project and look at the Plan tab. Dockstash reads docker-compose.yml, recognizes the valkey/valkey image, and adds a database layer with the right save-and-capture strategy — plus the container name it resolved and the env keys it found (VALKEY_PASSWORD, VALKEY_ARGS, and the legacy REDIS_PASSWORD). You can toggle files, databases, and proxy configs on or off before saving.
Optional: sanity-check the snapshot by hand
If you want proof before automating, trigger the same save Dockstash will trigger: run valkey-cli BGSAVE inside the container. Valkey replies "Background saving started", forks, and writes a point-in-time dump.rdb in /data — the same RDB persistence it inherited from Redis. That finished file is what gets backed up, never the live in-memory state.
docker exec <valkey-container> valkey-cli BGSAVEConfirm your storage destination
Backups are stored as encrypted restic snapshots on your own storage VPS over SSH. If you completed the setup wizard this is already configured; you can change host, user, port, or the SSH key any time under Settings → Storage.
Set a backup schedule
On the project’s Schedule tab pick daily, weekly, or a custom cron expression (validated inline). For Valkey used as a primary store (queues, sessions), daily is a sane floor and hourly is common. Add a weekly prune schedule with your retention policy so old snapshots are trimmed automatically.
Run the first backup now
Click Backup Now on the project card. Dockstash triggers a background save, waits for the finished dump.rdb, then backs it up — along with appendonly.aof when AOF persistence is enabled — straight into restic. You can watch the live restic output line by line in the log panel while it runs.
Confirm the snapshot exists
When the run finishes, the project card shows the new last-backup time, snapshot count, and repository size. Open the Snapshots screen and you will see the restore point in the timeline — that is your proof the backup landed off-site.
The dump command
valkey-cli SAVE # then capture the resulting dump.rdbThe restore command
place dump.rdb in the data dir and start valkey-servera SAVE/BGSAVE forks a point-in-time RDB snapshot to disk, so you back up the finished dump.rdb (plus the AOF if enabled) rather than volatile in-memory state.
Restore a Valkey backup and prove it works
A Valkey backup is only real once it has restored. Dockstash restores never overwrite your live instance by default — you restore to a fresh location first, check the data, and promote it deliberately.
Pick a restore point
Open Snapshots, select the project, and browse the timeline of restore points. Each row contains a complete point-in-time dump.rdb (plus the AOF when enabled) and the project files captured in the same run.
Restore to a new location
Click Restore and keep the default "Restore to new location" mode. Type the project name to confirm — this is a deliberate, typed-confirm action. The RDB and files land in the target path you choose, leaving the live instance untouched.
Verify the restored data
Place the restored dump.rdb in the data directory of a scratch Valkey container and start it — Valkey loads the RDB at startup. Run valkey-cli PING and you should get PONG back, then spot-check the keys your app depends on with DBSIZE and a few GETs.
docker exec <valkey-container> valkey-cli PINGPromote when satisfied
Once the restored data checks out, point your app at it (or repeat the restore with "Overwrite existing" — an explicit opt-in — and restart the live container so it loads the restored RDB). Better: let the weekly restore drill do this proof automatically so a restore is never your first rehearsal.
Gotchas to avoid
- As with Redis, never grab a dump.rdb mid-rewrite — trigger SAVE/BGSAVE first and back up the finished file.
- valkey-cli is the client binary; on some compatibility images redis-cli is symlinked, so Dockstash detects whichever is present.
- Enable and capture the AOF when you need the freshest writes; the RDB alone can trail behind.
Common Valkey backup problems
- Symptom
- The restored dump.rdb fails to load with a truncated-file or short-read error.
- Cause
- The RDB was copied while Valkey was still rewriting it — the same mid-rewrite hazard as Redis, since Valkey keeps the identical RDB persistence model.
- Fix
- Always trigger SAVE or BGSAVE and wait for it to finish before capturing dump.rdb. Dockstash does exactly this: it triggers the save, waits for completion, then backs up the finished file.
- Symptom
- A manual test with redis-cli works but valkey-cli reports "not found" (or the other way around).
- Cause
- The client binary differs by image: official valkey/valkey images ship valkey-cli, while some compatibility images symlink redis-cli instead.
- Fix
- Use whichever binary the image ships — the protocol and commands are the same. Dockstash detects whichever client is present in the container automatically, so backups work either way.
- Symptom
- You placed the restored dump.rdb in /data but the running Valkey still serves old data.
- Cause
- Like Redis, Valkey only reads the RDB at startup — you cannot hot-swap dump.rdb into a running instance. And if appendonly is enabled, the AOF takes precedence at startup and the RDB is ignored.
- Fix
- Stop the container, place the restored dump.rdb (and AOF, if you restored one) in the data directory, then start it again. If you restored only an RDB into an AOF-enabled setup, temporarily set appendonly no for the first start, then re-enable it.
- Symptom
- A restore succeeds but the most recent writes are missing.
- Cause
- AOF persistence is enabled and the appendonly.aof held newer writes than the RDB snapshot — the RDB alone trails behind.
- Fix
- Back up both files. Dockstash captures /data/dump.rdb and appendonly.aof together in the same run so the restore point includes the freshest writes.
Do it in one click with Dockstash
Dockstash runs the exact dump above, restics it off-site, and drill-tests the restore automatically — no script to maintain.
Last updated: July 2026
Frequently asked questions
How is backing up Valkey different from Redis?
It is not, meaningfully. Valkey forked from Redis and keeps the same RDB and AOF persistence model. The only practical difference is the client binary name (valkey-cli), which Dockstash detects automatically.
Can I restore a Redis RDB into Valkey?
Yes for current versions — the RDB format is shared across the fork point. As the projects diverge, keep restores within the same engine to be safe.
Does Dockstash detect Valkey automatically?
Yes. The valkey/valkey images and the valkey-cli binary are recognized, and both VALKEY_PASSWORD and the legacy REDIS_PASSWORD env keys are picked up.
Should I capture the AOF as well?
If appendonly is enabled and you cannot afford to lose the most recent seconds of writes, yes. Dockstash backs up both the RDB and the AOF files.
How often should I back up Valkey?
Match the schedule to what Valkey holds. For queues and sessions, hourly is a common choice; for slower-moving data, daily is fine. On the Free plan backups are manual (Backup Now); Pro allows schedules up to hourly, Business any cron expression.
Where do the backups actually live?
On your own storage VPS, as encrypted restic snapshots pushed over SSH. Dockstash never holds your data on a third-party cloud — you point it at a box you control, and the repository is encrypted with a password only you have.
How do I know a Valkey backup actually restores?
Schedule a restore drill. Dockstash restores the latest snapshot into an isolated scratch workspace, byte-hashes every file against the source, and verifies the captured dump — then stamps a pass/fail badge on the project. A weekly drill means you always have fresh proof.