How to fix ERR fsync error in Redis
Redis logs `ERR fsync error` when its persistence thread cannot flush the AOF/RDB file, typically because the disk reports a write or fsync failure. The process pauses writes with `STOP-WRITES-ON-BGSAVE-ERROR` until you fix the underlying storage or OS settings, so gather the fsync logs, check disk health, and tune persistence settings. This guide covers the symptoms, root causes, and ordered steps needed to restore durable writes.
Quick fix
Fixes ERR
\n# Tail Redis log for fsync errors\nsudo tail -n 50 /var/log/redis/redis-server.log | grep -i fsync\n\n# Confirm the append-only file path and ownership\nls -l /var/lib/redis/appendonly.aof\nstat -c "%n %s %F %a" /var/lib/redis/appendonly.aof\n\n# Verify the directory disk usage\ndf -h /var/lib/redis\n- Capture the fsync failure and inspect the affected files
- Review Redis persistence settings and current health indicators
- Tune the OS/disk parameters that affect fsync
- Move persistence to faster/local storage or adjust appendfsync
\n# Tail Redis log for fsync errors\nsudo tail -n 50 /var/log/redis/redis-server.log | grep -i fsync\n\n# Confirm the append-only file path and ownership\nls -l /var/lib/redis/appendonly.aof\nstat -c "%n %s %F %a" /var/lib/redis/appendonly.aof\n\n# Verify the directory disk usage\ndf -h /var/lib/redis\nERR fsync error
What this error means
When Redis reports "ERR fsync error" it means the storage layer rejected the blocking fsync/aio_fsync call that Redis uses to guarantee persistence for AOF and RDB files. The error almost always originates from the persistence thread or the asynchronous AOF worker: Redis issues fsync during `BGREWRITEAOF`, `BGSAVE`, or while flushing the append-only file, and it treats any kernel-level failure as a fatal durability concern. The message can be paired with "Asynchronous AOF fsync is taking too long (disk is busy?)" when Redis gives up waiting for the OS to complete the flush. Because Redis stops accepting writes in this state, you must diagnose the fsync failure carefully—validating disk health, permissions, and OS tunables—before resuming normal I/O or retrying persistence operations.
Typical symptoms
- Redis logs contain `ERR fsync error` or `Asynchronous AOF fsync is taking too long (disk is busy?)` during background persistence work
- Writes start failing or the primary stops accepting writes when the persistence thread hits the fsync error
- Replication lags out or replicas promote because the master set `stop-writes-on-bgsave-error` to yes
- Manual `BGREWRITEAOF`/`BGSAVE` commands fail with the same fsync error and the appendonly.aof file freezes in size
- Disk or storage monitoring already reports high latency, I/O timeouts, or full volumes around the same timestamp
Common causes
- The block device is full, read-only, or failing so the kernel rejects the fsync; Redis cannot persist new writes without at least one successful fsync
- The storage backend (slow shared disk, NFS/SAN volume, or virtual disk) is too busy or misbehaving, so asynchronous fsync operations either time out or return I/O errors
- Redis is configured with very aggressive fsync settings (`appendfsync always`, `no-appendfsync-on-rewrite no`) while the OS is not tuned for the load, which exposes `vm.overcommit_memory` and dirty write limits before the kernel can safely flush
How to fix "ERR fsync error"
Check the Redis log for exact fsync failures and make sure the persistence files are writable:\n\n
\n# Tail Redis log for fsync errors\nsudo tail -n 50 /var/log/redis/redis-server.log | grep -i fsync\n\n# Confirm the append-only file path and ownership\nls -l /var/lib/redis/appendonly.aof\nstat -c "%n %s %F %a" /var/lib/redis/appendonly.aof\n\n# Verify the directory disk usage\ndf -h /var/lib/redis\n\n\nReplace /var/lib/redis with your dir setting. If the log mentions a different file (like dump.rdb), run the same checks on that file. A read-only mount, quota, or disk failure will surface here.
Use redis-cli to see how persistence is configured and whether Redis is already in a protective state:\n\n
\nredis-cli INFO persistence | grep -E "fsync|bgsave|aof_enabled"\nredis-cli CONFIG GET appendfsync stop-writes-on-bgsave-error no-appendfsync-on-rewrite\nredis-cli CONFIG GET aof-use-rdb-preamble aof-rewrite-incremental-fsync\n\n\nA common pattern is appendfsync always + no-appendfsync-on-rewrite no combined with heavy writes. Consider issuing BGREWRITEAOF only after disk health is restored, and run redis-cli CONFIG SET stop-writes-on-bgsave-error no only temporarily to keep the primary writable while you fix the storage issue.
Configure kernel tunables Redis explicitly recommends and that reduce fsync pressure:\n\n
\nsudo sysctl -w vm.overcommit_memory=1\nsudo sysctl -w vm.dirty_ratio=15\nsudo sysctl -w vm.dirty_background_ratio=5\n\n\nAlso ensure the mount does not disable O_DIRECT or sync. If the disk is an SSD or NVMe, check SMART data (sudo smartctl -a /dev/sdX) and avoid throttling with hdparm. When using vm.overcommit_memory=2, Redis cannot allocate the memory it needs for background saves, so stick with 1 unless your platform forbids it.
If the current storage is shared or slow, relocate the AOF/RDB files to a dedicated local disk or tune persistence:\n\n
\n# Edit redis.conf\nappendonly yes\nappendfsync everysec\nno-appendfsync-on-rewrite yes\ndir /mnt/fast/redis\n\n# Then restart Redis and, if needed, rewrite the AOF\nredis-cli SHUTDOWN NOSAVE\n# Start Redis with the new dir, then\nredis-cli BGREWRITEAOF\n\n\nUse local SSD/ephemeral disk space whenever possible; network filesystems often break fsync semantics. If relocation is not possible, consider disabling AOF temporarily (appendonly no) while you resolve the storage issue, but be aware of the durability impact.
Advanced notes
Redis versions older than 6.2 did not always propagate fsync return codes properly (see GitHub issue #8111), so the server sometimes continued after a failed fsync and later logged ERR fsync error. Upgrade to a recent stable patch to get explicit fsync error handling and monitor redis-cli INFO persistence for aof_fsync_error counters. When using asynchronous AOF, also watch for the "Asynchronous AOF fsync is taking too long (disk is busy?)" warning so you can throttle writes before the kernel starts refusing fsync calls.
Frequently asked questions
- What does "ERR" mean?
- When Redis reports "ERR fsync error" it means the storage layer rejected the blocking fsync/aio_fsync call that Redis uses to guarantee persistence for AOF and RDB files. The error almost always originates from the persistence thread or the asynchronous AOF worker: Redis issues fsync during BGREWRITEAOF, BGSAVE, or while flushing the append-only file, and it treats any kernel-level failure as a fatal durability concern. )" when Redis gives up waiting for the OS to complete the flush.
- How do I fix "ERR"?
- Redis logs ERR fsync error when its persistence thread cannot flush the AOF/RDB file, typically because the disk reports a write or fsync failure. The process pauses writes with STOP-WRITES-ON-BGSAVE-ERROR until you fix the underlying storage or OS settings, so gather the fsync logs, check disk health, and tune persistence settings. This guide covers the symptoms, root causes, and ordered steps needed to restore durable writes.
- What causes "ERR"?
- The block device is full, read-only, or failing so the kernel rejects the fsync; Redis cannot persist new writes without at least one successful fsync The storage backend (slow shared disk, NFS/SAN volume, or virtual disk) is too busy or misbehaving, so asynchronous fsync operations either time out or return I/O errors Redis is configured with very aggressive fsync settings (appendfsync always, no-appendfsync-on-rewrite no) while the OS is not tuned for the load, which exposes vm.overcommit_memory and dirty write limits before the kernel can safely flush
- Is the "ERR" error serious?
- Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.