Persistence Interview Questions

RDB is a fork-and-snapshot point in time; AOF is a rewriteable log of write commands. RDB restarts faster; AOF with appendfsync everysec loses at most about one second. Many teams enable both so a truncated AOF can still fall back to the last RDB.

appendfsync always fsyncs every write, everysec batches, and no leaves it to the OS. always crushes throughput; no risks more loss after a power fail. everysec is the usual production compromise interviewers expect.

AOF rewrite produces a shorter file that reconstructs the same dataset; it is not a second database engine. After rewrite, Redis still uses the AOF fsync policy you chose. Leaving AOF on without rewrite is how disks fill.

Restoring means placing dump.rdb or appendonly.aof in the data dir and starting Redis, or cloning a replica then replicaof no one. Test restore on a spare host; an untested RDB is not a backup. Match Redis version or know RDB format compatibility.

save "" disables RDB snapshots; appendonly no disables AOF. A cache with eviction often runs with both off and accepts total loss. A session or job store that people call a cache but cannot lose should not use that profile.

Diskless replication via repl-diskless-sync streams the RDB to replicas over the socket instead of writing a temp file on the primary. Use it when the primary disk is the bottleneck. Replicas still need room if they persist locally.

Replica persistence is per process: a diskless sync on the primary does not decide whether the replica writes AOF or RDB. A replica with save "" and appendonly no is RAM-only and cannot rebuild after its own crash without a full resync. Set replica persistence explicitly.

fork copy-on-write during BGSAVE duplicates pages the parent dirties while the child writes the RDB. A heavily written dataset during save can briefly approach 2x RSS. That is why saves on a saturated primary cause latency spikes.

BGREWRITEAOF rewrites a compact AOF in a child using copy-on-write, similar to BGSAVE. The parent keeps appending to a buffer. A rewrite storm plus a big dataset means COW memory spikes you must size for.

Mixed RDB plus AOF load can use an RDB preamble inside the AOF so restart is faster than replaying every write. Misconfigured preamble after an upgrade is a common surprise. Know which files you are actually shipping as backups.

shutdown save versus shutdown nosave decides whether you take a last RDB on stop. Kubernetes SIGTERM without a save can lose the last everysec window. PreStop hooks that run BGSAVE or wait for AOF fsync are the ops answer.

Checking persistence health means INFO persistence: last_save, aof_rewrite_in_progress, rdb_last_bgsave_status. A failed BGSAVE that nobody alerts on is a silent backup hole. Also watch fork time in LATENCY DOCTOR.

Replica as backup source means BGSAVE or copy files from a replica so the primary does not fork under load. Never copy a live RDB while it is being rewritten. Wait until rdb_last_bgsave_status is ok.

AOF fsync everysec still loses writes in the last second plus any that were in the rewrite buffer during a crash at the wrong time. Quote that window. Applications that need stronger durability need appendfsync always or a disk database.

COW fragmentation after repeated BGSAVE can raise mem_fragmentation_ratio even when used_memory looks stable. activedefrag or a rolling restart of replicas recovers it. Persistence load is an operations memory problem, not just a disk problem.

Enabling AOF on a huge already-running instance rewrites history and can stall; do it on a replica, wait for catch-up, then failover. Big-bang appendonly yes on the only primary is a late-night incident.

rdbchecksum and AOF load errors can make Redis refuse to start on a truncated AOF unless you redis-check-aof --fix, which discards a tail. Know that --fix is data loss. Prefer keeping the last good RDB.

Replication backlog via repl-backlog-size is not AOF; it is a circular buffer for partial resync (PSYNC). Undersize it and replicas do full RDB resyncs after a blip. That full resync is a persistence-adjacent outage.

Modules and AOF: some module writes must be AOF-aware or they will not survive restart. RedisJSON and RedisBloom need persistence enabled if you treat them as source of truth. A cache-only policy silently drops module data.

Point-in-time restore in Redis is last RDB plus AOF up to crash, not WAL-level PITR like Postgres. If you need arbitrary-time restore, ship RDB snapshots to object storage on a schedule. Redis alone is not a backup product.