Two ways Redis keeps data safe

Tue, 15 Jun 2027 00:00:00 +0000

RDB and AOF preserve different representations of Redis state. Choosing between them starts with two questions: how much recent data may be lost, and how long recovery may take? A persistence setting alone answers neither. You need a recoverable artifact, an understood acknowledgment policy, and a restore procedure tested against actual values.

A snapshot captures a point, not an interval guarantee

An RDB file is a compact point-in-time dataset. BGSAVE forks a child that writes a temporary file and replaces the previous snapshot when complete. The parent continues serving requests, but forking, copy-on-write memory, and disk work still have costs. SAVE instead writes synchronously and blocks other clients; reserve it here for the tiny isolated exercise.

A rule such as save 60 1000 requires both elapsed time and a change threshold. It does not promise a new snapshot every sixty seconds regardless of activity, nor successful completion on schedule. Recovery exposure follows the age of a usable snapshot, including missed or failed saves. Monitor successful saves and their results, not just the configured interval.

AOF changes the recovery representation

AOF records mutations and synchronizes them according to appendfsync. everysec normally exposes roughly the most recent second, while no delegates flushing to the operating system. always synchronizes before replies under its effective configuration, at additional cost. These policies do not protect against losing the storage device or guarantee that a promoted replica contains every locally persisted write.

Modern AOF uses a manifest, a base, and incremental files. Its base can be RDB-formatted, so “AOF always replays a huge textual history” is misleading. Rewriting removes unnecessary historical operations. File size, startup time, rewrite overhead, and latency must be measured for your dataset rather than inferred from the format’s name.

Running both is not an automatic merge

With ordinary startup settings and AOF enabled, Redis loads AOF rather than independently loading dump.rdb and replaying a separate log on top. The RDB-formatted base inside AOF is part of that file set. An independently retained RDB remains useful for backup and deliberate recovery, but it does not magically fill holes in incomplete AOF artifacts.

Do not switch an existing RDB deployment by merely editing appendonly and restarting. Follow Redis’s documented live conversion procedure, wait for successful initial AOF creation, and persist the configuration. The two cases below start with separate empty directories; they are not a migration recipe for an existing database.

When it breaks

A successful BGSAVE request is not a successful completed snapshot. Failed storage writes, unavailable fork resources, or inadequate disk space can leave the usable recovery point old. Inspect INFO persistence, error logs, and resource headroom. Background persistence can also worsen tail latency even while Redis remains responsive.

Neither file format is an independent backup if its only copy shares the server’s failure domain. Retain consistent copies outside that machine and test their restore. AOF can faithfully persist an accidental deletion; snapshots can already contain the same mistake. Retention history and application validation matter as much as a boot that accepts connections.

Check it quickly

Use a POSIX environment with a C compiler, make, curl, tar, and Python 3.10 or newer. This ran on macOS with Redis 8.10.1, redis-py 8.1.0, and Python 3.14.4. Build only Redis core with libc and install the client in the temporary virtual environment.

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

Run the Python block using "$redis_lab/venv/bin/python" in the same shell. Each case creates its own Unix-socket server, with no TCP listener or scheduled snapshots. Both explicitly save a tiny snapshot; only the second enables AOF with always and no fsync suppression during rewriting. SIGKILL targets only the created subprocess. Its files stay available for restart, then the temporary directory is removed.

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


for aof in (False, True):
 with TemporaryDirectory(prefix="redis-restore-", dir="/tmp") as directory:
 with instance(directory, aof) as (client, process):
 assert client.set("version", "snapshot")
 assert client.incr("counter") == 1
 assert client.save()
 snapshot = (Path(directory) / "dump.rdb").read_bytes()
 assert snapshot.startswith(b"REDIS")
 assert client.set("version", "after-snapshot")
 assert client.set("later", "present")
 assert client.incr("counter") == 2
 if aof:
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 crash(process)

 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 with instance(directory, aof) as (client, process):
 expected = ([b"after-snapshot", b"present", b"2"] if aof
 else [b"snapshot", None, b"1"])
 assert client.mget("version", "later", "counter") == expected
 assert client.dbsize() == (3 if aof else 2)
 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 print("RDB + AOF" if aof else "RDB only", expected)
print("an unchanged standalone RDB does not override enabled AOF recovery")

RDB-only recovers version snapshot, no later key, and counter one. The AOF case recovers version after-snapshot, the later key, and counter two. In both cases, the standalone RDB bytes remain unchanged across the crash and checked restart. The counter is deliberately incremented without an initial SET: replaying both increments over the snapshot would incorrectly produce three.

These assertions compare recovered state, not just whether Redis starts. SIGKILL bypasses graceful shutdown but does not crash the operating system or discard its cache. The experiment establishes snapshot boundaries and ordinary AOF startup selection, not power-loss survival, backup transport integrity, replica failover behavior, or production recovery time. Define those separate acceptance tests before making a stronger promise.

Sources

Redis persistence, snapshots, AOF startup selection, live conversion, and backups, checked 2026-09-08.
Redis SAVE, synchronous snapshot behavior and blocking cost, checked 2026-09-08.
Redis BGSAVE, background saving and request acceptance, checked 2026-09-08.
Redis INFO, persistence progress and result fields, checked 2026-09-08.
Redis 8.10.1 configuration, snapshot triggers and AOF policy, checked 2026-09-08.
Redis 8.10.1 build instructions, core-only build and allocator selection, checked 2026-09-08.