Redis Persistence RDB vs AOF Compared

By Kokil Thapa | Last reviewed: September 2026

Redis keeps data in memory for speed, but a restart or crash wipes the keyspace unless you enable persistence. Redis persistence RDB vs AOF compared is the first decision every team faces after adding Redis to a Laravel queue, session store, or cache layer. RDB writes periodic point-in-time snapshots; AOF logs every mutating command. The wrong choice costs you stale cache, lost jobs, or slow restarts. This guide walks through how each mode works on Redis persistence and clustering, when to pick one, and how to run a hybrid setup in production.

What is Redis persistence and why does RDB vs AOF matter?

Redis is an in-memory data store. Without persistence, power loss or redis-cli SHUTDOWN NOSAVE clears every key. Persistence writes memory to disk so a restart reloads your data.

Two built-in mechanisms exist in Redis 8.10:

• RDB (Redis Database) — forked background snapshots written to dump.rdb.
• AOF (Append Only File) — an append log of mutating commands, replayed on startup.

On real client projects I treat Redis as infrastructure, not a throwaway cache. Queue workers, rate limiters, and session stores need a defined recovery point. That is where Laravel queues with Redis production setup and persistence settings intersect.

Pure cache layers on Redis caching patterns for web apps can skip persistence. Anything that holds business state should not.

How does Redis RDB snapshot persistence work?

RDB creates a binary snapshot of the dataset at a point in time. Redis forks a child process; the parent keeps serving requests while the child writes dump.rdb.

Trigger methods

RDB saves happen in three ways:

1. Automatic saves — controlled by save directives in redis.conf.
2. Manual saves — SAVE (blocking) or BGSAVE (background).
3. Shutdown save — default behaviour on graceful shutdown unless disabled.

# redis.conf — save if at least 1 key changed in 900 seconds
save 900 1
save 300 10
save 60 10000

# snapshot file location
dbfilename dump.rdb
dir /var/lib/redis

# optional: stop writes if background save fails
stop-writes-on-bgsave-error yes

RDB strengths and limits

RDB files are compact and fast to restore. A 2 GB dataset often compresses to a few hundred megabytes. Restarts load one file instead of replaying millions of commands.

The trade-off is granularity. If Redis dies between saves, you lose everything written since the last snapshot. With save 900 1, that window can be up to 15 minutes.

Large datasets pay a fork cost. Copy-on-write memory spikes during BGSAVE can trigger OOM on small VPS boxes. I've seen this on shared EC2 hosts running Redis alongside PHP-FPM. Monitor RSS during saves.

How does Redis AOF append-only file persistence work?

AOF records every write command as Redis protocol text. On startup, Redis replays the log to rebuild the keyspace. Official docs at redis.io persistence documentation describe both modes in detail.

Enabling and syncing AOF

# redis.conf
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec

# rewrite when AOF doubles
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

The appendfsync setting controls durability vs throughput:

• always — fsync after every write. Safest, slowest.
• everysec — fsync once per second. Default for most teams.
• no — let the OS buffer writes. Fastest, least safe.

AOF rewrite

Logs grow forever without compaction. BGREWRITEAOF forks a child that rebuilds a minimal command set representing the current dataset. The parent appends new writes to an incremental buffer during rewrite.

After rewrite, Redis swaps the old AOF for the new file atomically. Disk usage drops sharply on write-heavy workloads with TTL keys.

For Redis data structures beyond cache, AOF preserves every increment on counters and list pushes. That matters when Redis holds more than simple key-value cache entries.

Redis persistence RDB vs AOF compared: which wins in production?

Neither mode is universally better. The choice depends on acceptable data loss, restart time, disk I/O, and memory headroom.

Verdict: Use hybrid persistence for anything that survives a reboot. Enable AOF with appendfsync everysec. Keep RDB saves for backup portability and faster cold starts. Disable both only when Redis is a pure cache with cold rebuild acceptable.

Compare this with Redis vs Memcached vs Dragonfly when evaluating whether you need persistence at all. Memcached has none by design.

Laravel and PHP workload mapping

On production Laravel applications I've maintained, the split looks like this:

• Queue backend — hybrid persistence. Lost jobs after crash are painful.
• Session store — AOF with everysec. Users tolerate one second of session loss at most.
• Application cache — often no persistence. Rebuild from MySQL on miss.
• Rate limiting counters — AOF or hybrid. Gaps allow abuse windows.

See also Laravel cache tags with Redis vs Memcached and Redis caching to speed up Laravel PHP apps for cache-specific tuning that sits beside persistence choices.

How do you configure Redis persistence in redis.conf for production?

A practical hybrid config for Redis 8.10 on Ubuntu 24 with Laravel queue workers:

# --- RDB ---
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis

# --- AOF ---
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 128mb
aof-use-rdb-preamble yes

# --- safety ---
stop-writes-on-bgsave-error yes
aof-load-truncated yes

