RDB Snapshots: Forking, Copy-on-Write, Save Rules, Startup Load, and Data-Loss Window

Learning outcomes

AtlasMart can tolerate losing a short interval of derived recommendation-cache changes after a crash, but operators need to know exactly what an RDB snapshot can recover. Redis Database (RDB) persistence is a point-in-time snapshot, not a continuous journal.

1. A snapshot is a recoverable point, not a write-by-write history

RDB captures the in-memory dataset at a point in time. A save rule such as save 60 1 means Redis may start a background snapshot after at least one change in roughly sixty seconds; it does not make each write durable. The recovery point objective (RPO) is therefore bounded by when a successful snapshot actually completed, not by when an application received an OK reply.

2. Build an isolated RDB-only node

docker volume create atlasmart-redis-ch17-rdb_datadocker run --rm -v atlasmart-redis-ch17-rdb_data:/data redis:8.10.1 sh -lc 'printf "%s\n" "user default off" "user academy-admin on >AtlasMart-Admin-Lab-Only-2026 ~* &* +@all" > /data/users.acl'docker run -d --name atlasmart-redis-ch17-rdb -p 127.0.0.1:6381:6379 -v atlasmart-redis-ch17-rdb_data:/data redis:8.10.1 redis-server --dir /data --aclfile /data/users.acl --appendonly no --save 60 1 --dbfilename dump.rdbdocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin PINGdocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin ACL WHOAMI# users.acl lives in the named volume, so academy-admin remains available after the deliberate restart/crash.

docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin CONFIG GET save appendonly dir dbfilenamedocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin INFO persistencedocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin LASTSAVE

3. BGSAVE forks; the parent keeps serving clients

On the Linux container, BGSAVE forks a child. The child serializes the snapshot while the parent continues accepting commands. Linux virtual-memory pages are initially shared; when the parent changes a page, copy-on-write creates a private copy. That is why a write-heavy workload during a large snapshot can temporarily increase physical memory.

docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin SET atlasmart:ch17:l1:before snapshot-v1docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin HSET atlasmart:ch17:l1:order:1001 status paid total_cents 2599docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin BGSAVEdocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin INFO persistencedocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin LASTSAVE

4. Inspect the immutable finished artifact

Redis writes an RDB to a temporary file and atomically renames it to the configured dbfilename after completion. Once produced, the finished RDB is not modified in place, which is why copying a completed RDB is safer than copying a live AOF set without a consistency plan.

docker exec atlasmart-redis-ch17-rdb sh -lc 'ls -lh /data/dump.rdb && stat /data/dump.rdb'docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin LASTSAVEdocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin INFO persistence

5. Prove the RDB data-loss window

After the successful snapshot, write a second key but do not trigger another snapshot. Then stop the process abruptly and start the same container again. Because the volume survives, Redis can load the previous dump.rdb; the later unsnapshotted key is expected to disappear. That is a controlled demonstration of RPO, not a claim about exact seconds of data loss in production.

docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin SET atlasmart:ch17:l1:after unsnapshotted-v2docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin GET atlasmart:ch17:l1:afterdocker kill atlasmart-redis-ch17-rdbdocker start atlasmart-redis-ch17-rdbsleep 1docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin MGET atlasmart:ch17:l1:before atlasmart:ch17:l1:afterdocker logs --tail 40 atlasmart-redis-ch17-rdb# Expected: before survives; after may be absent because it was written after the last completed RDB.

6. Startup load evidence and integrity

After restart, inspect INFO persistence and logs. Fields such as rdb_last_load_keys_loaded and rdb_last_load_keys_expired describe the most recent RDB load. A successful load proves that Redis parsed this artifact; it still does not prove the file was copied off-host, encrypted, retained, or periodically restore-tested.

docker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin INFO persistencedocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin DBSIZEdocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin GET atlasmart:ch17:l1:beforedocker exec -e REDISCLI_AUTH=AtlasMart-Admin-Lab-Only-2026 atlasmart-redis-ch17-rdb redis-cli --user academy-admin GET atlasmart:ch17:l1:after

7. Wrong approach: treat replicas or a local dump.rdb as backup

A replica normally reflects primary mutations and deletions, so application mistakes can propagate. A local RDB can also disappear with its host or volume. Persistence improves process-restart recovery; replication improves availability/read scaling; backup requires an independently retained artifact plus a tested restore path.

8. Verification checklist and cleanup

Verify the exact image/version, save rule, completed BGSAVE status, RDB file size, LASTSAVE change, expected key comparison after restart, and cleanup of only this node.

docker rm -f atlasmart-redis-ch17-rdbdocker volume rm atlasmart-redis-ch17-rdb_data# Removes only the named Chapter 17 container/volume. Never use docker system prune for this lab.

9. Production judgment

RDB is attractive when compact snapshots, fast restart, portable point-in-time files, and bounded data loss fit the workload. Size the node for fork latency and COW headroom; schedule snapshots with storage/CPU contention in mind; monitor latest_fork_usec, RDB duration/status, COW bytes, disk space, and snapshot age. For tighter RPO, pair RDB with AOF or another durable system rather than pretending a more aggressive save rule is free.

10. Summary and bridge

RDB gives compact point-in-time recovery with an explicit window between successful snapshots. Lesson 2 moves to AOF, where each write is logged but durability still depends on the fsync policy and storage behavior.

Authoritative references

• Redis persistence
• INFO
• BGSAVE
• LASTSAVE
• SAVE
• BGREWRITEAOF
• CONFIG GET
• CONFIG SET
• Redis 8.10 release notes
• Redis 8.10 whats new
• BACKUP
• Redis replication
• Redis Sentinel
• Redis Cluster specification
• Redis ACLs
• Redis latency diagnosis
• Redis memory optimization
• Redis security
• Redis licenses
• Docker Official Redis image