> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Last RDB Save (minutes ago), Redis > Last RDB Save for Redis instances. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Sensitivity](/nerve-centre/overview#card-classes-explained) • **Category:** [Persistence](/nerve-centre/connectors#connectors-by-type) ## At a glance > The number of minutes since Redis last wrote a successful RDB snapshot to the node's own disk. RDB is Redis's point-in-time snapshot file (`dump.rdb`): a compact, forked copy of the entire dataset taken on a schedule or on demand. This card answers "if the Redis process restarted right now, how much recent data would it have to reconstruct on startup". It is the local-durability counterpart to the offsite backup card: a fresh RDB save protects you from a process crash; it does not protect you from losing the whole node. | | | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it tracks** | Minutes elapsed since `rdb_last_save_time`, the Unix timestamp of the last successful RDB save (scheduled `save` rule, manual `BGSAVE`, or `SAVE`). | | **Data source** | `rdb_last_save_time` from `INFO persistence`, cross-checked against `rdb_last_bgsave_status` (`ok` or `err`) and `rdb_bgsave_in_progress`. | | **Time window** | `RT` (real-time, re-evaluated on every Nerve Centre poll, typically every 60 seconds). | | **Alert trigger** | `> 60m`. If no successful RDB save has completed in the last 60 minutes, the card turns amber/red. | | **Units** | Minutes (integer, rounded down). `0` means a save completed within the last minute. | | **What counts** | A `BGSAVE` (or blocking `SAVE`) that completed with `rdb_last_bgsave_status = ok`. | | **What does NOT count** | (1) A `BGSAVE` still in progress (`rdb_bgsave_in_progress = 1`); (2) a save that failed (`rdb_last_bgsave_status = err`, usually fork or disk failure); (3) AOF writes, which are tracked separately; (4) the offsite copy, which the Backup card tracks. | | **Roles** | owner, dba, platform, sre | ## Calculation The card subtracts the last successful RDB save timestamp from "now": ```text theme={null} last_rdb_save_age_minutes = floor( (now_unix - rdb_last_save_time) / 60 ) ``` `rdb_last_save_time` is reported directly by `INFO persistence` as a Unix epoch and is identical to what `redis-cli LASTSAVE` returns. It updates only when a save completes successfully. The engine reads two companion fields to qualify the value: * **`rdb_last_bgsave_status`.** If this is `err`, the last save attempt failed (typically the fork failed for lack of memory, or the disk was full or read-only). In that case the timestamp may be stale even though Redis "tried", so the card surfaces the failure rather than just an ageing counter. * **`rdb_bgsave_in_progress`.** If a save is currently running, the age keeps climbing until that save lands; an in-progress save does not pre-emptively reset the clock. RDB save cadence is governed by the `save` configuration directive (for example `save 900 1 300 10 60 10000`, meaning save after 900s if at least 1 key changed, after 300s if 10 changed, after 60s if 10,000 changed). A quiet instance with few writes may legitimately go a long time between saves under those rules; that is expected behaviour, not necessarily a fault, which is why the alert is tunable. ## Worked example A DBA manages a Redis 7.0 instance backing a product-recommendation service. The `save` directive is the default `save 3600 1 300 100 60 10000`. RDB is the only persistence mechanism (AOF is off). Snapshot taken on 22 Mar 26 at 14:20 UTC. | Signal | Value | Source | | ------------------------ | ------------------- | ------------------ | | `rdb_last_save_time` | 22 Mar 26 13:02 UTC | `INFO persistence` | | `rdb_last_bgsave_status` | `ok` | `INFO persistence` | | `rdb_bgsave_in_progress` | `0` | `INFO persistence` | | `rdb_last_cow_size` | 612 MB | `INFO persistence` | | Card headline | **78 minutes ago** | computed | The card reads **78 minutes**, just over the 60-minute alert, and turns amber. The DBA's read: 1. **The last save succeeded, but cadence has slowed.** Status is `ok`, so nothing failed; the instance simply has not crossed a `save` rule in 78 minutes. Under the default rules, that means fewer than 100 keys changed in any 300-second window and fewer than 10,000 in any 60-second window since 13:02. For a recommendation cache during a quiet afternoon, that is plausible. 2. **The exposure is 78 minutes of writes.** If the process restarts now, it reloads `dump.rdb` from 13:02 and loses any keys written since. For a recompute-on-miss cache that is harmless (the service repopulates). If this instance also held anything not recomputable, 78 minutes would be a real loss window. 3. **Copy-on-write memory is healthy.** `rdb_last_cow_size` of 612 MB tells the DBA the fork's copy-on-write footprint during the last save was moderate, so the save is not at risk of a fork failure from memory pressure. Worth watching alongside [Memory Used vs Maxmemory %](/nerve-centre/kpi-cards/redis/memory-used-vs-maxmemory) because a near-full instance can fail to fork. ```text theme={null} Decision the DBA faces at 14:20 UTC: - Status is ok, so this is a cadence question, not a failure. - Is 78 minutes of potential loss acceptable for this dataset? cache-only, recomputable -> raise the alert to e.g. 6h, no action holds non-recomputable -> tighten save rules OR enable AOF - If non-recomputable: add `save 300 1` or switch to AOF everysec. ``` Three takeaways: 1. **A high reading is not automatically a fault.** RDB saves are write-driven by the `save` rules. A quiet instance saving infrequently is behaving as configured. Read the value against the importance of the data, not as a universal alarm. 2. **Watch the status field, not just the age.** An ageing counter with status `ok` is a cadence question. An ageing counter with status `err` is a failure: the fork or disk is broken and no new snapshot is being written at all. The card surfaces both, but they demand different responses. 3. **RDB protects against restart, not node loss.** A fresh `dump.rdb` lets Redis recover quickly after a process crash. It does nothing if the disk or VM is lost. Always pair this with [Last Successful Backup (hours ago)](/nerve-centre/kpi-cards/redis/last-successful-backup-hours-ago), which tracks the offsite copy. ## Sibling cards DBAs should reference together | Card | Why pair it with Last RDB Save | What the combination tells you | | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | [Last Successful Backup (hours ago)](/nerve-centre/kpi-cards/redis/last-successful-backup-hours-ago) | RDB save is local; backup is offsite durability. | Fresh RDB save plus stale offsite backup equals a broken shipping job, not a Redis fault. | | [Last AOF Rewrite Status](/nerve-centre/kpi-cards/redis/last-aof-rewrite-status) | The other persistence mechanism. | If RDB saves are failing, a healthy AOF is your fallback recovery point, and vice versa. | | [Memory Used vs Maxmemory %](/nerve-centre/kpi-cards/redis/memory-used-vs-maxmemory) | `BGSAVE` forks; a near-full instance can fail to fork. | High memory plus `rdb_last_bgsave_status = err` usually equals fork failing for lack of headroom. | | [Memory Fragmentation Ratio](/nerve-centre/kpi-cards/redis/memory-fragmentation-ratio) | Fragmentation and copy-on-write both pressure RSS during a save. | A save can spike RSS; high fragmentation makes that spike more dangerous. | | [Redis Health Score](/nerve-centre/kpi-cards/redis/redis-health-score) | The composite that folds save freshness into overall health. | A failing RDB save drags the score even when latency looks fine. | | [Operations per Second (live)](/nerve-centre/kpi-cards/redis/operations-per-second-live) | High write throughput drives save cadence under the `save` rules. | High ops with stale saves can mean reads dominate, or the save rules are too loose for the write rate. | ## Reconciling against the source **Where to look in Redis's own tooling:** > **`redis-cli LASTSAVE`** returns the exact Unix timestamp this card is built on. Convert it and compare. > **`INFO persistence`** for the full picture: `rdb_last_save_time`, `rdb_last_bgsave_status`, `rdb_bgsave_in_progress`, `rdb_changes_since_last_save` (how many writes are unsaved), and `rdb_last_cow_size`. > **`CONFIG GET save`** to see the active save rules governing automatic cadence. > **The Redis log** (path from `CONFIG GET logfile`) for `Background saving started` / `Background saving terminated with success` lines, and any fork-failure errors. **Why our number may legitimately differ from what you see:** | Reason | Direction | Why | | ----------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------ | | **In-progress save** | Vortex IQ shows older | A running `BGSAVE` does not reset the clock until it completes; `LASTSAVE` will jump only when it lands. | | **Manual `SAVE` vs `BGSAVE`** | Either | Both update the timestamp; a blocking `SAVE` you ran by hand will reset the card the same as a scheduled `BGSAVE`. | | **Time zone** | Display only | The epoch is UTC; Vortex IQ computes the gap in UTC and renders age in your profile time zone. | | **Polling interval** | Up to \~1 min | The card re-reads on poll; a save in the last few seconds may show on `LASTSAVE` before the next Vortex IQ poll. | **Cross-connector reconciliation:** | Card | Expected relationship | What causes divergence | | ---------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | [`redis.last-successful-backup-hours-ago`](/nerve-centre/kpi-cards/redis/last-successful-backup-hours-ago) | Local save should be fresher than the offsite copy. | If local is fresh but offsite is stale, the shipping job is broken, not Redis. | | `INFO persistence:rdb_changes_since_last_save` | A large unsaved-changes count alongside a high age means real exposure. | Many unsaved changes plus high age equals a meaningful loss window on restart. | ## Known limitations / FAQs **This card reads 4 hours but Redis seems totally healthy. Is something wrong?** Probably not. RDB saves are triggered by the `save` rules, which are write-volume based. A quiet instance can legitimately go hours without crossing a rule. Run `CONFIG GET save` to see the rules and `INFO persistence` to read `rdb_changes_since_last_save`: if few keys have changed, the long gap is expected. If the gap matters for your data, tighten the rules or raise the alert threshold rather than treating it as a fault. **What is the difference between this card and the offsite Backup card?** This card measures the last RDB save to the node's own local disk. The Backup card measures the last copy that reached offsite storage. A local save survives a Redis process restart; only an offsite copy survives losing the node, disk, or region. You want both fresh: a tight RDB save age for fast local recovery and a tight backup age for disaster recovery. **The status is `err`. What does that mean and what do I do?** `rdb_last_bgsave_status = err` means the last save attempt failed. The two usual causes are (1) the fork failed because the OS could not allocate the copy-on-write memory (the instance is near full, or `vm.overcommit_memory` is not set to 1 on Linux), and (2) the disk is full or read-only. Check the Redis log for the exact error, free disk or memory, and confirm `vm.overcommit_memory=1`. Until a save succeeds, your local recovery point keeps ageing. **We only use AOF, not RDB. Should I ignore this card?** If RDB is genuinely disabled (`save ""` and no `dump.rdb`), this card may read a very high value or reflect the timestamp of an old snapshot. In that case the relevant durability signal is [Last AOF Rewrite Status](/nerve-centre/kpi-cards/redis/last-aof-rewrite-status), and you can lower the priority of this card in the Sensitivity tab. Many teams run both RDB and AOF; if you do, keep both cards green. **Does running a manual `BGSAVE` reset the alert?** Yes. Any successful save, scheduled or manual, blocking `SAVE` or background `BGSAVE`, updates `rdb_last_save_time` and resets the card. Forcing a `BGSAVE` is a valid way to clear a transient amber reading, but if the underlying cadence is too slow for your data, fix the `save` rules rather than relying on manual saves. **Why does a `BGSAVE` sometimes spike memory and latency?** `BGSAVE` forks the Redis process. The child shares memory with the parent via copy-on-write, so during the save any keys the parent modifies trigger page copies, growing RSS. On a write-heavy, near-full instance this can spike memory (watch [Memory Used vs Maxmemory %](/nerve-centre/kpi-cards/redis/memory-used-vs-maxmemory)) and briefly raise latency. `rdb_last_cow_size` in `INFO persistence` quantifies that copy-on-write footprint from the last save. *** ### Tracked live in Vortex IQ Nerve Centre *Last RDB Save (minutes ago)* is one of hundreds of KPI pulses Vortex IQ tracks across Redis and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.