Post-config verification

After editing config, validate before the next incident:

1. Run redis-cli CONFIG GET appendonly and confirm yes.
2. Trigger redis-cli BGSAVE and check INFO persistence for rdb_last_bgsave_status:ok.
3. Trigger redis-cli BGREWRITEAOF and confirm rewrite completes.
4. Stop Redis gracefully, start it, and verify key count matches expectations.
5. Copy dump.rdb to a staging host and prove cold restore works.

Server hardening belongs with Linux system administration and ongoing support and maintenance. Persistence files need the same backup discipline as MySQL dumps.

For Symfony stacks, see Symfony cache component with Redis and APCu. WordPress object cache setups are covered in WordPress object cache with Redis setup.

Monitoring persistence health

Add these checks to your monitoring stack or testing and optimization runbook:

redis-cli INFO persistence | egrep 'rdb_last_bgsave_status|aof_last_bgrewrite_status|aof_last_write_status'

# expected: all "ok"

Alert on rdb_last_bgsave_status:err or disk full on /var/lib/redis. A failed background save with stop-writes-on-bgsave-error yes blocks all writes. Your app will look healthy while Redis rejects SET commands.

What happens when Redis restarts after a crash?

Startup order matters when both files exist. Redis 8.10 loads the AOF if appendonly yes and the file is present. Otherwise it loads dump.rdb.

With hybrid mode and aof-use-rdb-preamble yes, the AOF begins with an RDB-encoded preamble followed by the incremental command tail. Restarts stay fast while durability remains strong.

Failure scenarios

Graceful shutdown: Redis flushes AOF and saves RDB by default. Clean recovery.

Kill -9 / power loss: You lose at most one second of writes with everysec AOF. RDB alone loses everything since the last snapshot.

Truncated AOF after disk full: Set aof-load-truncated yes so Redis loads the valid prefix and logs a warning. Review Redis configuration reference for related directives.

Corrupt RDB: Redis refuses to start. Restore from off-host backup. This is why nightly dump.rdb copies matter.

On a booking platform like Adventure Third Pole Trek, Redis backs Livewire session state and queue jobs. A bad persistence plan surfaces as duplicate bookings or lost payment webhooks after an overnight reboot.

Replication as a second layer

Persistence protects against process death. It does not protect against disk failure or accidental FLUSHALL. Add a Redis replica on a second node for read scaling and hot standby.

Replicas receive the stream of writes from the primary. Combine replica lag monitoring with disk persistence for a defensible recovery story. Real-time features using WebSockets and Redis in Laravel should document their maximum acceptable lag explicitly.

Enterprise deployments often pair Redis with managed failover. For custom architecture review, see enterprise application development and API development in Nepal.

Key Takeaways

• RDB gives compact snapshots and fast restarts but loses data written between save intervals.
• AOF with appendfsync everysec limits loss to about one second on most Linux hosts.
• Hybrid mode with aof-use-rdb-preamble yes is the practical production default for queues and sessions.
• Disable persistence only when Redis is a true cache and cold rebuild from MySQL is acceptable.
• Test restore from dump.rdb on staging quarterly — backups you never restore are guesses.
• Monitor INFO persistence and disk space on /var/lib/redis before writes silently fail.

People Also Ask

Can you use RDB and AOF together in Redis?

Yes. Enable both in redis.conf. With aof-use-rdb-preamble yes, AOF rewrites embed an RDB snapshot as a preamble. You get AOF durability plus faster restarts. This is the recommended setup for production workloads that cannot tolerate large data gaps.

How much data can you lose with Redis AOF everysec?

At most about one second of writes under normal conditions. A crash during fsync could lose the last second of buffered commands. For stricter guarantees, set appendfsync always, but expect lower write throughput on busy instances.

Is RDB enough for Laravel Redis queues?

RDB alone is risky for queues. A save 900 1 rule means up to 15 minutes of queued jobs may vanish after a hard crash. Enable AOF with everysec for queue backends, or accept explicit job loss and design idempotent workers.

Does Redis persistence slow down cache reads?

Reads stay in memory and remain fast. Persistence adds disk I/O on writes and periodic fork overhead during BGSAVE or BGREWRITEAOF. Pure read-heavy caches feel little impact unless a background save coincides with memory pressure.

Pick the right Redis persistence model for your stack

Redis persistence RDB vs AOF compared boils down to how much data you can afford to lose and how fast you must recover. Snapshots alone suit warm-cache scenarios. Append logs protect operational data like jobs and sessions. Hybrid configs cover both without forcing an either-or trade-off.

Document your recovery point objective before the next server patch. Validate config with INFO persistence, ship off-host RDB backups, and rehearse a cold restore once per quarter. Use the JSON formatter when inspecting queue payloads during recovery drills.

Need Redis wired correctly into Laravel queues, cache, and deployment? Review the portfolio for production examples or contact us to audit your persistence and failover setup.