Persistence: RDB & AOF

SAVE writes the snapshot on the main thread, so the server answers no commands until it finishes — unusable in production. BGSAVE forks a child that writes the snapshot while the parent keeps serving; only the brief fork itself pauses the server.

always fsyncs before replying, so an acknowledged write survives a crash, at a big throughput cost. everysec (the default) fsyncs once per second in a background thread, risking about a second of writes. no never fsyncs — the OS flushes when it likes, so a machine crash can lose tens of seconds.

The AOF records every write, so it grows with write volume and repeats history. BGREWRITEAOF forks a child that writes a new minimal file reproducing the current in-memory dataset, then atomically swaps it in: smaller file, faster restart.

With it on, a rewritten append-only file starts with the whole dataset in compact binary snapshot format, then appends later write commands as normal text. One file, snapshot body plus command tail. You gain much faster loading and a smaller file; durability is unchanged.

Everything written since the last completed snapshot. The amount is set by the configured save points, how long each save takes, and the write rate — so it ranges from seconds to the longest save-point interval, potentially an hour.

An AOF-rewrite child lives far longer than a BGSAVE on the same data, and the parent keeps writing AOF to the same disk throughout. Watch latest_fork_usec, aof_rewrite_in_progress, aof_rewrite_scheduled, aof_last_bgrewrite_status, aof_last_cow_size, and LATENCY LATEST's fork event.

An OK from Redis means only that the command was applied in the master's memory. Safety is a ladder: process memory, OS page cache, the device (whose own cache can lie), another node. The WAIT and WAITAOF commands confirm replication or fsync after the fact, not synchronously.

Use RDB as the backup artifact: trigger BGSAVE (ideally on a replica), copy dump.rdb off-host with a timestamped name and retention. Restore by stopping the server, placing the file in dir, starting with appendonly no, then enabling AOF at runtime. Verify by actually restoring.

The snapshot child is a fork() sharing memory copy-on-write. Every page the parent writes during the save gets duplicated, so a write-heavy instance can approach double its size. Fix with memory headroom (maxmemory well under RAM), disabled transparent huge pages, vm.overcommit_memory=1, and snapshotting from a replica.

If appendonly yes, Redis loads the append-only file and ignores the snapshot, because the AOF is more current. Turning AOF on by editing the config and restarting loads an empty AOF, so the server comes up empty and can overwrite the snapshot.

Redis remembers the AOF size after the last rewrite (or at startup). When the current size exceeds that baseline by auto-aof-rewrite-percentage (default 100, meaning doubled) and is at least auto-aof-rewrite-min-size (default 64mb), it starts a rewrite. Percentage 0 disables it.

Each line is a save point: snapshot in the background if at least that many key changes happened within that many seconds. They are OR-ed, so any satisfied line triggers one. save "" disables automatic snapshots; manual BGSAVE and replica sync still work.

If the background fsync is still running when the next write is due, Redis postpones the write for up to about two seconds rather than blocking, so the unsynced window can reach ~2s. And with no-appendfsync-on-rewrite yes, fsyncs stop entirely during a rewrite. Check aof_delayed_fsync in INFO persistence.

With always, an fsync runs in the serving path each event-loop cycle, so every client pays the device's sync latency. Confirm with the latency monitor's aof-fsync-always and aof-write events plus INFO persistence, and device I/O stats. Options: faster local storage, back to everysec, or move the guarantee to replicas.

Redis 7 replaced the single appendonly.aof with a directory holding a base file (RDB-format by default), one or more incremental files, and a manifest. The parent writes concurrent commands into a new incremental file instead of an in-memory rewrite buffer, so the buffer and the final diff-append are gone.

Copy the file first. Distinguish a truncated tail (tolerated by default via aof-load-truncated) from mid-file corruption, which always blocks startup. redis-check-aof --fix truncates from the first invalid command to end of file, discarding everything after it. For RDB, redis-check-rdb only verifies; it cannot repair.

The copy unit is the whole directory — manifest plus the base file plus every incr file it names, as one consistent set. Startup reads the manifest and loads base first, then incr files in manifest order. Point redis-check-aof at the manifest. A single file copied or truncated in isolation gives an unloadable or silently short dataset.

A snapshot is a compressed, checksummed image that loads by deserialization instead of replaying millions of commands, so restarts and replica seeding are fast and the file is small enough to copy off-box. The costs: not human-readable or editable, and version-coupled on downgrade.

Decide with two budgets: acceptable fork-stall latency and acceptable restart time. Then choose among fewer rewrites (raise the percentage or disable auto and schedule off-peak), moving persistence to a replica, and sharding so no node maps 60 GB. Fix the host first: overcommit on, huge pages off.

Set AOF on with everysec or always, snapshots shipped off-host, and replicas in separate failure domains. Then state the residual risk plainly: asynchronous replication means a failover can discard acknowledged writes, so money needs reconciliation against a durable source elsewhere.

Cache: snapshots only, or nothing — data is rebuildable. Sessions: both, with the append-only file on everysec, since losing minutes of logins hurts but is survivable. Ledger: both, with a real replica and off-box backups, because Redis alone should not be the system of record.