Redis returns "ERR BGREWRITEAOF scheduled when RDB save in progress" when you try to start an AOF rewrite while a background RDB snapshot is already running. This prevents simultaneous persistence operations that could conflict or overload memory/disk. Wait for the current RDB save to finish, check persistence settings, or manually schedule AOF rewrites during low‑traffic periods.
Redis returns "ERR BGREWRITEAOF scheduled when RDB save in progress" when you issue a `BGREWRITEAOF` command while a background RDB snapshot (`BGSAVE`) is already running. Redis deliberately blocks concurrent persistence operations to avoid resource contention and ensure data consistency. The error occurs because Redis uses a single background thread for both `BGSAVE` (RDB persistence) and `BGREWRITEAOF` (AOF compaction). Starting a second heavy I/O operation while the first is still in progress would risk memory exhaustion, disk I/O contention, or inconsistent state. Redis enforces this serialization by checking the `rdb_bgsave_in_progress` flag before allowing `BGREWRITEAOF` to proceed. This is a protective mechanism, not a bug—it ensures that only one background persistence job runs at a time. You must either wait for the current RDB save to finish, adjust your persistence configuration to avoid overlapping schedules, or manually trigger AOF rewrites during known idle windows.
Use redis-cli to see whether an RDB save is currently running and monitor its progress:
# Check if a background save is in progress
redis-cli INFO persistence | grep -E "rdb_bgsave_in_progress|aof_rewrite_in_progress|rdb_last_bgsave_status"
# Monitor the RDB save progress (if in progress)
redis-cli INFO persistence | grep rdb_current_bgsave_time_sec
# Wait for completion, then verify the save finished successfully
redis-cli INFO persistence | grep rdb_last_bgsave_statusIf rdb_bgsave_in_progress is 1, wait until it becomes 0. The rdb_current_bgsave_time_sec field shows how long the current save has been running. Once the save finishes, rdb_last_bgsave_status should be ok.
Examine your redis.conf to understand when RDB saves are triggered and consider adjusting the schedules:
# View current save directives
redis-cli CONFIG GET save
# View AOF rewrite settings
redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli CONFIG GET auto-aof-rewrite-min-size
# Example: Less frequent RDB saves (only when 1000 keys change in 300 seconds)
redis-cli CONFIG SET save "300 1000"
# Or disable automatic RDB saves entirely if you rely on AOF
redis-cli CONFIG SET save ""If you use both RDB and AOF, ensure their automatic triggers don’t overlap. You can increase the RDB save thresholds or disable automatic RDB saves (save "") if AOF is your primary persistence method.
Before issuing BGREWRITEAOF programmatically, check that no RDB save is running:
#!/bin/bash
# Function to safely trigger BGREWRITEAOF
safe_bgrewriteaof() {
local status=$(redis-cli INFO persistence | grep "rdb_bgsave_in_progress" | cut -d: -f2)
if [[ "$status" == "0" ]]; then
echo "No RDB save in progress, starting BGREWRITEAOF..."
redis-cli BGREWRITEAOF
else
echo "RDB save in progress, skipping BGREWRITEAOF"
exit 1
fi
}
# Call the function
safe_bgrewriteaofFor cron jobs or automated scripts, wrap BGREWRITEAOF with this check. Alternatively, use Redis’s LASTSAVE command to see when the last RDB save completed and only run BGREWRITEAOF if enough time has passed.
If overlapping persistence operations are a recurring issue, evaluate whether you need both RDB and AOF:
# Option 1: Use AOF-only persistence (more durable, but larger files)
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG SET save ""
# Option 2: Use RDB-only persistence (faster restarts, point-in-time snapshots)
redis-cli CONFIG SET appendonly no
redis-cli CONFIG SET save "900 1 300 10 60 10000"
# Option 3: Increase system resources so persistence completes faster
# Check memory and disk I/O during saves
redis-cli INFO memory | grep used_memory_peak
iostat -x 1 # Monitor disk utilizationIf you keep both, ensure the server has enough memory (forked process memory) and fast disk I/O so that background saves finish quickly, reducing the window where BGREWRITEAOF would be blocked.
Redis versions before 7.0 had a stricter serialization between BGSAVE and BGREWRITEAOF—they could not run concurrently at all. Redis 7.0 introduced some improvements to background I/O handling, but the fundamental restriction remains because both operations perform heavy disk writes and memory-intensive operations (copy‑on‑write).
If you see this error frequently, monitor the rdb_bgsave_in_progress and aof_rewrite_in_progress metrics in your observability stack. Consider using Redis’s BGREWRITEAOF SCHEDULE command (available in Redis 6.2+) which queues the rewrite to run as soon as the current RDB save finishes, avoiding the need for manual retries.
For high‑availability setups with replication, note that replicas also perform RDB saves when they sync with a master. If you issue BGREWRITEAOF on a replica while it’s saving an RDB snapshot for initial sync, you’ll get the same error.
+elected-leader: Won election for epoch
Understanding "+elected-leader: Won election for epoch" in Redis Sentinel
ERR Unbalanced XREAD list of streams
How to fix "ERR Unbalanced XREAD list" in Redis
ERR syntax error
How to fix "ERR syntax error" in Redis
ERR fsync error
How to fix "ERR fsync error" in Redis
ConnectionError: Error while reading from socket
ConnectionError: Error while reading from socket in redis-py