Redis persistence is how it saves your in-memory data to disk, so you don’t lose everything when the server restarts. The two main methods are RDB (Redis Database) and AOF (Append Only File), and they offer different trade-offs between performance, data safety, and file size.
Let’s see RDB in action. Imagine you have a simple Redis instance and you want to save its state. You can trigger an RDB snapshot manually:
redis-cli BGSAVE
This command tells Redis to fork a child process that will write the entire dataset to a .rdb file in the background. The parent process continues to serve requests without interruption. You can also configure automatic RDB snapshots in redis.conf:
save 900 1
save 300 10
save 60 10000
This configuration means Redis will save the dataset if at least 1 key changed in 900 seconds (15 minutes), or 10 keys changed in 300 seconds (5 minutes), or 10000 keys changed in 60 seconds.
Here’s how AOF works. Instead of taking snapshots, AOF logs every write operation that modifies the dataset. When Redis restarts, it replays these commands to rebuild the state. You enable AOF in redis.conf:
appendonly yes
And you can choose the fsync policy. appendfsync everysec is a good balance:
appendfsync everysec
This tells Redis to fsync the append-only file to disk every second. Other options include always (maximum durability, but slowest) and no (let the OS handle fsyncing, fastest but least safe).
The core problem RDB solves is providing a point-in-time backup of your data. It’s excellent for disaster recovery and for loading large datasets quickly into memory after a restart. Because it’s a compact binary file, it’s also generally smaller than an AOF file, especially if your dataset has many updates.
AOF, on the other hand, is designed for higher durability. By logging every operation, it can provide a much more granular recovery point. If Redis crashes, you’ll only lose the operations that happened since the last fsync. This makes it the preferred choice for applications where data loss is unacceptable, even for a few seconds.
The trade-off is RDB’s performance. While BGSAVE runs in the background, it does involve a fork operation, which can momentarily pause your Redis instance under heavy load. AOF, especially with appendfsync everysec, has a lower performance impact because it’s just appending to a file, and the fsync happens less frequently. However, AOF files can grow very large over time, and replaying a very large AOF file on startup can be slow. Redis offers BGREWRITEAOF to compact the AOF file in the background, similar to how RDB takes snapshots.
The most surprising thing about RDB is that the BGSAVE command uses fork(), a Unix system call. This means Redis essentially creates a copy of its entire memory space for the child process. On systems with Copy-on-Write (CoW), the memory pages aren’t actually duplicated until the parent process modifies them. This makes the initial fork surprisingly efficient, even for large datasets, and Redis can continue serving requests with minimal impact.
When you consider RDB, think about how often you need to recover. If a daily or hourly snapshot is sufficient, RDB is great. If you need to guarantee you lose no more than one second of data, AOF is your friend. Many users opt for both: RDB for its fast restores and AOF for its durability. Redis will typically use the AOF file for recovery if both are present, as it’s generally more up-to-date.
The next concept you’ll want to explore is Redis Sentinel for high availability.