Redis exposes three values for the appendfsync setting: always, everysec and no. What does each one do, and how much data does each risk losing when the process or the machine crashes?

## The two-stage write path Understanding the policies requires understanding what happens to a logged command: 1. **Redis buffer.** After a write command executes, its normalised form is appended to an in-memory AOF buffer inside the Redis process. 2. **`write()` to the OS.** Once per event-loop cycle (before the server goes back to waiting for I/O), Redis flushes that buffer with a `write()` syscall. The bytes are now in the **kernel page cache**. They are no longer lost if the *Redis process* dies — the kernel owns them and will write them out — but they are not on the physical device yet. 3. **`fsync()` to the device.** Only `fsync()` tells the kernel to push those pages to durable storage and waits for the device to confirm. `appendfsync` governs step 3 exclusively. This is why "process crash" and "machine crash" are two different questions and why a candidate who conflates them gets the loss windows wrong. ## appendfsync always Redis performs the `fsync()` in the same event-loop cycle as the `write()`, **before** replies for those commands are sent to the clients. So when your client receives `+OK`, the command is durable on that node: neither `kill -9` nor a power cut loses it. The cost is that every batch of writes pays the storage device's sync latency, in the path that also serves every other client. On a consumer SSD an fsync is often a fraction of a millisecond; on network-attached storage it can be several milliseconds. Throughput commonly drops by an order of magnitude compared with `everysec`. Two nuances worth stating: the fsync covers everything in the cycle, so under heavy pipelining many commands amortise one sync; and "durable" means durable *on that machine* — it says nothing about replicas, which are updated asynchronously. ## appendfsync everysec — the default Redis calls `write()` every cycle as usual, but delegates `fsync()` to a **background thread** that runs roughly once per second. Command processing never waits for the device in the normal case. Loss windows: - **Redis process crashes** (bug, OOM kill, `kill -9`): only whatever is still sitting in the in-memory AOF buffer is lost — typically sub-millisecond of writes, because the buffer is flushed with `write()` every cycle. The kernel still holds and will persist everything already written. - **Machine crash or power loss**: up to about one second of writes, since that is the sync interval. The true worst case is closer to **two seconds**: if a previous fsync is still in flight when the next cycle wants to write, Redis postpones the `write()` rather than blocking on a busy disk, and only after ~2 seconds does it write anyway. This is the default because it is the knee of the curve: near-`no` throughput with a bounded, small, well-understood loss window. ## appendfsync no Redis performs the `write()` and never calls `fsync()` at all (barring rewrite bookkeeping). Flushing is entirely the kernel's decision, driven by its dirty-page writeback settings — on Linux, commonly up to around 30 seconds. - **Redis process crash**: still only the in-memory buffer is lost, exactly as with `everysec`. This surprises people; the OS is the safety net. - **Machine crash**: potentially tens of seconds of writes. Throughput is the highest of the three, and latency is the smoothest, because nothing in Redis ever waits on the device. ## Choosing - `everysec` for almost everything. The default is the default for good reasons. - `always` when a single lost acknowledged write is genuinely unacceptable *and* the storage is fast enough — and even then, be explicit that this protects one node, not the cluster, because replication is asynchronous. - `no` when Redis holds regenerable data (a cache, derived state) and you want maximum throughput; the honest version of that choice is often "persistence is a warm-start optimisation, not a durability guarantee". ## Things that silently change the policy - `no-appendfsync-on-rewrite yes` suspends fsyncs entirely while a background rewrite is running, to avoid two processes hammering the same disk. During that window, an `everysec` instance effectively behaves like `no`. It is a deliberate latency-versus-durability trade you should know you have made. - `CONFIG SET appendfsync ...` applies immediately but is lost on restart unless you also `CONFIG REWRITE`. - Virtualised or network-attached storage may lie about, batch, or simply be slow at fsync; the policy is only as good as the device honouring it. ## Observability `INFO persistence` exposes `aof_last_write_status`, `aof_last_bgrewrite_status`, `aof_pending_fsync` and `aof_delayed_fsync` — the last one counts how often an fsync was still running when Redis wanted to write, and a growing value is direct evidence that the disk cannot keep up with the chosen policy. The latency monitor tracks `aof-write`, `aof-fsync-always` and related events. ## The one-line answer "`write()` protects against a Redis crash, `fsync()` protects against a machine crash. `always` fsyncs before the reply — zero acknowledged loss, big throughput cost. `everysec` fsyncs in a background thread — about a second at risk, up to two in the worst case. `no` leaves it to the kernel — tens of seconds at risk, fastest."