Ceph Recovery: 3 typische Fehler und wie man sie vermeidet

Ceph ist eines der robustesten Storage-Systeme, die wir in Kundenumgebungen betreiben. Genau darin liegt aber auch die Falle: Weil der Cluster fast alle Fehler intern abfängt, wirken die verbleibenden Ausfallszenarien besonders bedrohlich, sobald sie doch eintreten. In den meisten Recovery-Situationen, die wir aus Kundenumgebungen kennen, wurde die Situation nicht durch den ursprünglichen Defekt eskaliert, sondern durch die Reaktion darauf.

Dieser Artikel beschreibt die drei Fehler, die uns in Notfällen am häufigsten begegnen, und zeigt, wie ein strukturierter Ablauf aussieht. Er richtet sich an Administratoren, die einen produktiven Ceph-Cluster betreiben, idealerweise in Kombination mit Proxmox VE oder als eigenständiges Storage-Backend.

Warum Recovery-Fehler so oft auf dieselben drei Muster zurückgehen

Ceph ist ein selbstheilendes System. Wenn ein OSD ausfällt, verteilt der Cluster die betroffenen Placement Groups (PGs) automatisch neu und stellt die konfigurierte Replikationsstufe wieder her. Das Problem: Dieser Prozess ist ressourcenintensiv und dauert je nach Datenvolumen, Netzwerk und Anzahl der OSDs Stunden bis Tage. In dieser Phase ist der Cluster in einem degraded-Zustand, aber weiterhin funktionsfähig.

Genau in diesem Fenster passieren die klassischen Fehler:

1. Ein Administrator startet OSDs neu, weil “irgendetwas nicht passt”.
2. Ein PG hängt in active+recovery_wait+degraded und wird per Hand auf active+clean gesetzt oder mit ceph pg force-recovery erzwungen, ohne die Ursache zu klären.
3. Ein defektes OSD wird mit ceph osd rm entfernt, bevor die Daten sauber umverteilt wurden.

Jeder dieser drei Eingriffe kann aus einem tolerierbaren Vorfall einen Datenverlust machen. Die gute Nachricht: Alle drei sind vermeidbar, wenn man den offiziellen Recovery-Ablauf kennt und dem Cluster die Zeit gibt, seine Arbeit zu erledigen.

Fehler 1: OSDs während des Backfill neu starten

Der wohl häufigste Reflex bei einer laufenden Recovery ist, dass ein Administrator einzelne OSDs “vorsorglich” neu startet, weil sie hohe I/O-Werte zeigen, langsam reagieren oder in ceph -s als besonders aktiv erscheinen. Genau das ist in der Backfill-Phase kontraproduktiv.

Wenn Ceph nach einem OSD-Ausfall Daten umverteilt, sind exakt die OSDs stark belastet, die Kopien der betroffenen PGs halten oder aufnehmen sollen. Ein Neustart dieser OSDs bewirkt drei Dinge gleichzeitig:

• Die laufende Backfill-Operation für alle PGs auf diesem OSD wird abgebrochen und muss teilweise von vorn begonnen werden.
• Der Cluster markiert die OSD kurzfristig als down, was zu neuen Peering-Vorgängen auf allen betroffenen PGs führt.
• Weitere OSDs übernehmen zusätzlich Last, was einen Dominoeffekt auslösen kann.

Was stattdessen sinnvoll ist: Vor dem Eingriff prüfen, wie weit der Recovery-Prozess ist und ob wirklich ein Problem vorliegt.

# Gesamtstatus des Clusters
ceph -s

# Fortschritt der Recovery-Operationen
ceph progress

# Aktive Backfill/Recovery pro PG
ceph pg dump pgs_brief | grep -E "backfill|recover"

# I/O-Last pro OSD
ceph osd perf

Sind hohe Latenzen sichtbar, ist der richtige Hebel meist nicht der Neustart, sondern die Drosselung der Recovery-Bandbreite:

ceph config set osd osd_max_backfills 1
ceph config set osd osd_recovery_max_active 1
ceph config set osd osd_recovery_op_priority 1

Diese Werte reduzieren die parallele Last, verlängern zwar die Recovery, halten aber die Client-I/O stabil.

Fehler 2: PG-States manuell setzen ohne ceph-mgr

Der zweite typische Fehler betrifft hängende PGs. Wenn eine PG längere Zeit in Zuständen wie active+recovery_wait+degraded, incomplete oder stale verharrt, greifen manche Administratoren zu Kommandos wie ceph pg force-recovery, ceph pg force-backfill oder in Extremfällen zu ceph pg mark_unfound_lost. Diese Kommandos sind mächtig und werden im Notfall auch benötigt, richten aber ohne saubere Analyse mehr Schaden an als Nutzen.

Das Kernproblem: Der Ceph-Manager (ceph-mgr) koordiniert Recovery-Prioritäten, Progress-Reporting und die Interaktion zwischen Mons und OSDs. Wer PG-States manuell überschreibt oder Force-Kommandos absetzt, während mgr nicht sauber läuft, umgeht diese Koordination und produziert widersprüchliche interne Zustände.

Der korrekte Ablauf sieht so aus:

Schritt	Kommando	Zweck
1	ceph mgr stat	Ist ein aktiver Manager vorhanden?
2	ceph health detail	Welche PGs sind betroffen, in welchem Zustand?
3	ceph pg <pgid> query	Detailanalyse einer einzelnen PG
4	ceph osd tree	Welche OSDs sind up/in, welche nicht?
5	Ursache beheben	Netzwerk, Disk, Auth, Clock-Skew
6	Erst dann Force-Kommandos	Nur nach Bestätigung durch Support/Doku

