Redis Persistence, Eviction Policies and Safe Operations

A clinic's patient portal stores login sessions in Redis. One morning the server running Redis is rebooted for patching, and every patient is logged out at once. Was that a bug? It depends entirely on whether anyone decided what should happen to the data on restart. Redis is a memory database first; persistence, memory limits and access control are all things you must configure on purpose.

Two ways Redis writes to disk

RDB takes point-in-time snapshots of the whole dataset into a compact file. Snapshots are triggered by save rules in the config (for example, after N changes within M seconds) or manually with BGSAVE, which forks a child process to write the file while the parent keeps serving. Restarts load the file quickly, and the file is a convenient backup unit. The cost: anything written since the last snapshot is lost on a crash.

AOF (append-only file) logs every write command. On restart Redis replays the log. The appendfsync setting controls how often the log is flushed to disk: always is safest and slowest, everysec (a common choice) risks about a second of writes, and no leaves the timing to the operating system. Redis rewrites the AOF in the background so it does not grow forever. Many deployments enable both, using the AOF to restore the freshest state and RDB files for backups.

# Persistence: AOF every second plus periodic snapshots
appendonly yes
appendfsync everysec
save 900 1
save 300 10

# Memory: cap Redis and decide what happens when the cap is reached
maxmemory 256mb
maxmemory-policy volatile-lru

# Network: do not listen on the public internet
bind 127.0.0.1
protected-mode yes

Default save rules and defaults for several settings differ between Redis versions, so state them explicitly in your config rather than trusting memory. Two operational notes: BGSAVE replies Background saving started and works by forking, which briefly increases memory use through copy-on-write when many keys change during the snapshot, so leave headroom. And none of this replaces a backup that has been restored at least once on another machine; an untested backup is a hope.

When memory runs out: eviction

Without maxmemory, Redis grows until the operating system intervenes. With it, Redis applies the configured maxmemory-policy when a write would exceed the limit. The default is noeviction, which rejects writes with OOM command not allowed when used memory > 'maxmemory'. That is the right behaviour for primary data and a nasty surprise for a cache you assumed would evict.

127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "noeviction"
127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-lru
OK
127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"

The first reply shows noeviction only if the server still has the default policy; if your instance was configured differently you will see that value. CONFIG SET changes the running server only: write the same setting in redis.conf or it reverts on restart. For the cache-design reasoning behind LRU and LFU, see Caching: Strategies, Eviction and Pitfalls.

Locking the door

A Redis instance reachable from the internet with no password is a standard way to leak data and lose a server, because Redis was designed to run inside a trusted network. Treat these as minimum requirements: bind to private interfaces, firewall the port, keep protected-mode on, require authentication and give each application the least access it needs with ACLs. Add TLS if traffic crosses networks you do not control.

127.0.0.1:6379> ACL SETUSER portal on >CHANGE_ME_TO_A_LONG_RANDOM_SECRET ~session:* -@all +get +set +del +expire +ttl
OK
127.0.0.1:6379> ACL WHOAMI
"default"

That user may only touch keys starting with session: and use five commands, so a bug or stolen credential in the portal cannot run FLUSHALL or read other applications' data. Store the real secret in your secrets manager, never in the repository. (ACL WHOAMI shows the user of the current connection; here it is still the default user until the client authenticates as portal.)

Watching a running instance

• Memory: INFO memory reports used_memory_human and, when set, the configured limit. Alert well before the limit, not at it.
• Slow commands: SLOWLOG GET 10 lists the slowest recent commands, which usually reveals an accidental KEYS, a huge LRANGE or HGETALL on an enormous hash.
• Big keys: redis-cli --bigkeys samples the keyspace and shows the largest key per type, and MEMORY USAGE key reports one key's size. Large keys cause latency spikes and slow deletes (use UNLINK instead of DEL to free them in the background).
• Persistence health: INFO persistence shows whether AOF is on and the status of the last save. Alert when a save fails.
• Hit rate: INFO stats includes keyspace_hits and keyspace_misses; the ratio tells you whether a cache is earning its memory.

Common mistakes and the symptoms they cause

• Assuming Redis is durable by default. Symptom: sessions or queued jobs vanish after a restart. Decide on AOF/RDB per instance, and keep truly critical data in a database.
• Leaving the default `noeviction` on a cache. Symptom: OOM command not allowed when used memory > 'maxmemory' errors in the application once the cache fills. Choose an eviction policy deliberately.
• No `maxmemory` at all. Symptom: the host starts swapping or the kernel kills the Redis process, which looks like a random crash.
• Exposing Redis to the public network without authentication. Symptom: unexpected keys or configuration changes, and eventually a compromised host. Bind privately, authenticate and use ACLs.
• **Running FLUSHALL, KEYS * or DEBUG on a shared instance.** Symptom: an outage caused by a well-meaning engineer. Restrict dangerous commands with ACLs.
• Never testing a restore. Symptom: during a real incident the RDB file turns out to be old, empty or unreadable.

How this shows up in real projects and interviews

Interviewers ask "is Redis durable?" to see whether you can say "it depends on RDB/AOF settings, and even then it is not a system of record unless you accept the loss window". They also ask what you would do when Redis memory is full, which is a question about eviction policy and key lifetimes. On a real team, the day-to-day work is monitoring memory and slow commands, setting TTLs on new key families as a review checklist item, and rehearsing failover. Containerised deployments add their own concerns, such as persistent volumes, covered in the Docker and Kubernetes courses.