# ❌ Default Redis configuration — what ships out of the box
# redis.conf defaults (Redis 7.2 / Valkey 7.2):

# No AOF
appendonly no

# RDB with lenient triggers (saves only after significant changes)
save 3600 1      # Save if at least 1 key changed in 3600 seconds
save 300 100     # Save if at least 100 keys changed in 300 seconds
save 60 10000    # Save if at least 10,000 keys changed in 60 seconds

# Result: a server under moderate write load takes up to 5 minutes
# (the 300-second window) to trigger a snapshot.
# Crash mid-window → up to 5 minutes of writes are gone.

# Verify persistence config on a running instance
redis-cli CONFIG GET appendonly
# → appendonly: no

redis-cli CONFIG GET save
# → save: 3600 1 300 100 60 10000

# Check when the last successful RDB snapshot completed
redis-cli LASTSAVE
# → 1725350400  (Unix timestamp — compare against current time for staleness)

# Monitor BGSAVE status
redis-cli BGSAVE
# → Background saving started

redis-cli LASTSAVE     # Unix timestamp of last completed RDB
redis-cli INFO persistence | grep rdb
# rdb_changes_since_last_save: 14823
# rdb_bgsave_in_progress: 1           ← 1 means snapshot running now
# rdb_last_bgsave_status: ok
# rdb_last_bgsave_time_sec: 12        ← last snapshot took 12 seconds
# rdb_current_bgsave_time_sec: 8      ← current snapshot has run 8 seconds

# Force a foreground save (BLOCKS the server — never in production)
redis-cli SAVE
# → OK  (but all clients blocked for the save duration)

# Detect fork() latency in Redis logs
redis-cli LATENCY HISTORY fork
# timestamp   duration(ms)
# 1725350400  47
# 1725350700  52

# Or via slow log
redis-cli SLOWLOG GET 10 | grep -A4 "BGSAVE"

# redis.conf — RDB configuration

# Automatic save triggers (comment all out to disable automatic RDB)
save 3600 1
save 300 100
save 60 10000

# Filename for the RDB dump
dbfilename dump.rdb

# Directory where dump.rdb is written
dir /var/lib/redis

# If BGSAVE fails, stop accepting writes (fail loudly rather than silently lose data)
stop-writes-on-bgsave-error yes

# Compress the RDB file with LZ4 (slight CPU cost, significant size reduction)
rdbcompression yes

# Checksum the RDB file (CRC64 — detects corruption on load)
rdbchecksum yes

# redis.conf — appendfsync options

appendfsync always
# Every write command is fsync()'d to disk before returning OK to the client.
# Durability: Maximum — zero data loss on crash.
# Throughput: Severely limited — disk fsync() latency (~1-10ms) on every write.
# Throughput cost: typically 50-90% write throughput reduction vs no persistence.

appendfsync everysec
# fsync() is called by a background thread every 1 second.
# Durability: At most 1 second of data loss on crash.
# Throughput: Near-native — writes go to OS page cache synchronously; fsync runs async.
# Production default: this is the recommended setting for most workloads.

appendfsync no
# Redis never calls fsync(). The OS flushes the page cache at its own discretion (typically 30s).
# Durability: Up to ~30 seconds of data loss on crash (OS-dependent).
# Throughput: Maximum — equivalent to no persistence from Redis's perspective.
# Use case: when the OS's own flush schedule is acceptable, or when running a replica.

Write path without fsync():
  Redis write() → OS page cache (volatile RAM) → [process crash here = data lost]
                                                → [power loss here = data lost]
                                                → disk (eventually, when OS flushes)

Write path with fsync():
  Redis write() → OS page cache → Redis fsync() → [confirmed on disk]
                                                  → [process crash: safe]
                                                  → [power loss with battery controller: safe]
                                                  → [power loss without battery: may still lose]

redis-cli BGREWRITEAOF
# → Background append only file rewriting started

