Redis "MISCONF Redis is configured to persist RDB snapshots"

Redis refuses writes when it can't persist — usually the disk filled or permissions broke. It's a feature protecting your data. Free the disk, fix the fsync path, then re-enable writes.

What you'll see

Root causes

Disk full where RDB/AOF files live (dir setting)

CONFIG GET dir shows the target; df -h that filesystem. Snapshots can't write, so Redis (correctly) stops accepting writes in that persistence mode.

Overcommit disabled → fork/BGSAVE failures

The classic companion error: 'Background saving error' from vm.overcommit_memory=0. sysctl vm.overcommit_memory=1 fixes fork() during saves.

Wrong ownership of the data dir

Containers running as a non-root user against a root-owned volume: chown the dir (chown -R redis:redis /data) so snapshots can land.

Fix it

  1. Confirm the failing path and reason
    redis-cli CONFIG GET dir; redis-cli INFO persistence | grep -E 'rdb_last_bgsave_status|aof_last_write_status'; df -h $(redis-cli CONFIG GET dir | tail -1)
  2. Free disk space (logrotate/journal vacuum on the same fs help)
    df -h / && sudo journalctl --vacuum-size=200M   # or clear the app's logs sharing the filesystem
  3. Fix overcommit so BGSAVE can fork
    sudo sysctl vm.overcommit_memory=1 && echo 'vm.overcommit_memory=1' | sudo tee /etc/sysctl.d/99-redis.conf
  4. Trigger a save and confirm status clears
    redis-cli BGSAVE && sleep 2 && redis-cli INFO persistence | grep rdb_last_bgsave_status   # expect ok

Field note

CONFIG SET stop-writes-on-bgsave-error no silences the protection — only acceptable when the data is truly disposable (cache-only Redis). Alert on disk usage on Redis hosts: this error is the canary; better to catch 85% full than lose writes.

Common questions

Why does Redis refuse writes when persistence breaks?

With save-on-disk configured, Redis assumes the dataset matters — refusing writes is safer than silently accepting data it can't persist. Free the disk and writes resume automatically.

Is it safe to turn off stop-writes-on-bgsave-error?

For a pure cache, yes — data is re-derivable. For anything durable, no: you'd trade a visible error for silent data loss on the next restart.

Related fixes

Ship it right the first time

Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.

Browse the template store →

One-time. Yours to modify. Instant download from the NinjaOps template store.