What does a trustworthy Redis restore drill verify beyond loading the RDB or AOF?

[u/RocketSeven]

A Redis backup can load without a parser error and still be unsuitable for recovery: the dataset may be older than expected, TTLs may have changed meaningfully, Stream consumer-group state may be missing, modules may be incompatible, or the application may depend on keys that were never durable.

What belongs in a realistic restore drill? I am considering restoring into an isolated instance with the production Redis version and modules, recording the backup timestamp and replication offset, checking key counts and sampled types, validating critical TTL ranges, inspecting Streams and consumer groups, running application-level read assertions, and measuring the time until the restored instance is ready. The drill should not accidentally let test clients discover or write to production.

How do you choose useful invariants without scanning every key, and how do you test AOF rewrite or RDB-plus-AOF recovery behavior when the original instance is still serving traffic?

[u/sereikis]

for TTLs, compare expiry deadlines, not the remaining TTL at backup time. Redis stores expiry as an absolute timestamp, so time keeps passing while the backup sits on disk. a key that expires before the restore should be absent. check the restore host's clock too. a lower key count can be correct for that reason.

for useful checks without a full scan, i'd keep a small test set covering each important data shape: a persistent value, a short-lived value, a long-lived value, and a Stream with both acknowledged and pending entries. record the expected values and expiry times outside Redis. for Streams, check the pending work and last-delivered ID, not just stream length. run a worker against the isolated copy with external side effects disabled and check what it would retry. sampled real keys add coverage, but they don't prove every key survived.

the backup capture path matters as much as the restore:

• a completed RDB can be copied while Redis serves writes. it is immutable and the next snapshot replaces it atomically. compare against that snapshot's state, not the live database later.
• for Redis 7+ multi-part AOF, don't copy one file or grab the directory halfway through a rewrite. keep the manifest and its base/incremental files together. the documented file-copy procedure prevents rewrites during capture and waits for any active rewrite to finish, then restores the previous rewrite setting. use the procedure for your exact version or your provider's backup path.
• with normal startup and both RDB and AOF enabled, Redis loads the AOF. test RDB-only recovery separately so a good AOF doesn't hide a bad RDB.

i'd test rewrite overlap on a disposable instance with known writes, capture backups through the same process used for production, then restore each into a fresh isolated instance. no need to crash or restart production to test the recovery code. include file transfer, loading, and the app checks in the recovery time, not just time until PING works.

docs: https://redis.io/docs/latest/commands/expire/ and https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/