Redis "MISCONF Redis is configured to save RDB snapshots": why writes stopped
Fix Redis MISCONF "unable to persist to disk": read the log, then fix disk space, folder permissions or fork memory — and check the instance was not attacked.
by OhSudo ··
Not sure this is your cause?Find it step by step: Can't connect to the database →Find it step by step: Disk full or out of memory →
Every write to Redis fails with this:
(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.Redis keeps data in memory and saves a copy to disk from time to time (an RDB snapshot, dump.rdb). The last save failed. Rather than keep accepting data it may not be able to save, Redis stops all writes until a save works again. Reads still work.
So the question is: why did the save fail? The message tells you where to look — the Redis log.
- RDB snapshotbackground save to dump.rdbfails(fails)
- Save failsdisk full, folder, fork(breaks here)so
- Writes refusedstop-writes-on-bgsave-error
TL;DR
redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|rdb_changes_since_last_save'sudo tail -n 30 /var/log/redis/redis-server.log # Debian/Ubuntu (RHEL: /var/log/redis/redis.log)redis-cli CONFIG GET dir # where Redis tries to save# fix the cause, then:redis-cli BGSAVEWrites resume by themselves as soon as a save succeeds.
1. Read the log
sudo tail -n 30 /var/log/redis/redis-server.log # Debian / Ubuntusudo tail -n 30 /var/log/redis/redis.log # RHEL familydocker logs --tail 30 redis # in DockerThe line just before Background saving error names the cause. The three usual ones:
| Log message | Cause | Section |
|---|---|---|
Write error saving DB on disk: No space left on device |
The disk is full | 2 |
Failed opening the temp RDB file temp-1234.rdb (in server root dir /var/lib/redis) for saving: Permission denied |
Redis can’t write to its folder | 3 |
Can't save in background: fork: Cannot allocate memory |
Not enough memory to start the save | 4 |
Also check where Redis saves, and whether that looks right:
redis-cli CONFIG GET dirredis-cli CONFIG GET dbfilenameIf dir is something strange — /root/.ssh, /etc/cron.d, /var/spool/cron, a web folder — stop and go to section 5.
2. The disk is full
Free space on the filesystem behind dir. See No space left on device to find what fills it. A large appendonly.aof or old temp-*.rdb files in the Redis folder itself are common suspects.
3. The folder isn’t writable
Redis runs as the redis user and writes a temporary file next to dump.rdb, then renames it. The folder must belong to that user:
ls -ld /var/lib/redissudo chown redis:redis /var/lib/redisIn Docker, the same applies to the volume: if you mounted a host folder over /data, it must be writable by the user inside the container (999 in the official image). On RHEL-family systems, a custom dir also needs the right SELinux label — the default /var/lib/redis already has it.
4. fork: Cannot allocate memory
To save in the background, Redis forks itself. The copy shares memory with the original, so it needs almost nothing extra — but with Linux’s default memory accounting, the kernel may refuse a fork of a large process anyway. Redis warns about this at startup:
WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. …Do what Redis recommends:
sudo sysctl vm.overcommit_memory=1echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/90-redis.conf # keep it after rebootAlso check maxmemory: if Redis uses almost all of the machine’s RAM, give it a limit with headroom (redis-cli CONFIG GET maxmemory).
5. Check that the instance wasn’t attacked
A Redis server reachable from the internet without a password is a classic target. Attackers connect, change dir and dbfilename to /root/.ssh and authorized_keys (or a cron folder), and use a save to plant their file. The save often fails on permissions — and MISCONF is how you find out.
If dir points somewhere it shouldn’t:
- Treat the server as compromised: check
/root/.ssh/authorized_keys,/etc/cron.d/and/var/spool/cron/for files you didn’t create. - Make Redis listen only where it must (
bind 127.0.0.1 ::1inredis.conf), keepprotected-mode yes, set a password (requirepass, or ACL users), and close port 6379 in the firewall.
6. After the fix
redis-cli BGSAVEredis-cli INFO persistence | grep rdb_last_bgsave_status # should say okWrites work again right after the successful save — no restart needed.
Warning
The “quick fix” you’ll see online: CONFIG SET stop-writes-on-bgsave-error no. It makes Redis accept writes while saves keep failing — so after a restart, everything since the last good save is gone. It’s acceptable only when Redis is purely a cache. In that case, turn persistence off on purpose instead: CONFIG SET save "" (and the same in redis.conf).
Shell, we have a problem!
Similar, but different: OOM command not allowed when used memory > 'maxmemory' — Redis is full and its eviction policy is noeviction; raise maxmemory or set a policy like allkeys-lru for a cache, and see that article. NOAUTH Authentication required — the client didn’t send the password. If Redis asks you to log in first, see NOAUTH.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.