Redis Tutorial 0/42 lessons ~6 min read Lesson 24

    RDB Snapshots

    RDB persistence writes a compact binary point-in-time snapshot (dump.rdb) — fast restarts and efficient backups at the cost of losing writes since last snapshot.

    Course progress0%
    Focus
    10 guided sections
    Practice signal
    Examples included
    Career prep
    Interview Q&A included

    Introduction

    RDB persistence writes a compact binary point-in-time snapshot (dump.rdb) — fast restarts and efficient backups at the cost of losing writes since last snapshot. BGSAVE forks a child process to write disk while master serves commands.

    save directives in redis.conf trigger snapshots after N changes in M seconds. fork() on large memory instances causes latency spikes via copy-on-write pressure — schedule BGSAVE off-peak.

    Combine RDB for backup cadence with AOF for finer recovery point objective.

    Understanding the topic

    Key concepts

    • SAVE — blocking snapshot; avoid production.
    • BGSAVE — background fork child writes RDB.
    • dump.rdb — single file restore point.
    • save 900 1 style rules in config.
    • LASTSAVE — Unix time of last success.
    • Partial sync possible after restart with replication.
    text
    flowchart LR
    Writes --> Memory
    Memory -->|fork| RDB
    Memory -->|append| AOF

    Step-by-step explanation

    1. Trigger via save rule, BGSAVE command, or shutdown.
    2. fork() creates child with shared memory pages.
    3. Child iterates keyspace writing compressed RDB.
    4. COW — parent writes duplicate pages on mutation.
    5. Complete RDB atomically renamed into place.

    Syntax reference

    Common commands

    • BGSAVE not SAVE in prod.
    • Monitor latest_fork_usec in INFO.
    • Copy RDB to S3 after BGSAVE for DR.
    bash
    BGSAVE
    LASTSAVE
    CONFIG GET save
    # redis.conf: save 900 1 save 300 10 save 60 10000

    Informative example

    Manual backup before migration — verify RDB file:

    bash
    redis-cli BGSAVE
    # wait for OK
    redis-cli LASTSAVE
    ls -lh /var/lib/redis/dump.rdb
    aws s3 cp dump.rdb s3://backups/redis/$(date +%F).rdb

    Stop writes or use REPLICAOF snapshot on replica for cold backup without master fork load.

    Real-world use

    Real-world use cases

    • Nightly backup to object storage.
    • Fast cold start after planned restart.
    • Disaster recovery baseline.
    • Clone staging from prod RDB (scrub PII).
    • Compliance point-in-time archive.

    Best practices

    • Run BGSAVE on replica when possible.
    • Leave RAM headroom for COW during fork.
    • Automate S3 upload with encryption.
    • Test restore quarterly — redis-check-rdb.
    • Pair with AOF for tighter RPO.
    • Alert on failed BGSAVE in logs.

    Common mistakes

    • SAVE on production master.
    • No off-site copy — datacenter loss = data loss.
    • Assuming RDB captures last second of writes.
    • Fork failure from overcommit disabled.

    Advanced interview questions

    Q1BeginnerRDB vs AOF?
    RDB compact snapshot; may lose minutes. AOF logs writes; tighter RPO.
    Q2BeginnerBGSAVE vs SAVE?
    BGSAVE background fork; SAVE blocks entire server.
    Q3IntermediateWhy latency spike during BGSAVE?
    fork + copy-on-write as keys mutate during snapshot.
    Q4IntermediateRestore from RDB?
    Stop Redis, replace dump.rdb, start — or RESTORE command for single key.
    Q5AdvancedBackup strategy for 50GB Redis?
    Replica BGSAVE, stream RDB to S3, AOF everysec on master, quarterly restore drill.

    Summary

    RDB = point-in-time binary snapshot.

    Ready to mark this lesson complete?Track your journey across the entire course.