Fix: MISCONF Redis is configured to save RDB snapshots but is currently not able to persist on disk

MISCONF means the last background RDB save failed, and Redis has stopped accepting write commands in response. This is not corruption and Redis is not down: reads still work, and the block on writes is a deliberate safety default (stop-writes-on-bgsave-error yes) so a broken persistence layer cannot fail silently until a crash makes it permanent. Your job is to find out why BGSAVE fails, fix that, and let a successful save re-enable writes.

MISCONF Redis is configured to save RDB snapshots but is currently not able to persist on disk

What this error means

When RDB persistence is enabled, Redis periodically forks a child process that writes the whole dataset to a temporary file and renames it over the RDB file. That can fail in three broad ways: the fork itself fails (memory accounting), the write fails (disk full, permissions, I/O errors), or the child is killed. Redis records the failure in rdb_last_bgsave_status, and while that status is err, every write command is answered with MISCONF. The instant a background save completes successfully, writes resume on their own. So the error you see in the application is really a pointer to a different failure on the Redis host.

Common causes

• Disk full on the volume holding the RDB file, or the temporary dump file pushing it over the edge (the save needs room for a second copy).
• Fork failure: vm.overcommit_memory=0 on a host where Redis uses more than half the RAM, so the kernel refuses to fork the child.
• Wrong permissions or ownership on the data directory, often after a migration, restore, or configuration change.
• The RDB child killed by the OOM killer under memory pressure during the copy-on-write window.
• Disk I/O errors on failing storage, visible in the kernel log.

How to fix it

STABILIZE first. If writes being down is the bigger emergency, temporarily decouple writes from the save failure while you repair it. This is a bridge, not a fix.

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

1. DIAGNOSE why the save fails. Check the save status and read the Redis log, which states the reason plainly (fork failure, permission denied, or no space).

redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|rdb_bgsave_in_progress'
tail -50 /var/log/redis/redis-server.log

2. Check the obvious suspects on the host: disk space on the data directory and directory permissions for the redis user.

redis-cli CONFIG GET dir
df -h /var/lib/redis
ls -ld /var/lib/redis

3. FIX what you found. Disk full: free space or grow the volume, remembering the snapshot needs roughly the RDB file’s size again in free space. Permissions: restore ownership to the user Redis runs as.

chown -R redis:redis /var/lib/redis

4. Fork failures with “Cannot allocate memory” in the log are the overcommit case. Enable memory overcommit, which is the documented setting for Redis hosts:

sysctl -w vm.overcommit_memory=1
echo 'vm.overcommit_memory = 1' >> /etc/sysctl.d/99-redis.conf

5. Trigger a save manually and confirm it succeeds; writes re-enable automatically once it does. Then restore the safety default if you loosened it in the stabilize step.

redis-cli BGSAVE
redis-cli INFO persistence | grep rdb_last_bgsave_status
redis-cli CONFIG SET stop-writes-on-bgsave-error yes

If the log shows I/O errors rather than space or permissions, treat the disk as the incident: check dmesg and SMART health before trusting the volume with your dataset.

How to prevent it

• Monitor rdb_last_bgsave_status and rdb_changes_since_last_save directly, so a failing save pages you before MISCONF blocks the app.
• Alert on the data volume at 70 to 80 percent full, with headroom sized for a full extra RDB copy.
• Set vm.overcommit_memory=1 on every dedicated Redis host as part of provisioning, not as incident response.
• Size hosts so Redis peaks below roughly half of RAM if you rely on RDB forks, or use smaller instances with sharding.
• Test restores from RDB files periodically; a snapshot pipeline nobody has restored from is a hope, not a backup.

When to call a senior engineer

Call for help when saves fail intermittently with no obvious disk or memory cause, when the dataset has outgrown the host and every BGSAVE flirts with the OOM killer, or when you had persistence silently broken for a while and need to establish what is actually recoverable. Erzon engineers can right-size the persistence strategy (RDB, AOF, or both), fix the host-level settings that make forks reliable, and leave you with monitoring that catches the next save failure before your application does.