Redis AOF persistence restores data by logging write commands. Its core value is stronger post-crash data safety, while Rewrite controls file growth. This article focuses on three areas: AOF file structure, fsync policies, and the rewrite mechanism. Keywords: Redis persistence, AOF, Rewrite.
Technical Specifications at a Glance
| Parameter |
Description |
| Technical Topic |
Redis AOF Persistence |
| Core Language |
C (Redis server implementation), with redis.conf as the configuration language |
| Protocol |
RESP / Redis Serialization Protocol |
| Version Focus |
Redis 7 |
| Default Key Strategies |
appendfsync everysec, aof-use-rdb-preamble yes |
| File Forms |
Base file, incremental file, manifest file |
| Core Dependencies |
fsync, fork, bgrewriteaof, RDB preamble |
| Best Fit Scenarios |
Higher data safety requirements than RDB can provide, with acceptable recovery time |
AOF Persistence Records Replayable Write Commands
AOF, or Append Only File, works by appending every Redis write operation to a log file. When the system restarts, Redis replays these commands in order to reconstruct the in-memory state.
This approach addresses the main weakness of RDB snapshots: significant data can be lost between two snapshot intervals. Because AOF records write commands at finer granularity, it usually provides stronger data safety.
The minimum viable configuration is as follows
appendonly yes
appendfilename "appendonly.aof"
aof-use-rdb-preamble yes
appenddirname "appendonlydir"
These settings enable AOF, define the file name, turn on hybrid persistence, and specify the AOF storage directory.
Redis 7 AOF Has Evolved from a Single File to a Multi-File Layout
Starting with Redis 7, AOF is no longer just a single appendonly.aof file. It is split into three file types to improve rewrite handling, recovery, and management.
- Base file: stores a baseline dataset at a point in time, in either RDB or AOF format.
- Incremental file: stores new write command logs generated after the baseline file.
- Manifest file: records file loading order so Redis can replay data in the correct sequence during recovery.
The manifest file determines recovery order
file appendonly.aof.1.base.rdb seq 1 type b
file appendonly.aof.1.incr.aof seq 2 type i
file appendonly.aof.2.incr.aof seq 3 type i
Here, type b means a base file, and type i means an incremental file. At startup, Redis loads them from top to bottom in order.
Incremental AOF Files Are Essentially RESP Protocol Text
Incremental AOF files usually use the .aof extension. Their contents are not business-readable statements, but the textual representation of the Redis RESP protocol. Each command is written in protocol format so machines can parse it reliably.
Common RESP prefixes include *, $, +, -, and :. In AOF scenarios, arrays and bulk strings are the most common, which means * and $ appear most often.
A set command is represented in AOF as follows
*3
$3
set
$3
k11
$3
v11
Here, *3 means the command contains three arguments. Each following `$
` indicates the length of the string on the next line. This structure ensures Redis can replay commands without ambiguity.
## Hybrid Persistence Is the Default Recommended Path in the Redis 7 Era
`aof-use-rdb-preamble yes` means the AOF base file uses RDB format first. This makes the baseline section more compact and faster to load, while new writes are still recorded through incremental AOF files.
As a result, modern Redis AOF is usually not a pure command-text log. Instead, it is a hybrid of an RDB baseline plus AOF increments. This is also the deployment model officially recommended in practice.
### Typical configuration recommendations
“`conf
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
“`
This combination balances startup recovery speed, disk usage, and runtime safety, making it suitable for most production environments.
## The Rewrite Mechanism Compresses AOF Instead of Simply Copying the Old File
As write operations accumulate, the AOF file keeps growing. The purpose of Rewrite is not to create a copy of the old AOF as-is, but to regenerate a shorter and cleaner AOF from the current in-memory state.
Its key benefits are clear: remove obsolete history, collapse repeated writes, and filter expired data. This can significantly reduce both file size and recovery cost.
### Rewrite follows these compaction rules
“`text
1. Read operations are not written to the new AOF
2. Multiple overwrites of the same key keep only the final result
3. Expired data is not written to the new AOF
4. Mergeable commands are combined whenever possible
“`
This shows that Rewrite is a result-based rebuild, not a history-based replay.
## Redis Continues Serving Traffic During Rewrite
When `bgrewriteaof` runs, the main process uses `fork` to create a child process for the rewrite. The child process generates a new file from the current memory snapshot, while the main process continues to handle client requests.
However, new write commands generated during Rewrite cannot be lost. To prevent that, the main process also writes incremental updates into an extra buffer. After the child process finishes the main body of the new file, Redis appends the buffered commands and then atomically replaces the old file through `rename`.
### Manual trigger command
“`bash
redis-cli bgrewriteaof
“`
This command starts the rewrite asynchronously, so it does not block business threads the way a synchronous operation would.
## AOF Fsync Policies Define the Trade-Off Between Performance and Safety
After a write command enters `aof_buf`, Redis does not flush it to disk immediately. The timing of `fsync` depends on `appendfsync`, which is one of the most important parameters in AOF performance tuning.
– `always`: flush to disk after every write. Highest safety, lowest performance.
– `everysec`: flush once per second. The default, balancing performance and safety.
– `no`: let the operating system decide when to flush. Higher performance, but also the highest risk.
### Recommended production configuration
“`conf
appendfsync everysec
no-appendfsync-on-rewrite no
aof-rewrite-incremental-fsync yes
aof-load-truncated yes
“`
These settings aim to control blocking risk, improve Rewrite stability, and allow Redis to recover automatically by truncating a corrupted AOF tail when needed.
## The Full AOF Workflow Can Be Summarized in Five Steps
First, the client write command is encoded in RESP format and written to `aof_buf`. Then Redis writes it to disk according to the configured fsync policy.
When the file grows beyond a threshold, Redis triggers Rewrite automatically or manually. The child process generates new base content, the main process continues accepting new writes, and finally Redis appends the buffered increments generated during Rewrite and atomically replaces the old file.
### Use pseudocode to understand the flow
“`python
def handle_write(cmd):
aof_buf.append(cmd) # Append the write command to the AOF buffer
if fsync_policy_due(): # Check whether a flush is required by policy
flush_to_aof_file(aof_buf) # Write buffered content to disk
def rewrite_if_needed():
if aof_too_large(): # Trigger rewrite when the AOF file exceeds the threshold
child = fork() # Create a child process to run Rewrite
if child == 0:
build_new_aof_from_memory() # Child process builds a new file from current memory
“`
This pseudocode captures the two main tracks of AOF: append-based logging and background rewrite.
## The RDB and AOF Decision Should Be Based on Recovery Goals, Not Preference Alone
RDB offers small files and fast recovery, which makes it a good fit for systems sensitive to startup time and able to tolerate some data rollback. AOF offers stronger data safety and replayable logs, but files are larger and recovery is slower.
In production, the better choice is often not one or the other, but hybrid persistence. If Redis is used purely as a cache layer and the data can be rebuilt, you can also disable persistence entirely in exchange for higher performance.
### Selection guidance
“`text
– High-performance cache: persistence can be disabled
– Small data loss is acceptable: prefer RDB
– Higher data safety requirements: AOF or hybrid persistence
– General production scenarios: RDB + AOF hybrid is safer
“`
These recommendations apply to most small, medium, and mid-to-large deployments.
## FAQ
### 1. Why does Redis officially recommend hybrid persistence over pure AOF?
Because hybrid mode stores the baseline dataset in RDB format, which loads faster and takes less space, while still preserving AOF protection for incremental writes. It balances performance and reliability.
### 2. Why is `appendfsync everysec` the most common choice?
It limits the worst-case data loss window to about one second while avoiding the heavy flush overhead introduced by `always`. In production, it is the most balanced strategy.
### 3. Does AOF Rewrite block live traffic?
Not completely. Rewrite runs in the background through a child process, and the main process continues handling read and write requests. However, `fork`, fsync activity, and disk pressure can still introduce short-lived latency spikes, so you should evaluate it against available memory and I/O capacity.
**AI Readability Summary:** This article systematically explains the Redis AOF persistence mechanism, covering AOF file composition, RESP protocol formatting, the Rewrite process, fsync policies, and Redis 7 hybrid persistence configuration. It also compares the best-fit scenarios for RDB and AOF to help developers make practical trade-offs between performance and data safety.