About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.
Redis used only for reproducible cached data may be rebuilt without a data backup, if the application can tolerate the rebuild cost. But many teams end up storing data in Redis that is not reproducible: sessions, queues, counters, rate limits, leaderboards, job state. At that point, how Redis writes to disk, and whether copies leave the server, becomes a recovery question.
Redis holds its working data in memory. Whether anything survives a restart depends on its persistence settings. Its two persistence mechanisms protect against different failures, and neither, on its own, is a backup. This guide explains both, how to copy their files safely, the newer backup commands in recent versions, and a replication failure mode that can remove every copy at once.
Why it matters
The Redis persistence documentation is blunt: "Make Sure to Backup Your Database. Disks break, instances in the cloud disappear, and so forth: no backups means huge risk of data disappearing into /dev/null."
Persistence files on the same server protect against a process restart. They do not protect against losing the server, a mistaken command that empties the data, or a replication fault that copies an empty dataset everywhere.
How it works
Two persistence mechanisms
The documentation describes the options:
- RDB (Redis Database): "point-in-time snapshots of your dataset at specified intervals."
- AOF (Append Only File): "logs every write operation received by the server. These operations can then be replayed again at server startup, reconstructing the original dataset."
- No persistence: "sometimes used when caching."
- RDB + AOF: both in the same instance.
RDB snapshots
By default, the documentation says, "Redis saves snapshots of the dataset on disk, in a binary file called dump.rdb." It can save "every N seconds if there are at least M changes", or on request with the SAVE or BGSAVE commands.
For a background RDB save, Redis forks a child process, "The child starts to write the dataset to a temporary RDB file", and "When the child is done writing the new RDB file, it replaces the old one." This uses the operating system's copy-on-write behaviour, so the parent can keep serving clients after the fork. The synchronous SAVE operation differs and blocks service while saving; background save also needs memory and I/O headroom.
The example configuration file in the Redis source repository lists default save points: after an hour with at least one change, after five minutes with at least 100 changes, and after 60 seconds with at least 10,000 changes. (These are the development branch's comments; check the configuration your version actually uses.)
The documentation lists RDB's strengths for backup: it is "a very compact single-file point-in-time representation of your Redis data", "perfect for backups", and "very good for disaster recovery, being a single compact file that can be transferred to far data centers".
Its weakness is the gap between snapshots: "you'll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a correct shutdown for any reason you should be prepared to lose the latest minutes of data." Forking can also pause service briefly: "fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big".
Two configuration items matter for backup integrity (from the example configuration file). With stop-writes-on-bgsave-error yes, Redis "will stop accepting writes if RDB snapshots are enabled (at least one save point) and the latest background save failed", so that a failing disk is noticed rather than ignored. And with rdbchecksum yes, "a CRC64 checksum is placed at the end of the file", making the format "more resistant to corruption". Our recommendation: keep both enabled, and alert on failed background saves rather than turning the protection off.
The append-only file
The AOF records each write command. The documentation calls it "an alternative, fully-durable strategy", subject to how often it is flushed to disk. There are three settings:
appendfsync always: "Very very slow, very safe."appendfsync everysec: "you may lose 1 second of data if there is a disaster." This is "The suggested (and default) policy".appendfsync no: "Never fsync, just put your data in the hands of the Operating System."
Because the log keeps growing, Redis rewrites it in the background to "the shortest sequence of commands needed to rebuild the current dataset in memory."
Since Redis 7.0.0, the AOF is no longer one file. The documentation explains that it "is split into base file (at most one) and incremental files (there may be more than one)", which "are put in a separate directory and are tracked by a manifest file." The directory is set by appenddirname. A backup of the AOF is therefore a set of files plus their manifest, not one file.
When both RDB and AOF are enabled, "the AOF file will be used to reconstruct the original dataset since it is guaranteed to be the most complete."
Which to use
The documentation's guidance is to use both "if you want a degree of data safety comparable to what PostgreSQL can provide you." RDB alone suits those who "can live with a few minutes of data loss in case of disasters". It discourages AOF alone, "since to have an RDB snapshot from time to time is a great idea for doing database backups, for faster restarts, and in the event of bugs in the AOF engine."
What the AOF can and cannot recover
The documentation describes a limited recovery opportunity after a mistaken flush when an unrevised AOF still contains the earlier history. That possibility depends on the captured files and rewrite state; it is not a general undo facility.
This documentation example is not a general edit recipe for modern multipart or binary-base AOF sets. A specialist must inspect preserved files and their manifest before deciding whether useful pre-error history remains. Once rewritten history replaces the necessary files, this recovery route can be lost. Our recommendation: if a mistaken flush happens, stop and protect the AOF files before anything else, including before a rewrite can be triggered, and work on a copy.
On damaged files, the documentation separates two cases:
- Truncated at the end, for example after a crash or a full disk. Recent versions "load the AOF anyway, just discarding the last non well formed command in the file", controlled by
aof-load-truncated. - Corrupted in the middle. Redis "will complain at startup and will abort". The documented approach is to run
redis-check-aof"initially without the --fix option", understand the problem, and only then repair. The warning is specific: letting the tool fix the file may discard everything "from the invalid part to the end of the file", "leading to a massive amount of data loss if the corruption happened to be in the initial part of the file."
Our recommendation: always copy damaged files before any repair attempt. The documentation's own procedure for older versions starts with "Make a backup copy of your AOF file."
Copying RDB files safely
RDB files are easy to back up. The documentation explains: "you can copy RDB files while the database is running: the RDB is never modified once produced, and while it gets produced it uses a temporary name and is renamed into its final destination atomically using rename(2) only when the new snapshot is complete. This means that copying the RDB file is completely safe while the server is running."
Its suggested approach: hourly and daily copies in separate directories, old copies removed on a schedule (for example 48 hours of hourly copies and one or two months of daily copies), names that include date and time, and "At least one time every day make sure to transfer an RDB snapshot outside your data center or at least outside the physical machine running your Redis instance."
Copying AOF files safely
For Redis 7.0 and later, copying the AOF directory during a rewrite can produce "an invalid backup." The documentation's workaround is to pause automatic rewrites, confirm through INFO persistence that none is in progress, copy the files, and then re-enable rewrites. It also describes taking hard links to the files and re-enabling rewrites once the links exist, which shortens the pause, because Redis "only appends to files in this directory, or completely replaces them if necessary".
Two cautions (our recommendations). Record the previous rewrite setting before changing it, and confirm it is restored after the copy. A backup script that fails halfway and leaves rewrites disabled will let the AOF grow without limit.
The newer BACKUP commands
The current documentation describes a BACKUP command family "Since Redis 8.10.0" that "produces a self-contained, restorable backup without stopping writes or manually managing AOF rewrites." In outline, BACKUP START produces a fresh base snapshot, BACKUP SEAL freezes the set and writes a manifest, the files listed by BACKUP LIST are copied to backup storage, and BACKUP CLEANUP releases them. A restore of a sealed set "reflects the state at the seal boundary".
This is explicitly a Redis 8.10.0 documentation claim, not a feature promise for Redis 7 or every Redis 8 installation. Confirm availability in the released version you deploy and its own documentation before designing around it. The documentation also notes that with the default backup-sealed-ttl of 0, files "remain pinned until BACKUP CLEANUP is called", so cleanup needs to be part of the routine.
Restoring
In the same newer backup workflow, the documentation describes a startup setting, preload-file, which loads a specific RDB file or AOF manifest at startup. "When preload-file is set, Redis loads only the specified file or manifest and its associated files." It "skips the normal appenddirname and dump.rdb loading", and "If the preload target is missing or cannot be loaded, startup aborts."
Our reading of the restore: recovery is bounded by the captured persistence files, not by later activity on the old server. An RDB describes a snapshot and an AOF describes the usable captured command sequence. Expiry and application semantics still need checking: a matching key count alone is not proof that sessions, queues or job state are usable. If both persistence modes are enabled on the restore target, remember that Redis prefers the AOF on a normal start, so a restored RDB file placed beside an existing AOF directory may not be what loads.
The documentation's procedure for switching from RDB to AOF carries a related warning: "not following this procedure (e.g. just changing the config and restarting the server) can result in data loss!" Its steps include, after restart, "check that your database contains the same number of keys it contained previously." That check is a sensible part of any restore test.
Replication can wipe every copy
The replication documentation describes a failure mode every team using replicas should know. A primary with persistence turned off and an automatic restart crashes, comes back empty, and "Nodes B and C will replicate from node A, which is empty, so they'll effectively destroy their copy of the data."
The documentation strongly advises "to have persistence turned on in the master and in the replicas." Where that is not possible, instances "should be configured to avoid restarting automatically after a reboot". It adds that with Redis Sentinel, "the master can restart fast enough for Sentinel to not detect a failure".
The lesson: replicas protect availability, not history. A fault or a mistaken command on the primary arrives at every replica within moments. Only copies held elsewhere, and kept over time, protect against that.
Off-server copies
The persistence page recommends transferring snapshots off site and encrypted, and warns that "this system can easily fail if not implemented in the right way". It advises verifying "the file size (that should match the one of the file you copied) and possibly the SHA1 digest", and having "some kind of independent alert system if the transfer of fresh backups is not working".
The same page suggests automating transfers with an SSH key without a passphrase. If you do that, our recommendation is to restrict that key on the receiving server to the one transfer task and destination, so the Redis server cannot use it to change or delete older backups. Backups the source can overwrite are exposed to the same incident as the source.
What to choose and why
These are our recommendations, based on the documentation above.
- Decide whether Redis holds data you cannot rebuild. If so, treat it as a database, not a cache.
- Use RDB and AOF together where losing minutes of writes matters; RDB alone where it does not.
- Copy RDB files off the server on a schedule, with dated names, a retention plan and an off-site copy at least daily.
- Copy AOF directories only with rewrites paused (or by the hard-link method), or use the BACKUP commands if your version supports them.
- Never run a primary without persistence and with automatic restart where replicas hold the only other copies.
- Verify transfers by size and checksum, and alert on missing backups.
- Keep copies the Redis server cannot change.
- Test restores on a separate server, check the key count, and record how long loading took.
Risks and limits
- RDB loses writes since the last snapshot; AOF with the default setting can lose about a second.
- Forking can pause service on large datasets.
- AOF repairs can discard large amounts of data; copy first, inspect before fixing.
- Copying AOF during a rewrite can produce an invalid backup.
- A rewrite after a mistaken flush can remove the history needed for that recovery route.
- Replicas copy mistakes and empty restarts.
- The BACKUP commands are version-specific; the latest documentation read on 13 November 2026 identifies Redis 8.10.0. Confirm the released version you deploy supports them.
- Configuration examples came from the development branch of the example file; check your installed version's defaults.
- Nothing here was run. Behaviour is quoted from the documentation for planning.
Sources
- Redis documentation, Redis persistence: https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
- Redis documentation, Redis replication: https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
- redis/redis repository, example redis.conf (unstable branch): https://raw.githubusercontent.com/redis/redis/unstable/redis.conf
This article was originally published on .