Valkey’s fork-based snapshotting, known as BGSAVE, achieves point-in-time persistence without completely freezing your primary database operations.
Let’s see this in action. Imagine a Valkey instance with a few keys:
127.0.0.1:6379> SET key1 value1
OK
127.0.0.1:6379> SET key2 value2
OK
127.0.0.1:6379> BGREWRITEAOF
Background appending only file rewriting started as a background process. Use BGREWRITEAOF status command to check progress.
127.0.0.1:6379> SET key3 value3
OK
While key3 is being added to the live database, the BGREWRITEAOF command is already working in the background, preparing a new AOF file based on the state of the database at the moment BGREWRITEAOF was initiated. This means key3 won’t be in the newly generated AOF file, but key1 and key2 will be. The primary instance remains responsive throughout this process.
The core of this magic lies in the fork() system call. When BGREWRITEAOF (or BGSAVE for RDB snapshots) is invoked, Valkey doesn’t copy all its data to disk. Instead, it uses fork(). This creates a child process that is an exact replica of the parent process at that instant. The operating system’s copy-on-write (COW) mechanism is the key enabler. Initially, the child process shares the same memory pages as the parent. Only when either process modifies a memory page does the OS create a separate copy of that page for the modifying process.
This means the parent Valkey process can continue serving client requests, accepting writes, and modifying its data. For every write operation the parent performs, the OS copies the modified memory page. The child process, meanwhile, reads from its (initially shared) memory pages and writes the data to disk. This allows the snapshotting to occur with minimal impact on the latency of your primary Valkey instance. The "snapshot without full blocking" is achieved because the blocking is effectively delegated to the OS’s COW mechanism, which is highly efficient for read-heavy workloads like snapshotting.
The primary problem this solves is the trade-off between data safety and application performance. Traditional snapshotting methods often require significant downtime or latency spikes to ensure data consistency. By forking, Valkey delegates the heavy lifting of data duplication to the operating system, allowing the main process to remain largely unaffected. You get a consistent snapshot of your data without bringing your application to a grinding halt.
The configuration directive save (for RDB) and the BGREWRITEAOF command control when these background saves happen. For RDB, you can configure rules like save 900 1 which means "save the RDB file if at least 1 key changed in the last 900 seconds." For AOF, BGREWRITEAOF is typically triggered manually or automatically when the AOF file size exceeds a certain threshold (controlled by auto-aof-rewrite-percentage and auto-aof-rewrite-min-size).
The actual data written to disk by the child process is a representation of the memory state at the time of the fork. If the parent process modifies a key after the fork, that modified version will not be included in the snapshot being generated by the child. The snapshot is a true point-in-time capture. This is why BGREWRITEAOF (and BGSAVE) is crucial for durability.
When the child process finishes writing its snapshot to disk, it simply exits. The parent process continues, now with a potentially updated AOF file or a fresh RDB snapshot available for recovery. The efficiency of the fork operation means that even on large datasets, the pause in client responsiveness is typically negligible, measured in milliseconds rather than seconds or minutes.
The ultimate limit of this mechanism is the available memory. If the parent process needs to write to a very large percentage of its memory pages while the child is still working, the OS will end up copying a significant portion of the data, potentially leading to high memory pressure and slower performance. This is a "soft" limitation, as the system doesn’t block entirely, but performance can degrade.
The next step after understanding background saving is to learn about Valkey’s replication, which uses a different mechanism to keep replicas in sync with the primary.