Redis Backup and Restore
A backup is a safe copy of your Redis data stored away from the running server. Persistence protects data during a restart, while a backup protects it from deleted files, broken disks, and human mistakes. A tested backup plan lets you recover quickly when something goes wrong.
The Photo Album Analogy
Persistence works like the memory in your head. It keeps the picture while you stay in the room. A backup works like a photo album stored in a different house. A fire in the first house leaves the album untouched. Redis backups follow the same idea: copy the data and keep the copy elsewhere.
Redis Server Backup Storage ┌────────────────┐ copy ┌──────────────────┐ │ dump.rdb │ ───────────► │ dump-2026-06-10 │ │ appendonlydir │ ───────────► │ aof-2026-06-10 │ └────────────────┘ └──────────────────┘ (same machine) (different machine or cloud)
Backing Up an RDB Snapshot
An RDB file is a compact snapshot of all data at one moment. Ask Redis to create a fresh one in the background with BGSAVE.
127.0.0.1:6379> BGSAVE Background saving started 127.0.0.1:6379> LASTSAVE (integer) 1718003600 127.0.0.1:6379> CONFIG GET dir 1) "dir" 2) "/var/lib/redis"
LASTSAVE returns the time of the last successful save as a Unix timestamp. Compare it before and after BGSAVE to confirm the new snapshot finished. CONFIG GET dir shows where the file lives.
Once the save completes, copy the file to safe storage.
$ cp /var/lib/redis/dump.rdb /backup/dump-$(date +%F).rdb
RDB files are safe to copy at any time because Redis writes a new file first and renames it into place.
Backing Up the AOF
Redis 7 and later store the append-only log as a folder named appendonlydir with several files inside. Copy the whole folder, not a single file.
$ cp -r /var/lib/redis/appendonlydir /backup/aof-$(date +%F)
Pause automatic rewrites during the copy if your workload is heavy, or copy from a replica to avoid load on the main server.
Choosing Between RDB and AOF Backups
Backup Type Strength Weakness ──────────── ───────────────────────────── ───────────────────────── RDB Small file, fast to restore Loses changes since the snapshot AOF Very little data loss Larger files, slower restore Both Strongest protection More storage and care
Restoring from an RDB Backup
1. Stop the Redis server. 2. Delete or move the old dump.rdb. 3. Copy the backup file to the data folder as dump.rdb. 4. Check file ownership so the redis user can read it. 5. Start the Redis server. 6. Run DBSIZE and a few GET commands to verify the data.
$ sudo systemctl stop redis $ sudo cp /backup/dump-2026-06-10.rdb /var/lib/redis/dump.rdb $ sudo chown redis:redis /var/lib/redis/dump.rdb $ sudo systemctl start redis
When appendonly is set to yes, Redis loads the AOF at start-up and ignores the RDB file. Restore the AOF folder in that case, or switch appendonly to no for the restore and enable it again afterward.
A Simple Daily Backup Script
#!/bin/bash redis-cli BGSAVE sleep 30 cp /var/lib/redis/dump.rdb /backup/dump-$(date +%F).rdb find /backup -name "dump-*.rdb" -mtime +14 -delete
Schedule the script with cron every night. The last line removes copies older than 14 days.
Practical Example – Recovering from a Mistake
10:00 A developer runs FLUSHALL on the production server by mistake. 10:02 The team stops Redis and finds last night's backup. 10:05 They copy dump-2026-06-10.rdb into place and start Redis. 10:06 The shop returns with data from 02:00. Lost: Changes made between 02:00 and 10:00. Fix: Add hourly backups to shrink the gap.
Backup Habits That Save Projects
- Store copies on a different machine or cloud storage.
- Keep several days of history, not only the latest copy.
- Restore a backup on a test server every month to prove it works.
- Encrypt backups that contain private data.
Key Points
- Persistence and backups solve different problems.
- BGSAVE creates a snapshot and LASTSAVE confirms it.
- Copy RDB files and the full AOF folder to separate storage.
- Restore by stopping Redis, replacing files, and starting Redis again.
- An untested backup offers no guarantee.