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.

Metrics type: Supporting Metrics • Category: Persistence

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”:

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 % because a near-full instance can fail to fork.

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), 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)	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	The other persistence mechanism.	If RDB saves are failing, a healthy AOF is your fallback recovery point, and vice versa.
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	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	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)	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	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, and you can lower the priority of this card in the Alert Rules 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 %) 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 or book a demo to see this metric running on your own data.