Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Redis By James Joyner IV · · 8 min read Last reviewed Jul 2026

Redis Error Guide: 'Background append only file rewriting already in progress' — Fix Overlapping BGREWRITEAOF

Quick answer

Fix Background append only file rewriting already in progress in Redis: diagnose concurrent BGREWRITEAOF, auto-rewrite races, and slow AOF forks.

  • #redis
  • #troubleshooting
  • #errors
  • #persistence
Free toolkit

Stuck on this Redis error? Get the free incident triage checklist

A one-page PDF — the exact steps to isolate, fix, and verify a production error like this one. No spam, unsubscribe anytime.

Overview

Redis returns Background append only file rewriting already in progress when you issue BGREWRITEAOF while an AOF rewrite child process is already running. AOF rewrite compacts the append-only file by forking a child that writes a fresh, minimal AOF; Redis allows only one such rewrite at a time.

The literal error clients receive:

(error) ERR Background append only file rewriting already in progress

Like the RDB save guard, this is protective — a second concurrent rewrite is not allowed. It appears when a manual BGREWRITEAOF collides with the automatic rewrite Redis triggers via auto-aof-rewrite-percentage, or when a rewrite is slow because the AOF is large or the disk is busy.

Symptoms

  • BGREWRITEAOF returns the error; INFO persistence shows a rewrite in flight.
  • Coincides with automatic rewrites or a large AOF and slow disk.
  • May queue: Redis can schedule a rewrite to start after the current one finishes.
redis-cli BGREWRITEAOF
(error) ERR Background append only file rewriting already in progress

Common Root Causes

1. A rewrite is genuinely still running

The previous manual or automatic rewrite has not completed.

redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_rewrite_scheduled'
aof_rewrite_in_progress:1
aof_rewrite_scheduled:0

2. Manual call races the automatic trigger

auto-aof-rewrite-percentage fired a rewrite at the same moment your script called BGREWRITEAOF.

redis-cli CONFIG GET auto-aof-rewrite-percentage
redis-cli CONFIG GET auto-aof-rewrite-min-size

3. The rewrite is slow

A large dataset, slow disk, or I/O contention makes each rewrite take long enough to collide with the next request.

redis-cli INFO persistence | grep -E 'aof_last_rewrite_time_sec|aof_current_size'

4. RDB save is also forking

An in-progress BGSAVE holds the single child slot; Redis serializes child processes.

redis-cli INFO persistence | grep rdb_bgsave_in_progress

How to diagnose

Step 1: Confirm a rewrite is in progress

redis-cli INFO persistence | grep -E 'aof_rewrite_in_progress|aof_last_bgrewrite_status'

aof_rewrite_in_progress:1 means the guard is correct — wait.

Step 2: Check how long rewrites take

redis-cli INFO persistence | grep -E 'aof_last_rewrite_time_sec|aof_current_size|aof_base_size'

A large aof_current_size versus aof_base_size explains frequent auto-rewrites.

Step 3: Look for overlapping triggers in the log

sudo journalctl -u redis-server --no-pager | grep -iE 'AOF rewrite|Background AOF|rewriting' | tail

Step 4: Check whether an RDB save is competing

redis-cli INFO persistence | grep -E 'rdb_bgsave_in_progress|aof_rewrite_scheduled'

aof_rewrite_scheduled:1 means Redis will start the rewrite automatically once the current child finishes.

Fixes

Wait for the current rewrite, then retry

while [ "$(redis-cli INFO persistence | tr -d '\r' | awk -F: '/aof_rewrite_in_progress/{print $2}')" = "1" ]; do
  sleep 1
done
redis-cli BGREWRITEAOF

Rely on automatic rewrites instead of manual ones

Tune the thresholds and let Redis manage timing, avoiding manual races:

redis-cli CONFIG SET auto-aof-rewrite-percentage 100
redis-cli CONFIG SET auto-aof-rewrite-min-size 64mb
redis-cli CONFIG REWRITE

Speed up rewrites

Move the AOF directory to faster disk, ensure RAM headroom for the fork’s copy-on-write, and keep appendfsync everysec (not always) unless durability demands otherwise.

Stagger AOF and RDB schedules

Avoid forcing BGSAVE and BGREWRITEAOF at the same moment; they compete for the single child slot.

What to watch out for

  • aof_rewrite_scheduled:1 means your request was accepted and queued, not lost — Redis will run it next. That is often the desired outcome.
  • aof_last_bgrewrite_status:err signals a failed rewrite (disk full, permissions) — a different problem than “already in progress”.
  • The rewrite fork can transiently increase memory via copy-on-write; size the host so a rewrite under write load cannot exhaust RAM.
  • With appendfsync always, rewrites and fsyncs contend harder for disk; watch latency during rewrites.

Paste the failing command into the free incident assistant, and browse more Redis guides.

Free download · 368-page PDF

Fixed it? Get 500 Redis & DevOps AI prompts — free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.

Did this fix your issue?

Free download · 368-page PDF

Get 500 Battle-Tested DevOps AI Prompts — Free

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.