📖 Scenario: You are managing a Redis database for a small online store. You want to understand how Redis saves data to disk to keep your data safe in case of a crash or restart.
🎯 Goal: Learn how to configure Redis persistence using RDB snapshots and AOF logs, and compare their behavior by setting up both methods.
📋 What You'll Learn
Create a Redis configuration snippet to enable RDB snapshots
Add configuration to enable AOF persistence
Write commands to trigger saving data with RDB
Write commands to check AOF file status
💡 Why This Matters
🌍 Real World
Redis persistence methods like RDB and AOF help keep data safe in real applications such as caching, session storage, and real-time analytics.
💼 Career
Understanding Redis persistence is important for roles like backend developers, DevOps engineers, and database administrators to ensure data durability and recovery.
Progress0 / 4 steps
1
Enable RDB Snapshot Persistence
Create a Redis configuration snippet that enables RDB snapshots by setting save 900 1 to save the DB if at least 1 key changes within 900 seconds, and set dbfilename to dump.rdb.
Redis
Hint
Use the save directive to set snapshot intervals and dbfilename to name the snapshot file.
2
Enable AOF Persistence
Add Redis configuration lines to enable Append Only File (AOF) persistence by setting appendonly yes and appendfilename appendonly.aof.
Redis
Hint
Set appendonly to yes to enable AOF and specify the AOF file name.
3
Trigger RDB Snapshot Save
Write the Redis command SAVE to manually trigger an RDB snapshot save.
Redis
Hint
Use the SAVE command to force Redis to save the DB snapshot immediately.
4
Check AOF File Status
Write the Redis command CONFIG GET appendonly to check if AOF is enabled and CONFIG GET appendfilename to check the AOF file name.
Redis
Hint
Use CONFIG GET with the keys appendonly and appendfilename to check AOF settings.
Practice
(1/5)
1. Which Redis persistence method saves the entire dataset at specific time intervals?
easy
A. AOF (Append Only File)
B. RDB (Redis Database snapshot)
C. Both RDB and AOF save snapshots
D. Neither RDB nor AOF save snapshots
Solution
Step 1: Understand RDB persistence
RDB saves the dataset by creating snapshots at set intervals.
Step 2: Compare with AOF
AOF logs every write operation, not snapshots.
Final Answer:
RDB (Redis Database snapshot) -> Option B
Quick Check:
Snapshot saving = RDB [OK]
Hint: RDB = snapshots at intervals, AOF = logs every change [OK]
Common Mistakes:
Confusing AOF with snapshot saving
Thinking both save snapshots
Believing neither saves snapshots
2. Which of the following is the correct Redis command to enable AOF persistence?
easy
A. CONFIG SET appendonly yes
B. CONFIG SET save "900 1 300 10 60 10000"
C. CONFIG SET rdbcompression no
D. CONFIG SET maxmemory-policy allkeys-lru
Solution
Step 1: Identify AOF enabling command
The command to enable AOF is CONFIG SET appendonly yes.
Step 2: Check other options
CONFIG SET save "900 1 300 10 60 10000" sets RDB save intervals, C disables RDB compression, D sets memory eviction policy.
Final Answer:
CONFIG SET appendonly yes -> Option A
Quick Check:
Enable AOF = appendonly yes [OK]
Hint: Enable AOF with 'appendonly yes' command [OK]
Common Mistakes:
Confusing RDB save command with AOF
Using unrelated config commands
Forgetting to set appendonly to yes
3. Given Redis configured with AOF enabled and fsync set to 'everysec', what is the expected data durability behavior?
medium
A. Data is saved only at intervals, risking data loss of last seconds
B. Every write is immediately saved to disk, no data loss
C. Data is never saved to disk automatically
D. Data is saved only when Redis restarts
Solution
Step 1: Understand AOF with fsync everysec
With fsync set to 'everysec', Redis writes AOF data to disk every second.
Step 2: Analyze durability implications
This means data could be lost if Redis crashes within the last second before fsync.
Final Answer:
Data is saved only at intervals, risking data loss of last seconds -> Option A
Quick Check:
AOF everysec fsync = possible 1-second data loss [OK]
Hint: AOF everysec fsync means possible 1-second data loss [OK]
Common Mistakes:
Assuming every write is immediately saved
Thinking data is never saved automatically
Confusing with no persistence
4. You enabled both RDB and AOF persistence in Redis, but after a crash, data is missing. What is the most likely cause?
medium
A. Redis does not support using both RDB and AOF together
B. Redis was not restarted after enabling persistence
C. RDB snapshot interval is too long, losing recent changes
D. AOF file is corrupted and Redis cannot load it
Solution
Step 1: Understand RDB and AOF coexistence
Redis supports both RDB and AOF, preferring to load AOF first on restart if available.
Step 2: Analyze data loss causes
With both enabled, if data is missing after a crash, the most likely cause is AOF corruption, causing fallback to the older RDB snapshot and loss of recent changes.
Final Answer:
AOF file is corrupted and Redis cannot load it -> Option D
Quick Check:
Data loss with both = AOF corrupted [OK]
Hint: With both enabled, data loss likely from AOF corruption [OK]
Common Mistakes:
Believing Redis can't use both persistences
Thinking RDB interval too long is the cause
Forgetting to restart Redis
5. You want Redis to recover data quickly after a crash but can tolerate losing up to 1 minute of recent writes. Which persistence setup is best?
hard
A. Enable AOF with fsync always, disable RDB
B. Enable both RDB and AOF with fsync everysec
C. Enable RDB snapshots every 60 seconds, disable AOF
D. Disable both RDB and AOF for fastest performance
Solution
Step 1: Match recovery speed and data loss tolerance
RDB snapshots every 60 seconds allow fast recovery but may lose up to 1 minute of data.
Step 2: Compare with AOF options
AOF with fsync always is slower but safer; both enabled adds overhead; disabling persistence risks total data loss.
Final Answer:
Enable RDB snapshots every 60 seconds, disable AOF -> Option C
Quick Check:
Fast recovery + 1 min loss = RDB every 60s [OK]
Hint: RDB snapshots match fast recovery with some data loss [OK]
Common Mistakes:
Choosing AOF for fast recovery despite slower startup
Enabling both causing unnecessary overhead
Disabling persistence risking total data loss
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.