Redis MISCONF "unable to persist to disk" - Causes and Fixes

Redis refuses write commands with this error when its latest background snapshot failed and the setting stop-writes-on-bgsave-error is yes, which is the default. Reads still work. The idea is to alert you that your data is not being saved, rather than letting you believe it is.

(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.

Applications show it as failed sessions, queue jobs that never enqueue, or cache writes that error out. The message wording can differ slightly between versions, so search for the MISCONF prefix.

Step 1: read the real reason in the log

The MISCONF message is a symptom. The log has the cause:

sudo tail -n 100 /var/log/redis/redis-server.log
sudo journalctl -u redis -n 100 --no-pager

Look for lines such as:

Check the persistence status directly:

redis-cli INFO persistence | grep -E "rdb_last_bgsave_status|rdb_last_bgsave_time_sec|rdb_changes_since_last_save"
redis-cli CONFIG GET dir
redis-cli CONFIG GET dbfilename

rdb_last_bgsave_status:err confirms it. dir is where the snapshot is written.

Step 2: fix by cause

Disk full

df -h $(redis-cli CONFIG GET dir | tail -1)
df -i $(redis-cli CONFIG GET dir | tail -1)

An RDB snapshot is written to a temp file first, then renamed, so you need free space for a whole extra copy of your dataset, roughly the size of the existing dump.rdb or more. Free space or move dir to a larger volume.

Permissions

The user running Redis needs write access to the directory:

ls -ld /var/lib/redis
sudo chown redis:redis /var/lib/redis
sudo chmod 750 /var/lib/redis

Under systemd, hardening options such as ProtectSystem=strict can make the directory read-only unless it is listed in ReadWritePaths=. In Docker, a read-only filesystem or an unmounted volume gives the same symptom.

Fork fails: not enough memory

BGSAVE uses fork(). The child shares memory with the parent through copy-on-write, but the kernel's overcommit rules may still refuse the fork on a host with little free RAM. Redis's startup log warns about this. The documented fix is to allow overcommit:

sudo sysctl vm.overcommit_memory=1
echo "vm.overcommit_memory = 1" | sudo tee /etc/sysctl.d/99-redis.conf

Also leave headroom. A busy dataset can need extra memory during a save as pages are modified. If the instance uses most of the host's RAM, set maxmemory lower. See OOM command not allowed. In containers, check the memory limit on the cgroup as well, because a fork that pushes the container over the limit gets killed.

Redis cannot write because of a bad config

A wrong dir or dbfilename after an edit also causes this. Check CONFIG GET dir and fix redis.conf.

Step 3: confirm snapshots work, then writes resume

Once the cause is fixed, trigger a save and watch the status:

redis-cli BGSAVE
sleep 5
redis-cli INFO persistence | grep rdb_last_bgsave_status

When it shows ok, writes are accepted again. Redis automatically retries saving according to your save rules, so it may recover on its own after a fix.

Emergency workaround, and its price

If you must accept writes right now:

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

This restores writes immediately, but you lose the safety net: Redis will accept data it cannot persist, and a restart would lose it. Use it only for a data set you can rebuild (a pure cache), and set it back to yes after the real fix. Persist the change in redis.conf only deliberately:

stop-writes-on-bgsave-error yes

Is persistence needed at all?

For a pure cache you may disable RDB snapshots with save "" in redis.conf, so no BGSAVE ever happens. For session stores, queues or anything you cannot lose, keep persistence and consider AOF (appendonly yes). Review the persistence section of the official Redis documentation for the trade-offs, since AOF has its own failure behavior.

Prevent a repeat

• Alert on disk usage of the dir volume and on rdb_last_bgsave_status not equal to ok.
• Monitor a page that writes to Redis, such as a login or cart action, with an अपटाइम मॉनिटर and a keyword check.
• Track backup or snapshot-copy jobs with cron monitoring.
• Check the Redis port is only reachable where it should be, using the पोर्ट चेकर. Port 6379 should rarely be open to the internet.

अगले कदम

• Memory limit hit instead? See OOM command not allowed.
• Auth problems: NOAUTH Authentication required.
• Verify your site end to end with the वेबसाइट हेल्थ चेक.
• Read about Node.js ECONNREFUSED if clients cannot connect at all.

सामान्य प्रश्न

Does MISCONF mean my data is lost?

No. Existing data in memory is intact and reads continue. The danger is that new data is not being saved, so a restart now would lose recent changes.

Why did it start suddenly?

Typically the disk filled, a deployment changed permissions, or memory pressure made fork fail. The log line before the first MISCONF shows which.

Is setting stop-writes-on-bgsave-error to no safe?

Only for disposable cache data, and only temporarily. It removes the warning that persistence is broken.

Does AOF avoid this error?

AOF has its own error handling and can also stop writes if it cannot write to disk. Check the documentation for your version.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.