RDB is NOT good if you need to minimize the chance of data loss in case Redis stops working (for example after a power outage).

On replicas, RDB supports partial resynchronizations after restarts and failovers.

RDB allows faster restarts with big datasets compared to AOF.

The parent process will never perform disk I/O or alike.

RDB maximizes Redis performances since the only work the Redis parent process needs to do in order to persist is forking a child that will do all the rest.

RDB is very good for disaster recovery, being a single compact file that can be transferred to far data centers, or onto Amazon S3 (possibly encrypted).

This allows you to easily restore different versions of the data set in case of disasters. For instance you may want to archive your RDB files every hour for the latest 24 hours, and to save an RDB snapshot every day for 30 days.

RDB is a very compact single-file point-in-time representation of your Redis data.

To learn more about how to evaluate your Redis persistence strategy, read on. If you'd rather not think about the tradeoffs between these different persistence strategies, you may want to consider Redis Enterprise's persistence options, which can be pre-configured using a UI.

RDB + AOF: You can also combine both AOF and RDB in the same instance.

No persistence: You can disable persistence completely.

Commands are logged using the same format as the Redis protocol itself. These operations can then be replayed again at server startup, reconstructing the original dataset.

AOF (Append Only File): AOF persistence logs every write operation received by the server.

RDB (Redis Database): RDB persistence performs point-in-time snapshots of your dataset at specified intervals.

Redis provides a range of persistence options. Persistence refers to the writing of data to durable storage, such as a solid-state disk (SSD).

Hard disk sentinel full version