Redis Persistence: RDB, AOF or Neither?

Redis keeps its data in memory, which is why it is fast. It is also why teams are sometimes surprised after a restart, when keys they assumed were safe have disappeared. Redis persistence settings decide what survives a crash or a restart: nothing, a periodic snapshot, a log of every write or both. The right choice depends on what you store. A pure cache can often start empty; a queue, session store or rate limiter may not be able to. This guide explains the Redis persistence options, the trade-offs between them, how they interact with replication and how to choose settings for each way you use Redis.

Decide what Redis is for first

Before choosing settings, list what each Redis instance holds. Common uses include:

• A cache in front of a database, where data can be rebuilt from the source.
• Session data, where loss logs users out.
• Job queues and streams, where loss means work is never done.
• Counters and rate limits, where loss resets limits.

Each use tolerates data loss differently. Many teams find it simpler to run separate instances for caching and for data that must survive, so that each can have suitable settings. Our guide to Redis caching covers the cache use case in front of PostgreSQL.

The Redis persistence options

The Redis documentation lists the options (Redis: Persistence):

• RDB: point-in-time snapshots of the dataset at specified intervals.
• AOF, the append only file: a log of every write operation the server receives, replayed at startup to rebuild the dataset.
• No persistence: persistence disabled entirely, which the documentation notes is sometimes used when caching.
• RDB and AOF together in the same instance.

RDB snapshots

The documentation describes RDB files as a compact, single-file representation of the data that is well suited to backups and disaster recovery, and notes that RDB allows faster restarts with big datasets compared with AOF. To write a snapshot, Redis forks a child process that does the work, so the parent process does not perform disk I/O itself.

The main drawback is data loss between snapshots. The documentation says RDB is not a good fit if you need to minimise the chance of data loss when Redis stops working, because snapshots are usually created minutes apart, so you should be prepared to lose the latest minutes of data. It also warns that fork can be time-consuming with a big dataset and may cause Redis to stop serving clients for some milliseconds, or even a second when the dataset is very big and the CPU is not fast.

The append only file

AOF records every write, so less data is lost after a crash. How much less depends on the fsync policy. The documentation describes three settings:

• appendfsync always: fsync every time commands are appended. Very slow, very safe.
• appendfsync everysec: fsync every second. The documentation says this is fast enough and that you may lose one second of data in a disaster.
• appendfsync no: leave flushing to the operating system.

The trade-off is size and speed: AOF files are usually bigger than equivalent RDB files, and AOF can be slower than RDB depending on the fsync policy.

What the documentation recommends

The Redis documentation offers clear guidance. It suggests using both methods if you want a degree of data safety comparable to what PostgreSQL can provide. If you care about your data but can live with a few minutes of loss in a disaster, RDB alone may be enough. It discourages using AOF alone, because occasional RDB snapshots are useful for backups and faster restarts.

Persistence and replication

Replicas are not a substitute for persistence. The Redis replication documentation explains that replication is asynchronous by default, with the WAIT command available to request acknowledged copies, though it notes WAIT does not turn Redis into a strongly consistent system (Redis: Replication).

The same page describes a dangerous combination: a primary with persistence turned off and automatic restarts. If that primary crashes and restarts, it comes back empty, and its replicas then synchronise with it and are emptied too. The documentation strongly advises turning persistence on in the primary and replicas, and, where that is not possible, making sure instances do not restart automatically.

Worked example: settings per use

The table below is a hypothetical plan for a company running Redis for several purposes. It illustrates reasoning; confirm settings against the documentation for your version and hosting.

UseCan data be rebuilt?Acceptable lossPersistence choicePage and API cacheYes, from PostgreSQLAll of itNo persistence, separate instanceUser sessionsNoSmall; users may log in againRDB plus AOF with everysecBackground job queueNoAs little as possibleRDB plus AOF with everysec; jobs designed to be retriedRate limit countersPartlyShort gaps acceptableRDB snapshotsFeature flag cacheYes, from the flag serviceAll of itNo persistence

Notice that even with AOF set to every second, the queue row still assumes jobs can be retried. Design the application so that a small loss is survivable rather than relying on persistence alone.

Back up and test restores

Persistence files are not backups until they are copied somewhere else. Copy RDB snapshots off the server on a schedule, keep several versions and periodically restore one into a test instance to confirm it works and to measure how long it takes. Our guide to a disaster recovery plan explains how to set recovery time and recovery point objectives that guide these choices.

Managed Redis services

If you use a managed Redis service, persistence and backups may be configured through the provider's settings rather than the configuration file, and the options available may differ. Read the provider's documentation on what is persisted, how often backups are taken and how failover affects data, rather than assuming defaults.

Plan for restart time

Persistence affects how long Redis takes to come back. Loading a large dataset from disk takes time, and during that period the application may see errors or empty results. Measure restart time on realistic data in a test environment, decide whether the application should wait, fall back to the database or queue requests, and include that behaviour in your runbook.

Monitor persistence health

Watch for failed background saves, growing AOF files, long fork times and disk space. A failed save can go unnoticed until a restart reveals that recent data was never written. Alert on persistence errors as seriously as on memory or connection problems.

Frequently Asked Questions

Does Redis save data to disk?

It can. Redis offers RDB snapshots, an append only file that logs writes, both together or no persistence at all, depending on configuration.

What is the difference between RDB and AOF?

RDB takes periodic snapshots and may lose minutes of data in a crash. AOF logs every write and, with fsync every second, may lose about one second of data.

Should a Redis cache use persistence?

A cache whose data can be rebuilt from the source often runs without persistence. Keep it separate from Redis instances that hold data you cannot afford to lose.

Are replicas enough to protect Redis data?

No. Replication is asynchronous by default, and a primary that restarts empty can wipe its replicas. Use persistence and backups as well.

Keep fast data safe

We review how teams use Redis, choose persistence and backup settings for each use and test recovery. See our custom app development services, or talk to us about Redis persistence.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.