A Redis instance is configured with snapshot persistence only — no append-only file. If the host loses power, how much data is lost, and what exactly determines that amount?

## What a snapshot protects, and what it does not An RDB file is a point-in-time image. It says: *at this instant, the dataset looked like this*. It carries no record of anything that happened afterwards. So with snapshotting as the only persistence, a sudden power loss costs you **every write accepted since the last completed snapshot** — no partial recovery, no replaying the difference, because nothing recorded the difference. That is the honest shape of the guarantee, and stating it plainly is the point of the question. Redis is not lying to you about it: snapshot-only persistence is explicitly a "lose the last N minutes" configuration, and it is a perfectly good one for data you can rebuild. ## The three factors that size the window **1. The configured save points.** Each `save <seconds> <changes>` line is a trigger condition, and they are alternatives. With the conventional set (`3600 1`, `300 100`, `60 10000`), the *worst case* is bounded by the longest interval whose change threshold you meet. A near-idle server that changes one key an hour is protected only hourly — so it can lose up to an hour of (admittedly sparse) changes. A server taking 10,000 writes a minute snapshots roughly every minute, losing at most about a minute of a very large volume. Notice the asymmetry: low-traffic servers have long windows measured in time, high-traffic servers have short windows containing many writes. **2. When the snapshot's content was frozen.** The child that writes the file forked at time T; the file's contents are the dataset as of T, not as of when the file finished. On a large dataset the write can take tens of seconds. Every command accepted during that period is outside the snapshot even though the snapshot "was running" at the time. The practical version: your effective last-good-point is the last *fork* that completed successfully, not the last moment a save was in progress. **3. Whether saves are actually succeeding.** This is where real incidents live. A disk fills, permissions change, or `fork()` is refused for lack of memory; background saves start failing; the config still says `save 300 100`, so everyone assumes five minutes of exposure, but the last good file on disk is from Tuesday. The instruments: - `rdb_last_bgsave_status` — `ok` or `err` - `rdb_last_save_time` / `LASTSAVE` — Unix time of the last **successful** save - `rdb_changes_since_last_save` — keyspace modifications currently unprotected A climbing `rdb_changes_since_last_save` that never resets is the signature of silently failing persistence. Redis does push back here: with the default `stop-writes-on-bgsave-error yes`, once a background save has failed the server rejects writes with a `MISCONF` error, precisely so a persistence outage cannot masquerade as a healthy server. ## What you do not lose A crash *during* a save does not corrupt or truncate your previous snapshot. The child writes to a temporary file and only `rename()`s it over `dump.rdb` once the complete image, including its CRC64 checksum, is written; rename within a filesystem is atomic. So a mid-save crash leaves the previous complete snapshot on disk. Similarly, a torn or corrupted file is detected on load rather than silently accepted, because of the checksum (unless `rdbchecksum` was disabled). One subtlety: writing and renaming does not by itself guarantee the bytes reached the platter, so a hard power cut can in principle lose a *just-completed* snapshot to the OS page cache. In practice the dominant exposure is the write gap, not this. ## Shrinking the window, and what it costs - **Tighter save points** shorten the gap but add fork pauses and copy-on-write memory episodes; on a large write-heavy instance that tax is continuous while the benefit only materializes during a crash. - **The append-only file** is the real answer when the window must be about a second rather than minutes; that is a different persistence mechanism, not a snapshot tuning knob. - **Replicas do not shrink the durability window in a power loss** of the whole rack, and replication is asynchronous, so a replica may itself be behind at the moment the primary dies. ## The one-sentence version With snapshots only, your loss window is "time since the last successful fork", bounded by your save points, inflated by save duration, and unbounded if saves have been failing — which is why you monitor `rdb_last_bgsave_status` rather than trusting the config file.