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

Hi, it's BlueByte. The application is up, Redis answers PING, GET still returns data — and every single write comes back as (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. Nothing crashed. Redis is refusing writes on purpose because its last background save failed, and it wants you to find out now rather than at restore time. We'll walk through the two MISCONF replies, the four failures behind them, how to tell which one you have, the fix per cause, and how to be told next time before your users tell you.

Two MISCONF replies, and only one of them is about the snapshot

Redis has two errors that start with this prefix, and they point at different subsystems. The long one above is the RDB reply, raised when snapshotting is on and the last background save failed. The other is short and carries the operating system's own message:

(error) MISCONF Errors writing to the AOF file: No space left on device

That one is the append-only file, not the snapshot, and it is driven by aof_last_write_status rather than the RDB state. Read the whole reply before you start: the word after MISCONF decides which half of INFO persistence you care about.

Why one failed background save stops your writes on purpose

This is not a bug or a safety fuse that tripped by accident. It is the default, and redis.conf explains itself:

# By default Redis will stop accepting writes if RDB snapshots are enabled
# (at least one save point) and the latest background save failed.
# This will make the user aware (in a hard way) that data is not persisting
# on disk properly, otherwise chances are that no one will notice and some
# disaster will happen.
#
# If the background saving process will start working again Redis will
# automatically allow writes again.
stop-writes-on-bgsave-error yes

Two consequences worth holding onto. It only applies when at least one save point is configured, so an instance started with save "" never enters this state at all. And it clears itself: the moment one background save succeeds, writes are accepted again, with no restart and no config change. That is why the fix below ends with a single BGSAVE rather than a service restart.

The four failures behind it: space, permissions, a read-only mount, and fork

Redis writes the snapshot to a temporary file inside dir and renames it over dbfilename (dump.rdb by default) only once the file is complete. Each step fails with its own log line, which is what makes the log worth reading first:

• The disk filled. Write error while saving DB to the disk(...): No space left on device. Often the volume is shared with application logs, or old orphaned temp-*.rdb files from children that were killed mid-save are still sitting there.
• The directory isn't writable by the redis user. Failed opening the temp RDB file temp-2481.rdb (in server root dir /var/lib/redis) for saving: Permission denied. Typical after a container bind mount, a restore from backup unpacked as root, or a policy change.
• The rename step hit a read-only filesystem. Error moving temp DB file temp-2481.rdb on the final destination dump.rdb (in server root dir /var/lib/redis): Read-only file system. The child wrote the whole snapshot and then could not put it in place.
• fork() failed. Can't save in background: fork: Cannot allocate memory. Redis forks a child to write the snapshot and relies on copy-on-write, so in theory the child costs almost nothing. The FAQ explains why the kernel disagrees: with overcommit_memory at zero, Linux can't know in advance how many pages will change, so the fork fails unless there is as much free RAM as duplicating every parent page would take. In the docs' own example, a 3 GB dataset with 2 GB free will fail.

Read INFO persistence and the log before you change anything

Start with the state that decides whether writes are blocked, then the configuration it depends on:

redis-cli info persistence | grep -E 'rdb_last_bgsave_status|rdb_changes_since_last_save|rdb_last_save_time|aof_enabled|aof_last_write_status'
redis-cli config get dir dbfilename save stop-writes-on-bgsave-error

rdb_changes_since_last_save:184213
rdb_last_save_time:1758501902
rdb_last_bgsave_status:err
aof_enabled:0
aof_last_write_status:ok

1) "dir"
2) "/var/lib/redis"
3) "dbfilename"
4) "dump.rdb"
5) "save"
6) "3600 1 300 100 60 10000"
7) "stop-writes-on-bgsave-error"
8) "yes"

rdb_last_bgsave_status is documented as the status of the last RDB save operation, and err is the flag that turns writes off. rdb_last_save_time is the epoch timestamp of the last successful save — run date -d @1758501902 to see how long this instance has been running with nothing on disk, and rdb_changes_since_last_save to see how much would be lost. If aof_enabled is 1 and aof_last_write_status is err, you are in the AOF variant instead.

Now get the reason, which is only in the log and the filesystem:

sudo journalctl -u redis-server --since '2 hours ago' | grep -iE 'saving|fork|rdb'
df -h /var/lib/redis
df -i /var/lib/redis
stat -c '%n %U:%G %a' /var/lib/redis
sudo -u redis test -w /var/lib/redis && echo "writable by redis" || echo "NOT writable by redis"
cat /proc/sys/vm/overcommit_memory

Read the result as a short tree. A No space left on device line with df -h at 100% is the disk; df -i at 100% with space free is inodes. Permission denied with stat showing an owner other than redis is the directory. fork: Cannot allocate memory with /proc/sys/vm/overcommit_memory reading 0 is the kernel setting. Nothing here writes anything, so it is safe to run on the live instance.

