Redis RDB snapshots, AOF logging, and recovery conditions

Redis can use RDB snapshots, an Append Only File (AOF), both, or no persistence. RDB saves a point-in-time representation of the dataset on configured conditions or on demand. It is useful for backup and transfer, but changes after the last successful snapshot may be absent after a failure. AOF records write commands for replay during startup. When both are enabled, startup preference and file format depend on Redis version and configuration, so check the documentation for the deployed release.

Expert perspective: operational trade-offs in Redis guidance

Redis’s published comparison of RDB and AOF advises choosing persistence based on tolerated loss and performance requirements. appendfsync everysec generally requests an fsync about once per second and is a common compromise, but it does not promise that a failure can lose no more than exactly one second of writes. OS scheduling, the failure mode, filesystem, and storage device’s flush guarantees affect the result. appendfsync always requests synchronization after command batches and before replies, but it is not an unconditional guarantee against every hardware or storage failure. Replication and backups remain separate protection layers.

Operational costs of snapshots and AOF rewrites

Background BGSAVE and AOF rewrite can fork a child process. Parent and child initially share memory pages; subsequent writes can trigger Copy-on-Write and raise peak memory use, depending on write rate and workload. The fork itself can also pause request processing, with impact determined by dataset size and operating-system conditions. There is no universal safe memory-headroom percentage. Measure peak RSS, fork duration, CoW growth, and free disk space under representative load. AOF rewrite produces a more compact representation of the current state plus ongoing changes; it is not an immutable audit record of every historical command.

Validate backups, replication, and recovery

RDB and AOF files are components of a backup strategy; they do not by themselves provide failover or point-in-time recovery. Replication can improve availability, but asynchronous lag leaves a possible loss window during failure. Test file integrity, off-host backup copies, compatibility with the deployed Redis and modules, restore time, and failover steps. Redis Software and Redis Open Source can expose different controls, so follow product-specific guidance. Set fsync and snapshot policies from an explicit recovery point objective and verify the resulting behavior through restore drills.

A hypothetical recovery timeline

Assume a Redis 7.x instance uses RDB only. Assume the successful RDB represents the logical dataset state at 12:00, when job:done equals 40. Background writing may finish later; file completion time is distinct from the snapshot data time. The value changes to 41 at 12:02 and 42 at 12:04; a failure occurs at 12:05 before another RDB completes. Restoring that file returns the key to 40 because the later writes are outside the snapshot. These values are illustrative; actual loss depends on snapshot completion and failure conditions (Redis persistence documentation).

AOF appendfsync everysec requests synchronization about once per second; it does not guarantee an exact one-second maximum loss for every failure. Redis describes buffering, fsync, and operating-system/storage behavior, so do not treat this setting as a hard bound across failure modes. If the recovery point objective matters, record the configuration and compare restored keys and application invariants in an isolated recovery drill.

A practical restore check can record these steps:

  1. Copy the backup or AOF set away from the source; record its checksum, size, and creation time. With multipart AOF in Redis 7 and later, preserve the manifest-referenced set rather than an arbitrary subset.
  2. Restore in an isolated instance using the same Redis release and required modules; do not overwrite production. Record load errors, truncation warnings, and persistence status.
  3. Check expected keys and values at the backup's point in time, plus application invariants. A matching total key count alone does not prove value correctness.
  4. Exercise representative read/write paths, measure restore time, and test failover steps. Record the backup timestamp and exactly what the drill verified.

This is an operational checklist for a team to test; it does not prove data consistency or recoverability without a drill.

References