redis-cli INFO persistence | grep aof
# aof_enabled: 1
# aof_rewrite_in_progress: 1
# aof_rewrite_scheduled: 0
# aof_last_rewrite_time_sec: 45         ← last rewrite took 45 seconds
# aof_current_rewrite_time_sec: 12      ← current rewrite has run 12 seconds
# aof_last_bgrewrite_status: ok

# redis.conf
no-appendfsync-on-rewrite yes
# ❌ DANGER: When AOF rewrite is in progress, Redis stops calling fsync()
# for new writes to the main AOF buffer.
# Rationale: rewrite child is already doing heavy disk I/O; adding fsync()
# from the parent would cause I/O contention.
# Consequence: during the rewrite period (which can last MINUTES for large datasets),
# your data-loss window silently expands from 1 second to the FULL REWRITE DURATION.

# ✅ Safe default — keep fsync() running during rewrites
no-appendfsync-on-rewrite no
# Yes, this creates I/O contention during rewrites. Accept the throughput cost
# rather than silently expanding your data-loss window to match the rewrite duration.

# The pure AOF restart sequence (slow path):
# 1. Redis starts
# 2. Detects appendonly.aof
# 3. Opens aof file and begins sequential replay
# 4. Re-executes every SET, HSET, ZADD, EXPIRE... one by one
# 5. 3 hours later: server ready to accept connections

appendonly.aof (Hybrid format):
  ┌─────────────────────────────┬───────────────────────────────────┐
  │   RDB SNAPSHOT PREAMBLE     │   AOF DIFF TAIL                   │
  │   (binary, compact, fast)   │   (text commands since last snap) │
  │   Loaded in seconds         │   Replayed sequentially           │
  └─────────────────────────────┴───────────────────────────────────┘

# redis.conf — Hybrid mode (enable alongside AOF)
appendonly yes
aof-use-rdb-preamble yes     # Hybrid mode — the 2025 production default

# AOF rewrite triggers (when to compact the AOF)
auto-aof-rewrite-percentage 100   # Rewrite when AOF is 100% larger than the base
auto-aof-rewrite-min-size 64mb    # But only if the AOF is at least 64MB

# Manual snapshot (background, non-blocking)
redis-cli BGSAVE

# Check last successful snapshot timestamp
redis-cli LASTSAVE
# → 1725350400

# Convert to human-readable date
date -d @1725350400
# → Mon Sep  3 04:00:00 UTC 2026

# The RDB file location
redis-cli CONFIG GET dir
# → /var/lib/redis

redis-cli CONFIG GET dbfilename
# → dump.rdb

# Full path: /var/lib/redis/dump.rdb

# Scheduled off-box backup (cron example)
# Every hour: trigger snapshot, wait for completion, copy to S3

#!/bin/bash
redis-cli BGSAVE
# Wait for BGSAVE to complete
while [ "$(redis-cli INFO persistence | grep rdb_bgsave_in_progress | cut -d: -f2 | tr -d '\r')" = "1" ]; do
  sleep 1
done

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
aws s3 cp /var/lib/redis/dump.rdb \
  s3://my-redis-backups/dump_${TIMESTAMP}.rdb \
  --storage-class STANDARD_IA

# Verify AOF file integrity before using it for recovery
redis-check-aof /var/lib/redis/appendonly.aof
# → AOF analyzed: size=2147483648, ok_up_to=2147483600, diff=48
# → This AOF file is truncated (last 48 bytes are incomplete)

# Auto-fix truncated AOF (removes the incomplete trailing write)
redis-check-aof --fix /var/lib/redis/appendonly.aof
# → Truncated AOF repaired at offset 2147483600

# Verify RDB file integrity
redis-check-rdb /var/lib/redis/dump.rdb
# → [offset 0] Checking RDB file dump.rdb
# → [offset 26] AUX FIELD redis-ver = '7.2.1'
# → [offset 10485760] 100000 keys read so far
# → [info] 2500000 keys read
# → [info] Sanity check passed