Redis RDB is Redis’s default snapshot-based persistence mechanism. It periodically writes the full in-memory dataset to disk at a point in time and restores that state after a restart. It addresses the risk of data loss in an in-memory database during power failure, but it requires trade-offs among performance, data freshness, and file safety. Keywords: Redis, RDB, bgsave.
Technical Specifications at a Glance
| Parameter | Details |
|---|---|
| Technical Topic | Redis RDB Persistence |
| Primary Language | C |
| Persistence Protocol / Mechanism | Snapshot Persistence, fork, Copy-On-Write |
| Default State | RDB Enabled by Default |
| Filename | dump.rdb |
| Popularity in the Official Ecosystem | Redis GitHub stars typically exceed 60k+ |
| Core Dependencies | Linux fork, file system, CRC64, LZF |
Redis RDB Persistence Is a Snapshot Mechanism Built for Recovery
At its core, Redis persistence moves the state of the in-memory database onto disk and reactivates it back into memory during restart. For a standalone Redis instance, this is not an optional optimization. It is the minimum capability that determines whether the system can recover after a failure.
RDB is snapshot-based persistence. It does not record every write command. Instead, it generates a binary snapshot file of the full in-memory dataset at a specific moment. Its advantages are compact files and fast recovery. Its cost is that data generated between two snapshots may be lost.
You Need a Clear Understanding of RDB vs. AOF Recovery Priority
Redis supports enabling both RDB and AOF at the same time. However, if both exist, Redis prioritizes loading AOF during restart. This means AOF has higher recovery priority, while RDB is better suited for fast backups and full-state recovery.
AI Visual Insight: This diagram shows the layered structure of Redis persistence: in-memory data branches into two paths, RDB snapshots and AOF logs. It also highlights the load order and recovery entry point during instance restart, making it essential for understanding why recovery priority matters more than the default enabled state.
redis-cli config get appendonly
redis-cli config get save
# Check whether AOF is enabled and inspect the current RDB save-point configurationThis command sequence helps you quickly confirm the persistence strategy currently used by the instance.
RDB Persistence Runs in Three Modes: Manual Blocking, Manual Background, and Automatic Triggering
RDB snapshots are typically generated in three ways: save, bgsave, and automatic triggering based on save rules. The core difference among them is not whether a snapshot is generated, but whether the main Redis process is blocked.
The SAVE Command Blocks the Redis Main Thread
save writes the snapshot to disk directly in the current process. During execution, Redis cannot continue processing read or write requests. For that reason, it is generally not recommended for production systems unless you are in a test environment or working within a very short maintenance window.
AI Visual Insight: This diagram illustrates the synchronous persistence path of the save command, where the main process performs disk persistence directly. It emphasizes that request handling and disk writes compete for the same process resources, which causes service blocking and reduced availability.
The BGSAVE Command Is the Mainstream Production Approach
bgsave first forks a child process, and the child process writes the in-memory snapshot to a temporary RDB file. The main process continues responding to client requests, so the impact on live traffic is much smaller. However, the fork operation and memory page copying still introduce resource overhead.
AI Visual Insight: This image shows the background execution model of bgsave: the main process continues serving traffic, while the child process handles snapshot persistence. It reflects Redis’s design choice of trading process isolation for service continuity.
redis-cli bgsave
redis-cli lastsave # Check the timestamp of the most recent successful persistence operation
# Generate a snapshot asynchronously, then verify when the last persistence completedThis command sequence manually triggers a background snapshot and checks whether it completed successfully.
Automatic RDB Trigger Rules Ultimately Invoke BGSAVE
A configuration such as save 3600 1 means: if at least one write occurs within 3600 seconds, trigger a snapshot. Common default combinations are once per hour with one write, once per five minutes with 100 writes, and once per minute with 10,000 writes.
The key point in these rules is not the syntax itself, but the write density of your workload. Systems with infrequent writes can reduce snapshot frequency to minimize I/O. Systems with heavy writes should combine RDB with AOF or replication to avoid relying on RDB alone and accepting a large rollback window.
save 3600 1 # Trigger if at least 1 write occurs within 1 hour
save 300 100 # Trigger if at least 100 writes occur within 5 minutes
save 60 10000 # Trigger if at least 10000 writes occur within 1 minute
# Automatic save rules ultimately trigger bgsave, not the blocking save commandThis configuration defines the typical automatic snapshot thresholds for RDB.
Key RDB Configuration Options Directly Affect Availability, Storage Usage, and Safety
stop-write-on-bgsave-error yes means that after the most recent background persistence failure, Redis stops accepting new writes. This is a conservative strategy, but it exposes disk or permission problems early and prevents the business layer from assuming that data is still being safely persisted.
rdbcompression yes uses LZF compression for string objects and can significantly reduce file size in many cases. It is a good fit for environments with limited disk space or frequent master-replica synchronization. rdbchecksum yes appends a CRC64 checksum to the end of the RDB file to improve corruption detection.
stop-write-on-bgsave-error yes # Stop accepting writes after a persistence failure
rdbcompression yes # Enable LZF compression
rdbchecksum yes # Enable CRC64 checksum
dbfilename dump.rdb # Set the RDB filename
dir ./ # Set the persistence file directoryThis configuration covers the most commonly used RDB options and the ones that most strongly influence production behavior.
Understanding the RDB File Structure Is the Key to Understanding Recovery
An RDB file typically consists of a file header, version number, database data section, end marker, and checksum. The header usually begins with the string REDIS, the version number is used for compatibility across different RDB formats, the EOF marker indicates the end of the data section, and the file ends with a checksum.
The most valuable part is the database data section. It stores multiple non-empty databases, and each database contains key-value pairs, value types, expiration time units, and exact expiration timestamps. This is the fundamental reason Redis can reconstruct runtime state as accurately as possible after restart.
AI Visual Insight: This diagram breaks down the encoded structure of a single key-value pair inside an RDB file. It shows the arrangement of VALUE_TYPE, expiration time units, timestamp, and the actual key/value data, helping explain how a binary snapshot balances compactness with recovery precision.
Copy-On-Write Determines the Real Cost of BGSAVE
bgsave looks non-blocking, but after fork, the parent and child processes initially share the same memory pages. If the main process modifies data during the snapshot, the kernel triggers Copy-On-Write and duplicates the modified pages before writing them.
As a result, the additional memory overhead of RDB does not appear only at the moment the snapshot starts. It is strongly correlated with write activity during the snapshot window. The heavier the write traffic, the more memory pages are copied, and the higher the temporary memory pressure becomes.
AI Visual Insight: This diagram shows the complete bgsave timeline: the main process forks a child, the child writes a temporary file, and after completion it renames the file to replace the old RDB, while the main process continues to process requests. It is the key workflow for understanding why asynchronous does not mean zero cost.
AI Visual Insight: This image focuses on the Linux Copy-On-Write mechanism: parent and child processes initially share memory pages, and only writes trigger page duplication. It explains why RDB snapshots can amplify memory usage and affect latency stability under heavy write load.
info persistence # Check RDB/AOF persistence status
info memory # Observe memory changes and evaluate COW overhead
# Monitor persistence and memory metrics together to assess whether bgsave affects instance stabilityThis command sequence helps operations teams observe RDB snapshot status and resource consumption.
In Production, You Should Treat RDB as a Fast Recovery Tool, Not a Zero-Loss Solution
If your goal is fast recovery, low disk usage, and easy backup or migration, RDB is an excellent fit. If your goal is to minimize the data loss window, RDB alone is not enough. You should combine it with AOF or replication.
A practical rule of thumb is this: cache-oriented workloads should prioritize RDB, while transactional or high-value write workloads should prioritize an AOF + RDB combination. The former optimizes for performance and recovery speed. The latter minimizes the rollback window.
FAQ
1. Why is BGSAVE recommended over SAVE in production?
Because save blocks the Redis main process and prevents it from handling any read or write requests during execution. bgsave uses a child process to persist data asynchronously, which significantly reduces the direct impact on live traffic.
2. What is the biggest risk of RDB?
The biggest risk is the rollback window. If the instance crashes between two snapshots, all writes generated during that interval may be lost. That makes RDB unsuitable for scenarios with extremely strict data freshness requirements.
3. If BGSAVE is already asynchronous, why can it still affect performance?
Because fork itself has a cost. In addition, once the main process modifies shared memory pages during the snapshot, Copy-On-Write is triggered, introducing extra memory copying, CPU overhead, and latency jitter.
Core Takeaway
This article systematically explains the Redis RDB persistence mechanism, covering snapshot principles, save/bgsave trigger modes, core configuration options, RDB file structure, and the Copy-On-Write workflow. It helps developers understand the trade-offs among performance, data safety, and recovery capability.