Fix the cause, then prove it with one BGSAVE

Each cause has its own repair, and none of them needs a restart:

# Disk full: find what is using the volume, then list temp files left by killed children.
sudo du -xh --max-depth=1 /var/lib/redis | sort -h | tail -5
sudo find /var/lib/redis -name 'temp-*.rdb' -mmin +60 -ls
 
# Delete them only once no save is running — removing an in-flight child's
# temp file breaks that save. rdb_bgsave_in_progress must read 0.
redis-cli info persistence | grep rdb_bgsave_in_progress
sudo find /var/lib/redis -name 'temp-*.rdb' -mmin +60 -delete
 
# Directory not writable: hand it back to the redis user.
sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis
 
# fork: Cannot allocate memory — the setting the docs ask for, now and on reboot.
sudo sysctl vm.overcommit_memory=1
echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/60-redis-overcommit.conf

Then ask Redis to try again and watch the flag clear:

redis-cli bgsave
sleep 5
redis-cli info persistence | grep -E 'rdb_last_bgsave_status|rdb_last_save_time'
redis-cli set bluebyte:canary ok

Background saving started
rdb_last_bgsave_status:ok
rdb_last_save_time:1758616355
OK

The OK on the last line is the whole point: writes came back by themselves, because the status flipped, not because anything was restarted.

A worked example: a session store that filled its own volume

A session-store Redis on a 20 GB volume starts rejecting writes at 02:10. INFO persistence shows rdb_last_bgsave_status:err and an rdb_last_save_time four hours old; df -h reports the volume 100% full; the log carries Write error while saving DB to the disk(...): No space left on device repeating every save point. du finds a 5.8 GB dump.rdb, three orphaned temp-*.rdb files from earlier saves whose children were killed, and the application's own log directory on the same volume. The operator moves the logs to another filesystem, removes the orphaned temp files, and checks df -h reads 44% before touching Redis at all. Then redis-cli bgsave answers Background saving started, rdb_last_bgsave_status reads ok a few seconds later, and the next SET succeeds — no restart, no lost keys beyond what was already unsaved. The follow-up is the real fix: dir gets its own filesystem so an application log can never take Redis down again.

Turning the switch off is a workaround, and here is what it hides

If you need writes back this second and you accept the trade, there is a documented switch:

redis-cli config set stop-writes-on-bgsave-error no

The redis.conf comment is specific about when that is reasonable: if you have set up proper monitoring of the server and its persistence, you may want to disable the feature so Redis keeps working even when there are problems with disk or permissions. Note what you are buying. Writes resume instantly, the snapshot is still failing, and the only thing that changed is that nobody is being told. If the process restarts before a save succeeds, everything since rdb_last_save_time is gone. CONFIG SET also does not survive a restart unless you follow it with CONFIG REWRITE, so an instance "fixed" this way often re-blocks after the next deploy. Use it as a deliberate choice on a cache you can afford to lose, and keep an alert on the status either way.

Keep it from coming back

Alert on rdb_last_bgsave_status rather than on PING — an instance in this state answers PING perfectly. Size the machine for saving, not just for the dataset: the administration guide notes that in a write-heavy application, while saving an RDB file or rewriting the AOF, Redis can use up to twice the memory it normally uses, and it recommends setting an explicit maxmemory below physical RAM, so on a box with 10 GB free you set 8 or 9. Put vm.overcommit_memory = 1 in /etc/sysctl.conf as the same guide asks, and disable transparent huge pages with echo never > /sys/kernel/mm/transparent_hugepage/enabled. Give dir its own filesystem, and monitor free space against the size of dump.rdb, not against zero — a save needs room for a second copy before the rename. If an instance really is a pure cache, say so in the config with save "" instead of leaving save points enabled and the safety switch off.

How this differs from OOM command not allowed and READONLY

(error) OOM command not allowed when used memory > 'maxmemory'. is the memory limit, not the disk: the dataset hit maxmemory and the eviction policy has nothing it is allowed to evict. Reads work there too, which is why the two get confused, but INFO persistence will show rdb_last_bgsave_status:ok and the fix is maxmemory, the eviction policy, or less data. (error) READONLY You can't write against a read only replica. means you are connected to a replica rather than the primary — a routing or failover problem, with nothing wrong on disk at all. Check which error string you actually got before reaching for any of these.

Next time writes stop while reads keep working, walk these checks back in order: which MISCONF reply is it, what does rdb_last_bgsave_status say, what did the log record at the last save attempt, and only then decide between fixing the disk and accepting the trade.