Redis persistence and high availability: RDB, AOF, replicas and Sentinel

Redis serves everything from RAM, which is why it is fast. Persistence decides what survives a restart or crash, and replication decides what happens when a whole server is gone. They solve different problems, and you usually want both.

RDB snapshots

RDB writes a compact point-in-time copy of the whole dataset to one file, dump.rdb by default, in the directory set by dir. To do it, Redis forks a child process that writes the file while the parent keeps serving clients. Snapshots run on a schedule of save rules (“after N seconds if at least M keys changed”) or on demand.

# redis.conf
save 3600 1 300 100 60 10000   # the default rules, written out
dbfilename dump.rdb
dir /var/lib/redis

redis-cli BGSAVE                       # snapshot now, in the background
redis-cli INFO persistence | grep rdb_  # status of the last save
redis-cli CONFIG GET dir                # where the file is written

• Good: one compact file, ideal for backups and copying to another site; faster restarts with big datasets than AOF.
• Cost: you lose everything written since the last snapshot if Redis stops uncleanly, typically minutes of data. On large datasets the fork itself can pause the server for milliseconds, or up to a second on slow hardware.

AOF: the append-only file

With AOF, Redis logs every write command and replays the log at startup. Durability depends on appendfsync:

• always: fsync after every write batch. Safest and very slow.
• everysec: fsync once per second. The default and recommended setting; you lose at most about one second of writes.
• no: leave flushing to the operating system. Fastest, least safe.

# redis.conf
appendonly yes
appendfsync everysec
appenddirname "appendonlydir"

The log grows forever, so Redis rewrites it in the background into the shortest form that rebuilds the current data (BGREWRITEAOF, or automatically). Since Redis 7.0 the AOF is split into a base file and incremental files in its own directory, tracked by a manifest.

Do not switch a server that holds data from RDB to AOF by just editing redis.conf and restarting: Redis would start from the new, empty AOF and you lose the dataset. Enable it live with CONFIG SET appendonly yes, wait for the rewrite to finish (aof_rewrite_in_progress:0 in INFO persistence), then persist the setting with CONFIG REWRITE.

Which should you use?

• Pure cache that can be refilled from the source: persistence can be off, or RDB only for faster warm-up.
• Data you care about, a few minutes of loss acceptable: RDB alone.
• Data loss should be as small as possible: RDB and AOF together. The Redis documentation recommends this combination and discourages AOF alone, because RDB files are better for backups and faster restarts. When both are on, Redis loads the AOF at startup because it is the more complete.

Backups

Copying dump.rdb while Redis runs is safe: a new snapshot is written under a temporary name and renamed only when complete. Copy it on a schedule (for example hourly and daily, deleting old copies) and move at least one copy off the machine every day. Copying the AOF directory needs automatic rewrites paused during the copy; the persistence page describes the steps. redis-cli --rdb /backup/dump.rdb can also pull a snapshot over the network.

Replication

A replica keeps an exact copy of a primary and reconnects by itself when the link breaks. Configure it on the replica:

# replica's redis.conf
replicaof 10.0.0.11 6379
masterauth CHANGE_ME          # if the primary requires a password
replica-read-only yes         # the default

redis-cli INFO replication
redis-cli ROLE

• Replication is asynchronous: the primary does not wait for replicas, so a failover can lose the most recent writes. WAIT reduces that risk but does not make Redis strongly consistent.
• min-replicas-to-write and min-replicas-max-lag make the primary refuse writes when too few replicas are in sync, which limits the window of loss.
• Keep persistence enabled on the primary. A primary without persistence that restarts automatically comes back empty, and its replicas then sync to that empty dataset and wipe their copies. If you must run without persistence, disable automatic restarts.

Sentinel: automatic failover

Redis Sentinel watches a primary and its replicas. It monitors them, sends notifications, promotes a replica when the primary fails, and tells clients the address of the current primary. Sentinels listen on TCP port 26379 by default.

# sentinel.conf on each Sentinel host
sentinel monitor mymaster 10.0.0.11 6379 2

redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

The last number, the quorum, is how many Sentinels must agree the primary is unreachable before a failover starts; the failover itself also needs a majority of all Sentinels to authorize it. Run at least three Sentinels on separate machines, and use a client library that asks Sentinel for the primary instead of hard-coding an address. Sentinel gives high availability for one dataset; to spread data over many primaries you need Redis Cluster instead.

Official documentation

• Redis docs: Persistence
• Redis docs: Replication
• Redis docs: High availability with Sentinel