Keeping Redis Safe and Always On
This tutorial covers all of it: saving to disk, backups, replication, high availability, and scaling out.
How Redis Saves to Disk — RDB vs AOF
Redis lives in memory, but it can write to disk so data survives a restart. There are two ways. RDB takes a snapshot of everything every so often. AOF writes down every change command as it happens. You can use one, the other, or both together.
RDB saves a full picture now and then. AOF logs every write as it happens, so it loses less on a crash but the file is larger.
| Small file, fast restart |
| Great for backups |
| Can lose recent writes |
| Snapshot uses some CPU/RAM |
| Loses at most ~1 second |
| Bigger file, slower restart |
| Rewritten to stay compact |
| Safer for durability |
# redis.conf — RDB: snapshot if enough changes happened in a time window
save 900 1 # after 900s if at least 1 key changed
save 300 10 # after 300s if at least 10 keys changed
save 60 10000 # after 60s if at least 10000 keys changed
# AOF: log every write; sync to disk about once a second
appendonly yes
appendfsync everysec
# trigger a snapshot or rewrite the AOF by hand (runs in the background)
BGSAVE
BGREWRITEAOFTurn on AOF for safety (lose at most a second), and keep RDB snapshots for quick backups and fast restarts. On restart, Redis rebuilds from the AOF because it is the most complete. If you use Redis purely as a cache you can rebuild, you may turn persistence off entirely.
Backups and Recovery
A backup is just a safe copy of the RDB file. Because dump.rdb is a single file,
backing up is a copy, and restoring is putting that file back and starting Redis.
# 1) make a fresh snapshot in the background
redis-cli BGSAVE
# 2) find where Redis keeps the file, then copy it away
redis-cli CONFIG GET dir # e.g. /var/lib/redis
cp /var/lib/redis/dump.rdb /backups/dump-$(date +%F).rdb
# 3) to restore: stop Redis, drop the backup in place, start again
sudo systemctl stop redis
cp /backups/dump-2026-09-20.rdb /var/lib/redis/dump.rdb
sudo systemctl start redisA backup on the same disk as Redis is not safe — if the disk dies, both are gone. Copy the RDB to another machine or to cloud storage. And keep a few older copies, in case a bad write got into the newest one.
Replication — Primary and Replica
Replication keeps one or more copies of your data on other servers. The primary takes all the writes and streams every change to its replicas. Replicas are read-only copies. This gives you a spare copy and lets you spread reads across servers.
Writes go to the primary. The primary copies every change to its replicas. Reads can be served by any replica.
# on the replica server: point it at the primary
REPLICAOF 10.0.0.1 6379
# (or in redis.conf: replicaof 10.0.0.1 6379)
# check the link and how far behind the replica is
INFO replication
# role:master / role:slave, connected_slaves, master_repl_offset ...The primary does not wait for replicas before replying to a write. So a replica can be a tiny bit behind, and a write can be lost if the primary dies at the wrong instant. Replicas give you spare copies and read scaling — they do not by themselves make failover automatic. For that, add Sentinel.
High Availability with Redis Sentinel
If the primary dies, someone must promote a replica to take its place — fast, and without a human at 3am. That someone is Sentinel. Sentinels are small watchdog processes that watch the primary, agree when it is truly down, and promote a replica automatically.
Several sentinels watch the primary. When enough agree it is down (a quorum), they pick a replica and promote it to the new primary. Clients are pointed at the new one.
# sentinel.conf — watch a primary called "mymaster", quorum of 2
sentinel monitor mymaster 10.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
# start a sentinel
redis-sentinel /etc/redis/sentinel.conf
# apps ask Sentinel for the current primary address (it may change after a failover)
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymasterUse an odd number, three or more, on separate machines. A quorum stops a single confused sentinel from starting a needless failover. Your app should connect through a Sentinel-aware client so it always finds the current primary, even after it changes.
Scaling Out with Redis Cluster
One server can only hold so much data and handle so many writes. Redis Cluster
splits the data across many primaries. It divides the keyspace into 16,384 hash
slots, and each node owns a range of slots. A key's slot is decided by
CRC16(key) mod 16384, so every client can work out which node holds a key.
A key is hashed to a slot number, and the slot belongs to one node. Here key user:57
lands in slot 8492, which node B owns.
# build a cluster: 3 primaries + 1 replica each (6 nodes)
redis-cli --cluster create \
10.0.0.1:6379 10.0.0.2:6379 10.0.0.3:6379 \
10.0.0.4:6379 10.0.0.5:6379 10.0.0.6:6379 \
--cluster-replicas 1
# which slot does a key map to, and see the slot layout
CLUSTER KEYSLOT user:57 # -> 8492
CLUSTER SLOTS
# keep related keys on the same node with a hash tag {..}
MSET {user:57}:name "Asha" {user:57}:cart "..."
# only the part in {} is hashed, so both land in the same slot
In a cluster, a command that touches several keys (like MGET or a transaction)
only works if those keys live in the same slot. Use a hash tag — put a
shared part in braces, like {user:57}:name and {user:57}:cart —
so related keys land together.
Which Setup Do You Need?
Golden Rules
CRC16(key) mod 16384. Use it when one server is not enough.
{ } so related
keys share a slot and multi-key commands keep working.