The nobackfill flag in depth

Advanced⏱ ~16 minceph

What you'll learn

Distinguish nobackfill from norebalance precisely
Identify when the difference matters
Use it appropriately
Recognise its risk

Prerequisites

None — start here.

Verified against Ceph Tentacle 20.2.x · Ceph Squid 19.2.x (supported previous) · cephadm matches the verified Ceph release · podman 4.x · csi-rbd and csi-cephfs current · RBD / CephFS / RGW current (matches Ceph release) · Linux kernel 5.15+ (5.10 minimum) · Ubuntu 24.04 LTS (Ceph host baseline) · Debian 12 (Bookworm) (Ceph host baseline) · Rocky Linux / RHEL / AlmaLinux 9.x (Ceph host baseline) · Proxmox VE 9.x (cross-course integration) · Kubernetes 1.31+ (cross-course integration) · 2026-08-18

Why this matters in production

nobackfill and norebalance look similar and differ in one respect that determines whether the flag is safe.

The difference

norebalance:  suppresses backfill of misplaced objects
nobackfill:   suppresses all backfill, including of degraded objects

ceph osd set nobackfill
ceph -s | grep -E 'degraded|misplaced|backfilling'

	`norebalance`	`nobackfill`
Misplaced object backfill	stopped	stopped
Degraded object backfill	continues	stopped
Log-based recovery	continues	continues
Can leave a PG degraded	no	yes
Safe during business hours	yes	no

When the difference matters

A PG becomes degraded and its log gap is too large for recovery.
  → the repair requires backfill
  → norebalance permits it
  → nobackfill does not
  → the PG stays degraded until the flag is cleared

This case arises whenever an OSD is absent longer than the PG log window, which is most absences of more than a few minutes.

ceph config get osd osd_max_pg_log_entries
ceph pg dump pgs | awk '$10 ~ /backfill/ {print $1, $10}' | head

Using it appropriately

Situation	Appropriate
A cluster-wide emergency requiring all movement to stop	yes, briefly
Diagnosing whether backfill is causing an impact	yes, briefly
Freezing the cluster state for investigation	yes, briefly
Pausing an expansion	no — use `norebalance`
Reducing background load routinely	no — use `norebalance`
Overnight, unattended	no

# a brief diagnostic, scripted
ceph osd set nobackfill
sleep 300
# measure
ceph osd unset nobackfill

The risk

nobackfill left set:
  a failure produces degradation the cluster cannot repair
  the degradation persists until the flag is cleared
  a second failure on those PGs is considerably worse

ceph -s | grep degraded
ceph osd dump | grep flags

The failure mode is identical to norecover's, reached by a different route:
degraded PGs that nothing repairs.

Quiz

Knowledge check · 4 questions

Q1. What distinguishes `nobackfill` from `norebalance`?

nobackfill also stops log-based recovery, so a returning OSD never catches up at all nobackfill also stops backfill of degraded objects, so it can leave a PG degraded indefinitely nobackfill applies per-OSD rather than cluster-wide, so its scope is narrower in practice They are equivalent in effect, and the second name is kept only for compatibility with older scripts
Q2. A PG whose OSD was absent for an hour is repaired by log-based recovery.

True False
Q3. Choose between the backfill flags.

A team wants to pause data movement overnight while an unrelated investigation runs. They are choosing between nobackfill and norebalance.
Q4. What determines whether a returning OSD's repair uses recovery or backfill?

Passing score: 75%. Answers are checked in this browser.

Production discipline

Use norebalance rather than nobackfill for any unattended or routine pause — the difference is that nobackfill also suppresses the backfill repairing degraded PGs. Reserve nobackfill for brief, scripted, attended diagnostics.

Cross-course references

Kubernetes: broad suppressions that also disable healing need attended use
Linux: distinguishing optimisation from repair determines what is safe to defer