Das ceph pg <pgid> query liefert unter anderem den recovery_state, an dem sichtbar wird, ob eine PG auf ein bestimmtes OSD wartet, ob Objekte als unfound markiert sind oder ob die PG wegen eines Peering-Fehlers nicht weiterkommt. Ohne diese Information ist jede Aktion Blindflug.

Ein häufiges Missverständnis: unfound bedeutet nicht “verloren”. Es bedeutet, dass Ceph das betroffene Objekt aktuell auf keinem erreichbaren OSD findet. In vielen Fällen taucht das Objekt wieder auf, sobald ein zwischenzeitlich ausgefallenes OSD zurückkommt. mark_unfound_lost sollte immer der letzte Schritt sein, weil er endgültig Daten aus der PG entfernt.

Fehler 3: OSDs ohne Drain entfernen

Das dritte Muster: Ein OSD ist auffällig, zeigt SMART-Fehler oder wird als Wackelkandidat identifiziert, und der Administrator entfernt es mit einer schnellen Sequenz aus ceph osd out und ceph osd rm, ohne den Cluster vorher sauber leerlaufen zu lassen. Wenn zeitgleich noch ein zweites OSD ausfällt oder eine bereits laufende Recovery nicht abgeschlossen ist, kann das die Redundanz unter die konfigurierte Mindestanzahl (min_size) drücken.

Der korrekte Ablauf für die geplante Entfernung eines OSD:

# 1. OSD aus dem CRUSH-Datenfluss nehmen, aber im Cluster belassen
ceph osd out <osd-id>

# 2. Warten, bis alle PGs sauber umverteilt sind
watch -n 5 'ceph -s'
# Ziel: HEALTH_OK, keine PGs mehr in backfill/recovery

# 3. OSD-Dienst stoppen (Node-abhaengig)
systemctl stop ceph-osd@<osd-id>

# 4. OSD als down markieren (Sicherheitsschritt)
ceph osd down <osd-id>

# 5. Aus CRUSH-Map und Auth entfernen
ceph osd crush remove osd.<osd-id>
ceph auth del osd.<osd-id>
ceph osd rm <osd-id>

Der entscheidende Schritt ist Punkt 2: Warten. Das Umverteilen kann bei großen Disks und ausgelasteten Netzwerken viele Stunden dauern. Wer diesen Schritt überspringt, entfernt aktiv Redundanz aus dem System und riskiert bei einem zweiten Ausfall unmittelbaren Datenverlust.

Bei einem tatsächlich schon ausgefallenen OSD (down/out, nicht mehr erreichbar) entfällt der Drain, weil Ceph die Daten bereits selbst umverteilt. Aber auch hier gilt: erst warten, bis der Cluster wieder HEALTH_OK meldet, dann die verbleibenden Verwaltungsschritte durchführen.

Recovery-Monitoring: Die Kommandos, die wirklich helfen

In einer laufenden Recovery-Situation ist Überblick wichtiger als Aktionismus. Diese Kommandos liefern belastbare Aussagen darüber, ob der Cluster Fortschritt macht:

# Live-Statusuebersicht mit progress bar
ceph -s
ceph progress

# Fortschritt pro PG
ceph pg dump pgs_brief

# Recovery-Rate in Objekten und MB/s
ceph -s | grep -E "recovery|backfill"

# Wo hakt es?
ceph health detail

# Historie der Zustandsaenderungen
ceph osd tree
ceph osd df tree

Ein guter Indikator für “es läuft” ist eine kontinuierlich sinkende Zahl von degraded objects und misplaced objects in der Ausgabe von ceph -s. Stagniert dieser Wert über 15 bis 30 Minuten hinweg vollständig, lohnt sich die Detailanalyse per ceph health detail und ceph pg <pgid> query.

Für langfristige Beobachtung empfehlen wir das Ceph-eigene Dashboard sowie eine Anbindung an ein bestehendes Monitoring (Prometheus/Grafana über das Ceph-Exporter-Modul). In einer akuten Recovery ist die CLI aber schneller und zuverlässiger als jede GUI.

Wann externe Unterstützung sinnvoll ist

Es gibt Situationen, in denen der Griff zum Telefon der richtige nächste Schritt ist. Aus unserer Erfahrung sind das typischerweise:

• PGs im Zustand incomplete oder down (mögliches Peering-Problem, potenziell datenrelevant)
• unfound-Objekte, die nach längerer Wartezeit nicht zurückkehren
• Cluster in HEALTH_ERR mit unklarer Ursache
• Recovery, die über Tage keinen Fortschritt macht
• Verdacht auf Datenverlust bei kombiniertem Ausfall mehrerer OSDs
• Ceph im Rahmen einer Proxmox-Umgebung mit produktiven VMs, deren Ausfallzeit teurer wird als der Support

Für diese Fälle bieten wir Ceph-Recovery-Support im Rahmen unserer Proxmox- und Virtualisierungsberatung sowie im Rahmen unserer Linux-Systemadministration an.

Fazit

Ceph vergibt viele Fehler, aber nicht alle. Die drei häufigsten Recovery-Fallen lassen sich vermeiden, wenn man dem Cluster die Zeit lässt, seine Arbeit zu tun: keine OSDs mitten im Backfill neu starten, keine PG-States ohne Analyse überschreiben, keine OSDs ohne sauberen Drain entfernen. In den meisten Fällen ist die richtige Aktion Warten, Beobachten und Drosseln, nicht Eingreifen.

DATAZONE unterstützt Sie beim Design, Betrieb und der Notfall-Recovery Ihres Ceph-Clusters, sei es unter Proxmox VE, als eigenständiges Storage-Backend oder in Kombination mit TrueNAS. Wenn Sie eine akute Recovery-Situation haben oder Ihren Cluster präventiv absichern möchten, nehmen Sie Kontakt mit uns auf.