Redis Persistence

Redis keeps its working dataset in memory, which is why reads and writes are fast, but memory alone is not durable. If the process crashes or the machine fails, purely in memory data disappears. Persistence is the part of Redis that trades some performance for recovery. In practice Redis offers two main persistence mechanisms, RDB snapshots and the append only file, and many deployments combine them because each solves a different problem.

RDB snapshots

RDB persistence writes the dataset to a compact binary snapshot at defined moments, such as after a certain number of writes within a time window. The file is efficient to load and usually smaller than the append only log. That makes it attractive for fast restarts, backups, and replica initialisation.

The tradeoff is data loss between snapshots. If Redis takes a snapshot every five minutes and the server dies four minutes after the last save, roughly four minutes of writes are gone. Snapshotting also creates resource pressure when the child process copies memory pages during the fork. With large datasets, that copy on write cost can create latency spikes or require more headroom than operators expect.

Append only file

AOF persistence records each write command in sequence. On restart, Redis can replay the log and reconstruct the dataset. Because the log can be fsynced every write, every second, or left to the operating system, operators can choose how much data loss they are willing to risk versus how much write latency they can tolerate.

The append only file usually offers better durability than snapshots, but the file grows over time and must be rewritten in the background to stay manageable. That rewrite is another operational event that consumes CPU, disk bandwidth, and memory. If the storage layer is slow, AOF can become the bottleneck long before Redis itself runs out of CPU.

Mixed mode and replicas

Many teams enable both RDB and AOF. The snapshot gives a compact baseline, while the log captures newer writes with finer granularity. This mixed approach balances restart speed and durability, though it also increases operational complexity.

Persistence interacts with replication too. A replica is not a backup. If bad writes, accidental deletes, or corruption are replicated quickly, the replica will mirror the mistake. Durable storage and backup policy still matter even in a replicated Redis topology.

Choosing the right mode

The right choice depends on what Redis is doing in the system. For a cache where data can be rebuilt, snapshots may be enough or persistence may be disabled entirely. For a job queue, rate limiter, or session store, losing a few seconds of writes might be acceptable but losing minutes may not. For primary data, many teams decide Redis is the wrong place altogether unless they are comfortable with the durability profile.

Redis persistence is therefore not a box to tick. It is an explicit tradeoff between throughput, latency, restart speed, disk cost, and acceptable loss. Understanding that tradeoff is the difference between using Redis as a fast tool and accidentally treating it like a database with guarantees it does not actually provide.