Context
Redis can persist its in-memory dataset through RDB snapshots, append-only logging, or a combination. The important choice is the recovery behavior the application needs. A cache that can be rebuilt and a workflow storing important state require different decisions about acceptable loss, restart time, and operational evidence.
Prerequisites
Record the Redis version, deployment model, data purpose, persistence configuration, storage guarantees, backup process, and recovery objective. Obtain authorized read access to persistence status. Keep a separate test instance with no production client access. The current persistence documentation includes multipart AOF behavior introduced in Redis 7.0, so an older single-file backup script must be reviewed against the actual server version.
Review and test persistence
- Inspect effective persistence settings and
INFO persistence. Record whether AOF is enabled, snapshot behavior, last operation status, and background work. A file with a recent modification time does not establish that the intended persistence operation succeeded. Compare the running configuration with the configuration that will apply after a restart. - Translate each mechanism into a business recovery statement. RDB captures a point-in-time dataset, while AOF records write operations under a selected synchronization policy. The chosen fsync behavior, host storage, and failure mode affect what survives. Do not promise that a named setting creates an absolute end-to-end data-loss guarantee independent of the underlying platform.
- Inspect the backup capture procedure for consistency and completeness. Current multipart AOF uses a manifest and associated base and incremental files. Copying one familiar filename may omit required history. Use the documented capture approach for your deployment and avoid mixing files from different rewrite moments. Preserve the original artifact before running any repair utility.
- Restore the captured artifact to the isolated test instance and restart it with the intended configuration. Use known test keys and an application-level validation set to determine what was recovered. Measure startup and loading behavior locally. Rehearse interruption or disk-failure scenarios only in a disposable environment with a written expectation for what data may be absent.
Diagnostic table
| Observation | Risk | Next check |
|---|---|---|
| Persistence status reports failure | New durable state may be missing | Disk, permissions, and server logs |
| Only one AOF file was archived | Multipart set may be incomplete | Manifest and capture procedure |
| Restart uses unexpected data | Wrong artifact or configuration | Loading logs and backup identity |
| Background persistence strains memory | Copy-on-write pressure possible | Workload and host headroom |
Illustrative scenario
A team upgrades Redis but keeps a backup script that copies an old single-file AOF path. A restore rehearsal reveals that the saved material does not represent the complete current persistence set. The team updates capture to the supported procedure, preserves matching files together, and verifies known records after restart. The rehearsal discovers an artifact-boundary problem before the original server is needed for recovery.
Correct and verify
Repair the demonstrated storage or capture issue, then create and restore a fresh backup. Do not use a repair option on the only available artifact; some repairs intentionally discard damaged trailing data. Confirm recovered state, configuration persistence, and application behavior. A healthy replica is useful redundancy, but it is not a substitute for an independently recoverable backup when deletion or corruption propagates.
Operating procedure
Monitor persistence failures, background-operation duration, memory headroom, disk space, and backup verification age. Keep version-specific artifact requirements with the restore SOP. Test the selected recovery contract after upgrades or changes to storage and fsync policy, recording measured behavior rather than assuming the configuration name proves the outcome.
Explore Clouvenix backup disaster recovery for implementation and operational handover.