Use RDB snapshots for backups and AOF for durability, and keep both on if Redis holds data you care about. RDB files are compact and safe to copy while the server runs. Copy them off the machine on a schedule, and set an alert for when the copy fails.
What each mode gives you
The Redis documentation describes RDB as point-in-time snapshots at set intervals, and AOF as a log of every write that is replayed at startup. You can also run with no persistence, which is sometimes used for pure caches, or combine both.
RDB strengths: a single compact file, good for archiving and moving to a far location, fast restarts for large datasets. Weakness: you may lose the last few minutes after a crash, since snapshots are usually five minutes apart or more.
AOF strengths: far better durability. With the default of fsync every second you can lose about one second of writes. Weakness: bigger files, and speed depends on the fsync policy.
The documentation's guidance is to use both if you want data safety comparable to PostgreSQL. If you can live with a few minutes of loss, RDB alone is fine. It discourages AOF alone, partly because occasional RDB snapshots make good backups.
Is it a cache or a datastore?
Decide this before anything else. If Redis only holds data you can rebuild from another source, no persistence may be the right choice, and your recovery plan is rebuilding the cache. If it holds queues, sessions you cannot lose or primary data, treat it as a datastore and back it up.
Backing up safely
For RDB, the documentation says copying the file is completely safe while the server runs: the file is never modified once produced and is renamed atomically when complete. Its suggested routine is hourly snapshots kept for about two days, daily snapshots kept for a month or two, and at least one daily copy outside the data centre or at least off the machine.
For AOF on Redis 7 and later, copying the directory during a rewrite can give you an invalid backup. The documented workaround is to disable automatic rewrites, confirm none is running, copy the files, and re-enable rewrites. Hard links shorten the window.
Off host copies that actually arrive
The docs warn that a transfer scheme can easily fail if built wrong. Verify file size and a checksum after transfer, and set up an independent alert for when fresh backups stop arriving. If you encrypt the copy, store the password in several safe places, because a backup you cannot decrypt is worthless. More on that in backup encryption keys.
A switch to AOF can lose data
The documentation is blunt that enabling AOF by just editing the config and restarting can lose data. Enable it on the live server with a config set command, then update the config file so the change survives a restart. Take a copy of dump.rdb first.
Test the restore
Load a copy of the file into a scratch instance and compare key counts with production. See the general method in our restore test guide.
Safeguard's asset discovery can help you find Redis instances you forgot about, and the free scan at gold.safeguard.sh/scan covers dependencies.
Quick check
Can I copy dump.rdb while Redis is running?
Yes. The Redis documentation says it is safe, because the file is replaced atomically once a snapshot completes.
Is AOF alone enough?
It works, but the Redis docs discourage it because periodic RDB snapshots make useful backups and help with restarts.
Sources
Last reviewed: 19 October 2026.
