Persistence, Durability & Redis as a Primary Database

RDB persistence writes the whole dataset to a single compact binary file (dump.rdb by default) at configured save points — combinations of an elapsed time and a minimum number of changes, any one of which triggers a snapshot. save "" disables automatic snapshotting entirely, leaving only manually triggered snapshots (or none, for a pure cache with no persistence at all).

SAVE writes a snapshot synchronously on the command-executing thread, blocking every other client for the whole write — essentially never what you want against a live instance. BGSAVE instead forks the process: the child writes the new RDB file from its own copy-on-write view of memory while the parent keeps serving commands on the original thread, and the new file atomically replaces the old one only once it is complete. Because both save points and an explicit BGSAVE share this fork step, a very large dataset can still make fork() itself take long enough to be felt as a latency spike on the parent, even though the child’s write never blocks it.

RDB’s data-loss window is bounded by the interval between save points, not by any single command: whatever was written since the last completed snapshot is lost if the process dies before the next one, which is why RDB alone suits data that can tolerate losing the last few minutes far better than it suits a system of record. See BGSAVE and Redis persistence.

The append-only file instead logs every write command as it happens, in the same wire format Redis itself speaks, and rebuilds the dataset by replaying that log on startup. It is off by default and turned on with appendonly yes.

appendfsync controls how often the AOF is actually flushed and `fsync`ed to disk, independently of how often commands are appended to it in memory:

Since Redis 7.0, the AOF is multi-part: instead of one growing file, a base file (an RDB- or AOF-format snapshot of the dataset at the time of the last rewrite) and one or more incremental files live together in a directory (appenddirname, default appendonlydir), tracked by a manifest file that records which base and increment files currently make up the log. BGREWRITEAOF compacts the log the same way BGSAVE compacts a snapshot: it forks, the child writes a fresh base file containing only the minimal set of commands needed to reach the current dataset, the parent keeps appending new writes to a new increment file in the meantime, and the two are atomically swapped in via the manifest once the child finishes — so a rewrite never blocks writes and never risks losing data written during it.

See BGREWRITEAOF and Redis persistence for the full multi-part AOF format and rewrite mechanics.

The two are not mutually exclusive: save points and appendonly yes can both be configured on the same instance, and Redis restarts from whichever one is more complete. With both enabled, a restart always loads the AOF, never the RDB file, since the AOF is guaranteed to be the more up-to-date of the two — the RDB file is then kept around for what it is genuinely good at: a compact, fast-to-restore point-in-time copy for off-box backups and disaster recovery, rather than the mechanism a restart actually relies on. Redis also avoids running an RDB save and an AOF rewrite at the same time, since both fork and both drive heavy disk I/O; whichever is requested second while the other is in progress is deferred until the first completes.

This combination is the closest Redis gets to the durability profile of a traditional relational database: snapshotting for cheap, restorable backups, AOF for sub-second recovery-point durability on restart. See Redis persistence ("Interactions between AOF and RDB persistence").

Both appendfsync everysec and asynchronous replication mean a command can reply OK to the client before the write it represents is actually durable anywhere but the primary’s memory. WAIT and WAITAOF let a caller block until a specific durability target is actually met, turning an implicit guarantee into one the application can check before, say, telling a customer their order succeeded.

WAIT numreplicas timeout blocks until at least numreplicas connected replicas have acknowledged having received and applied all write commands issued by the calling connection so far, or until timeout milliseconds pass (0 blocks forever); it says nothing about whether any of those replicas has actually fsynced the data to disk, only that they have it in memory.

WAITAOF numlocal numreplicas timeout is the disk-durability counterpart: it blocks until numlocal local fsyncs (0 or 1, since a single instance has only one local AOF) and numreplicas replica fsyncs have happened for every write issued by the connection so far, and returns the actual counts reached whether or not the targets were met before timeout. It requires AOF to be enabled wherever a local fsync is being waited on — asking for numlocal 1 against an instance with appendonly no fails outright, since there is no local AOF to fsync.

Both commands return immediately with whatever counts have already been reached, rather than actually blocking, when issued inside MULTI/EXEC or a script, since blocking there would stall every other client behind the single command-executing thread. See WAIT and WAITAOF.

New in Redis 8.10, the BACKUP command family produces a self-contained, restorable backup while the instance keeps serving writes, without the operator having to hand-manage AOF rewrites or coordinate around BGSAVE. A backup is itself a multi-part-AOF-shaped artifact: a BASE snapshot, an INCR file of writes accumulated since, and a manifest tying the two together, all hard-linked into a dedicated backup directory (backupdirname, default backupdir, resolved under the server’s working directory dir) rather than copied, so opening the backup window costs no extra disk I/O up front.

A typical backup, taken and shipped off-box, looks like this against a single node:

After copying the three files reported by BACKUP LIST to durable off-box storage, BACKUP CLEANUP releases them from the backup directory. Because starting a backup is decoupled from sealing it, a control plane managing several Bookshop shards can stagger BACKUP START across nodes so they don’t all fork at once, let each accumulate INCR data independently, then seal and copy each in turn.

Restoring is a startup-time operation driven by the preload-file configuration setting, given as <type>:<path> where <type> is aof or rdb. Pointed at a sealed backup’s manifest, it loads exactly that BASE+INCR file set — reflecting the dataset as of the BACKUP SEAL call, not merely the earlier BACKUP START snapshot — instead of the server’s normally configured appenddirname/dump.rdb:

preload-file can equally point at a lone RDB file (preload-file rdb:/path/to/backup.rdb) for a plain snapshot restore. See BACKUP START, BACKUP SEAL, and Redis persistence ("Online backups with the BACKUP command family") for the full state machine and restore procedure.

No persistence at all loses everything on any unclean stop — appropriate only for data that is purely derived or cache, never for anything Bookshop treats as a system of record. RDB alone bounds the loss window to the gap between the last completed save point and the crash, typically minutes with a realistic save schedule; a snapshot every five minutes means up to five minutes of writes can vanish. appendfsync everysec narrows that to about one second, at write latency close to RDB’s, which is why it’s the default and the right starting point for most workloads that care about durability at all. appendfsync always narrows it further, to essentially nothing beyond the write itself, at the cost of an fsync round trip on (batches of) every write — a real latency tax, not a free upgrade. RDB and AOF together inherit AOF’s tighter restart recovery point while keeping RDB’s cheap, portable snapshots for backup and disaster recovery, so the two address different failure scenarios rather than duplicating the same one. WAIT/WAITAOF don’t change any of these windows on their own; they let a caller confirm, for one specific write, that a chosen durability target was actually reached before treating that write as safe — turning a statistical guarantee into a per-request check where it matters enough to pay the latency for it.

Redis is increasingly used as a system of record in its own right — not only a cache in front of one — and that shift changes which guarantees actually matter.