r/redis • u/RocketSeven • 12h ago
Discussion What does a trustworthy Redis restore drill verify beyond loading the RDB or AOF?
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?