A Deep Dive into Redis Data Persistence: RDB and AOF
A deep dive into AOF, RDB, and keeping your data safe when the lights go out.
A deep dive into RDB snapshots, AOF ledgers, and the mechanics of in-memory durability.
The defining characteristic of Redis is that it lives entirely in RAM. This is the source of its blistering, sub-millisecond speed. But it also introduces a terrifying physical reality: if the server loses power, or the process crashes, the RAM is instantly wiped clean.
So, how can we trust Redis with critical data like user sessions, persistent queues, or primary application state?
The answer lies in its persistence mechanisms. Redis solves the “volatile RAM” problem by elegantly bridging the gap between memory and the physical hard drive using two completely different strategies: RDB (Redis Database) and AOF (Append-Only File).
1. RDB: The Point-in-Time Snapshot
RDB is the default persistence mode in Redis. Think of it like taking a photograph of your entire dataset at a specific moment in time.
If you configure Redis to save every 5 minutes, it will take all the keys, lists, sets, and hashes currently sitting in RAM, compress them into a tiny binary file (usually named dump.rdb), and write that file to the hard disk.
The Magic of fork() and Copy-on-Write
You might be wondering: If Redis is single-threaded, doesn’t writing a massive 10GB dataset to a slow hard drive block the entire database and cause requests to time out?
It would, if Redis did the writing itself. Instead, Redis uses a brilliant UNIX system call called fork().
When the
fork()system call is called, the operating system kernel makes a copy of the parent process’s memory space, open file descriptors, and execution state. Both processes then run independently and concurrently, continuing execution from the exact same point immediately after thefork()call.
When it’s time to take a snapshot, the main Redis process
forksitself, creating an exact child clone of the database in memory.The main process continues serving client requests with zero interruption.
The child process takes the snapshot, writes the
dump.rdbfile to the disk, and then silently kills itself.
Because modern operating systems use Copy-on-Write (CoW), the child process doesn’t actually duplicate all 10GB of memory. It simply shares the memory with the parent, only duplicating the specific memory pages that get modified while the snapshot is being written.
Copy-on-write (CoW) is an optimization strategy that delays copying data until it is actually modified. Instead of creating a full duplicate immediately, the system creates a reference to the original, allowing multiple actors to share the same data. A true copy is only made when a write operation occurs.
The Catch: The Data Loss Window
RDB is incredibly efficient, but it has one fatal flaw. If Redis takes a snapshot at 12:00 PM, and the server crashes at 12:04 PM, you lose all the data written during those four minutes. RDB trades absolute durability for performance.
2. AOF: The Indestructible Ledger
If losing even a single second of data is unacceptable for your application, you need AOF (Append-Only File).
Instead of taking periodic snapshots, AOF acts as a continuous ledger. Every time a write command changes the database (like SET user:1 "Alice"), Redis immediately logs that exact command as text to the bottom of the AOF file on the disk.
If the server crashes, Redis simply reads the AOF file from top to bottom, replaying every single command to reconstruct the database state perfectly.
𝐋𝐞𝐚𝐫𝐧 𝐭𝐨 𝐛𝐮𝐢𝐥𝐝 𝐆𝐢𝐭, 𝐃𝐨𝐜𝐤𝐞𝐫, 𝐑𝐞𝐝𝐢𝐬, 𝐇𝐓𝐓𝐏 𝐬𝐞𝐫𝐯𝐞𝐫𝐬, 𝐚𝐧𝐝 𝐜𝐨𝐦𝐩𝐢𝐥𝐞𝐫𝐬, 𝐟𝐫𝐨𝐦 𝐬𝐜𝐫𝐚𝐭𝐜𝐡. Get 40% OFF CodeCrafters: https://app.codecrafters.io/join?via=the-coding-gopher
