Skip to main content
Redis Basics
CHAPTER 09 Intermediate

Redis Persistence Explained | RDB Snapshots and AOF

Updated: May 16, 2026
15 min read

# CHAPTER 9

Redis Persistence and Data Durability

1. Introduction

Throughout this course, we have stated a terrifying fact: Redis stores data in RAM. If the server loses power, or if the process crashes, the RAM is instantly cleared, and your data is vaporized. This is perfectly fine if Redis is just caching HTML pages that MySQL can regenerate. But what if you are using Redis as your primary database for a live gaming leaderboard? You cannot afford to lose that data. In this chapter, we will learn how Redis magically achieves Persistence—saving the speed of RAM while writing to a physical Hard Drive.

2. Learning Objectives

By the end of this chapter, you will be able to:
  • Define the concept of Data Durability.
  • Understand RDB (Redis Database Backup) Snapshots.
  • Understand AOF (Append Only File) logging.
  • Configure persistence in redis.conf.
  • Balance performance against absolute data safety.

3. The RDB Snapshot Method

The RDB (Redis Database) method is like taking a photograph of your RAM. Every few minutes (or hours), Redis pauses for a microscopic fraction of a second, takes a perfect 1:1 snapshot of every single key and value in memory, and saves it to a highly compressed binary file on your hard drive (usually named dump.rdb).

How to trigger it manually:

bash
1 
SAVE

*(Warning: SAVE blocks all other operations! In production, you use BGSAVE to take the snapshot in a Background process).*

The Trade-off: If you configure RDB to take a snapshot every 5 minutes, and the server crashes at minute 4, you permanently lose 4 minutes of data.

4. The AOF Logging Method

The AOF (Append Only File) method is completely different. It is a literal text log. Every single time you execute a command that changes data (like SET or INCR), Redis writes that exact command into a massive text file (appendonly.aof) on your hard drive. If the server crashes, Redis turns back on, opens the AOF file, and literally "re-types" every single command from the log into the engine to rebuild the RAM from scratch!

The Trade-off: AOF provides absolute mathematical data safety (you never lose a single command). However, logging every single command slows down the server slightly, and the physical AOF file can grow to enormous sizes.

5. Configuring Persistence

You control these mechanisms by editing the redis.conf file on your server.

Configuring RDB:

text
123 
save 900 1   # Save snapshot if 1 key changed in 15 minutes
save 300 10  # Save snapshot if 10 keys changed in 5 minutes
save 60 10000 # Save snapshot if 10,000 keys changed in 1 minute

Configuring AOF:

text
12 
appendonly yes
appendfsync everysec # The golden rule! Syncs the log every 1 second.

6. The Hybrid Approach (The Industry Standard)

Which one should you use? In modern enterprise architecture, you use both.
  • You turn on AOF to guarantee that you never lose more than 1 second of live data.
  • You turn on RDB to create compressed, nightly .rdb files that you can easily upload to Amazon S3 as disaster recovery backups.

When Redis reboots, if it detects both files, it will automatically choose the AOF file to rebuild the data, because the AOF file is always mathematically more recent!

7. Data Recovery Workflow

What happens if the server completely burns down?
  1. 1. You buy a brand new server.
  1. 2. You install a fresh copy of Redis.
  1. 3. Before turning Redis on, you copy your dump.rdb or appendonly.aof file into the /var/lib/redis directory.
  1. 4. You start the Redis service.
  1. 5. Redis detects the file, loads the data into RAM, and your application is back online in seconds!

8. Mini Project: Proving Persistence

Let's prove the data survives a crash.
  1. 1. Open terminal: redis-cli
  1. 2. SET proofoflife "I survived!"
  1. 3. Force a physical save to disk: BGSAVE
  1. 4. Now, brutally kill the Redis server process from your Linux terminal (simulate a power outage).
  1. 5. Start the Redis server back up.
  1. 6. Open terminal: redis-cli
  1. 7. GET proofoflife
*(Returns "I survived!". The RAM was wiped, but Redis instantly rebuilt it from the dump.rdb file upon boot!)*

9. Common Mistakes

  • AOF File Bloat: If you run INCR counter 1 million times, the AOF file will contain 1 million lines of text, making the file massive. To fix this, Redis has a background process called AOF Rewrite. It intelligently compresses the log. (e.g., Instead of 1 million INCR lines, it just rewrites it as one single SET counter 1000000 line!).

10. Best Practices

  • Never Run SAVE in Production: If your database is 10 Gigabytes, running the SAVE command will freeze the entire database engine for 5 to 10 seconds while it writes to the hard drive. During those 10 seconds, every single user on your website will receive a Timeout Error. Always use BGSAVE to utilize a background thread.

11. Exercises

  1. 1. Which persistence mechanism takes a compressed binary "photograph" of the database at specific intervals?
  1. 2. Which persistence mechanism logs every individual write command as it happens?

12. Redis Challenges

You configure your Redis server to use strictly RDB snapshots, scheduled to run every 15 minutes. At exactly 2:14 PM, a catastrophic hardware failure occurs and the server loses all power. How much data is permanently, irreversibly lost? *(Answer: You lose exactly 14 minutes of data. Because the snapshot had not yet triggered for the current interval, any SET or INCR commands executed since the 2:00 PM snapshot were stored exclusively in volatile RAM and are permanently destroyed).*

13. MCQ Quiz with Answers

Question 1

When architecting an enterprise Redis deployment requiring absolute data durability with zero tolerance for data loss, which persistence configuration is strictly required?

Question 2

During a server reboot, if Redis detects both a dump.rdb snapshot file and an appendonly.aof log file in its data directory, which file will the engine prioritize to rebuild the in-memory dataset?

14. Interview Questions

  • Q: Compare and contrast the RDB and AOF persistence mechanisms in Redis. Discuss the specific trade-offs regarding CPU performance during saves, file size, and the potential for data loss.
  • Q: Explain the concept of "AOF Rewrite" (BGREWRITEAOF). Why is this architectural background process strictly necessary when utilizing Append Only File persistence over long periods?

15. FAQs

Q: If I use both AOF and MySQL, isn't that redundant? A: Yes! If your Redis instance is acting *strictly* as a cache for MySQL, you should turn Persistence completely OFF. If the Redis server crashes, you just let it reboot empty, and it will naturally refill its cache from MySQL as users request data. You only use Redis Persistence if Redis is acting as the *primary* database for specific features (like live sessions).

16. Summary

You have conquered volatility. By understanding the binary snapshots of RDB and the chronological command logging of AOF, you can architect Redis deployments that are not only blazingly fast in RAM, but structurally indestructible on the hard drive.

17. Next Chapter Recommendation

Our data is safe from hardware failure. But what if multiple users try to edit the same data at the exact same millisecond? In Chapter 10: Transactions and Atomic Operations, we will learn how to queue up complex commands and execute them flawlessly as a single, indivisible unit.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Previous Chapter Redis TTL Tutorial | EXPIRE and Cache Management
Next Chapter Redis Transactions | MULTI, EXEC, and WATCH Commands

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·

Explore More

📖 Related Tutorials 6

❓ Related Quizzes 6