Purging an OSD from the cluster

Why this matters in production

Purge removes the OSD from the cluster’s records entirely. Doing it in one command rather than as separate steps is what prevents the residue that shows up months later as a phantom entry nobody can explain.

The command

ceph osd purge 13 --yes-i-really-mean-it

The confirmation flag is required because the operation is irreversible.

What it removes

The CRUSH weight removal is what causes additional data movement beyond marking out: the host bucket’s weight changes, altering placement for PGs that never involved this OSD.

The manual equivalent

ceph osd crush remove osd.13
ceph auth del osd.13
ceph osd rm 13

Three commands where purge is one. Doing them individually risks completing some and not others, and the residue is what appears as a phantom.

Verifying

ceph osd tree | grep -w 13
ceph auth ls | grep 'osd\.13'
ceph osd dump | grep '^osd.13'
ceph orch ps --daemon-type osd | grep osd.13
ceph -s

All should return nothing. And the device should become available:

HOST=stor-04
ceph orch device ls --refresh | grep ${HOST}

If the device still shows as unavailable, it needs zapping:

# host from the `ceph orch device ls` output above:
HOST=stor-04

ceph orch device zap "$HOST" /dev/sdX --force

Recovering from a partial removal

# a CRUSH entry with no daemon and no auth key
ceph osd tree | grep -E 'osd\.[0-9]+' | grep -v up | grep -v down

# clean it up
ceph osd crush remove osd.13
ceph osd rm 13
ceph auth del osd.13

A phantom entry consumes an OSD id and appears in the tree, which is cosmetic until someone tries to reuse the id.

Reusing the id

# Substitute your own value before running:
HOST=stor-04

ceph orch daemon add osd "$HOST:/dev/sdX"

The orchestrator assigns the lowest free id, so a purged id is reused automatically. Where a specific id must be reused — for consistency with documentation or automation — the --osd-id option exists but is rarely worth the constraint.

Quiz

Production discipline

Use purge rather than the manual sequence so nothing is left behind, and batch purges of OSDs from the same host to pay the weight-change rebalance once. Verify the OSD tree, the auth list, and the device availability after every removal — the residue is quiet and accumulates.

Cross-course references

• Kubernetes: removing a node leaves residue in several places if not done through the proper path
• Linux: incomplete decommissioning leaving orphaned credentials is a recurring audit finding