MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk

What it means

With RDB snapshots on, Redis saves its data in the background when a save point is reached (for example save 60 1000: after 60 seconds if at least 1,000 keys changed). It forks a child process that writes a temporary file in dir, then renames it to dump.rdb.

If that save fails, and stop-writes-on-bgsave-error is yes (the default), Redis stops accepting writes. The point is to make the failure impossible to miss: otherwise Redis would go on taking writes it can’t keep. Reads still work. Nothing you sent was written.

Three things must all be true:

• at least one save point is configured (with save "" you never see this error);
• stop-writes-on-bgsave-error is yes;
• the latest background save failed.

Redis keeps retrying the save, and writes come back by themselves as soon as one succeeds. The message doesn’t say what went wrong; the log does.

With AOF persistence, a failed write to the append-only file stops writes in the same way, with a shorter message that includes the reason: MISCONF Errors writing to the AOF file: <reason> (from Redis’s source; we didn’t reproduce that one).

Common causes

1. The disk is full. Log: Write error while saving DB to the disk(rdbSaveRio): No space left on device. The snapshot needs room for a full copy, written beside the old one before the rename.
2. Redis can’t write to its directory. Log: Failed opening the temp RDB file temp-<pid>.rdb (in server root dir <dir>) for saving: Permission denied, or Read-only file system. Common in Docker when a mounted volume belongs to another user (the official image runs Redis as redis), or when dir points somewhere it shouldn’t.
3. fork() fails. Log: Can't save in background: fork: Cannot allocate memory. On Linux this happens with a large dataset when vm.overcommit_memory is 0: the kernel refuses a child that could, in theory, need as much memory again. Redis’s docs recommend setting it to 1. (We didn’t reproduce this one.)
4. Someone changed dir or dbfilename. Redis’s security page warns that a client allowed to run CONFIG can point them anywhere, to write files to other paths. A directory Redis can’t write to makes the next save fail. If CONFIG GET dir shows a directory you didn’t set on a server that is reachable without a password, treat it as a break-in.

How to fix it

Read the log

grep -E 'Background saving|RDB|fork' /var/log/redis/redis-server.log | tail
docker logs <container> 2>&1 | grep -E 'Background saving|RDB|fork' | tail

The line before Background saving error says why the save failed; if fork() failed, there’s a Can't save in background: fork: … line instead. INFO persistence confirms the state:

rdb_changes_since_last_save:1
rdb_last_bgsave_status:err
rdb_saves_consecutive_failures:1

Fix the cause

• Full disk: free space on the volume that holds dir (df -h); old RDB copies, logs and core files are the usual suspects. Keep free space of at least the size of dump.rdb, plus room for the AOF if you use it.
• Permissions: make dir writable by the user Redis runs as, for example chown -R redis:redis /data, or fix the ownership of the Docker volume.
• fork: sysctl vm.overcommit_memory=1, and add vm.overcommit_memory = 1 to /etc/sysctl.conf so it survives a reboot. Make sure the machine has memory to spare: while it saves, a busy server can use up to twice its normal memory.

Then save and check:

redis-cli BGSAVE
redis-cli INFO persistence | grep rdb_last_bgsave_status    # rdb_last_bgsave_status:ok

Writes are accepted again as soon as a save succeeds.

Moving the data directory needs a restart

Since Redis 7, dir and dbfilename are protected settings: CONFIG SET dir is refused unless enable-protected-configs allows it:

(error) ERR CONFIG SET failed (possibly related to argument 'dir') - can't set protected config

Change dir in redis.conf and restart instead.

Writes back now, while you fix it

redis-cli CONFIG SET stop-writes-on-bgsave-error no

Writes resume at once, but nothing is being saved: if Redis restarts before a save succeeds, every change since the last good snapshot is lost. Set it back to yes once saves work. If Redis is a pure cache and you don’t need snapshots at all, CONFIG SET save "" turns them off (and with them, this error); put the same in redis.conf.

Reproduce it

A temporary Redis 8.10.2 container whose data directory is a read-only tmpfs, with a save point of one change per second:

docker run --rm -d --name seo-redis-misconf --tmpfs /ro:ro redis:8 redis-server --dir /ro --save "1 1"

SET greeting hello returned OK, then the save failed. Three seconds later SET greeting bye and DEL greeting got:

(error) MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.

GET greeting still returned "hello". The log:

* 1 changes in 1 seconds. Saving...
* Background saving started by pid 44
# Failed opening the temp RDB file temp-44.rdb (in server root dir /ro) for saving: Read-only file system
# Background saving error

The same lines came back every few seconds as Redis retried. CONFIG SET dir /data was refused as a protected config (the error above); CONFIG SET stop-writes-on-bgsave-error no let SET through straight away.

A second container with a 1 MB tmpfs as dir, 100,000 keys and the same save point:

# Write error while saving DB to the disk(rdbSaveRio): No space left on device

and the same MISCONF reply to the next SET. A third, whose tmpfs belonged to root while Redis ran as redis, logged for saving: Permission denied; it had no save points (--save ""), and there a failed manual BGSAVE didn’t stop writes.

Valkey 8.1.10, with a read-only dir, names itself and its logs: MISCONF Valkey is configured to save RDB snapshots, … Please check the Valkey logs for details about the RDB error.

In Inlet

Inlet shows the server’s message and links it to this page. In a query tab, INFO persistence shows as a table, so rdb_last_bgsave_status and rdb_changes_since_last_save are easy to check after you fix the cause. On a connection tagged production, Inlet refuses write and admin commands such as CONFIG SET before they’re sent.