clusterlogs/content/memorias/2026-08-19-mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01.md

+++ title = "Reparar PG dañado (HEALTH_ERR) en el clúster Ceph de mcps-hpc-01" description = "Diagnóstico y reparación de un PG_DAMAGED real (pg 3.ec) en el clúster cephadm de producción; 407 pgs sin deep-scrub a tiempo se documentan como trade-off, no como bug, y no se tocaron." date = 2026-08-19T18:56:05Z authors = ["gen"] slug = "mem-20260819-6ea868-reparar-pg-danado-health-err-en-el-cluster-ceph-de-mcps-hpc-01" template = "memory.html"

[taxonomies] categories = ["memorias"] tags = ["almacenamiento", "ceph", "salud-cluster"] systems = ["ceph", "mcps-hpc-01"]

[extra] id = "MEM-20260819-6EA868" kind = "memory" author_id = "gen" author_fingerprint = "SHA256:JhN1Tt4jYqWoJIznDJ6QkMAiOR6HFHr3xLz9aBJqmPg" risk = "high" ticket = "" review_required = true review_policy = "all-active" reviewer_snapshot = true reviewers = ["gen"] started_at = "" finished_at = "" duration_minutes = 0 agent = "claude-code" +++

Contexto

El clúster Ceph de mcps-hpc-01 (cephadm, fsid 9dd39ee8-b987-11f0-9c83-3497f632acb0: 5 mons, mgr activo+standby, 2 MDS, 20 OSDs, 4 pools, 1089 pgs, ~45 TiB usados de 232 TiB) respalda cephfs_hpc, del que dependen Caddy #2, Zammad y en general /mnt/cephfs. Al revisar ceph -s salió HEALTH_ERR por dos causas distintas: 1 scrub error/PG_DAMAGED en pg 3.ec, y 407 pgs sin deep-scrub a tiempo (warning, no error). El repair de 3.ec (ceph pg repair 3.ec) quedó corriendo en segundo plano al cierre de la sesión — es un deep-scrub completo del PG (~42 GiB), tarda varios minutos; falta reconfirmar con ceph -s / ceph health detail que OSD_SCRUB_ERRORS y PG_DAMAGED ya no aparecen.

Cambios realizados

• Diagnosticado pg 3.ec con rados list-inconsistent-obj: el shard primario (osd.10) está limpio (digest correcto) y el shard de la réplica (osd.13) tiene read_error puro, sin ambigüedad entre copias
• Confirmado con smartctl que el disco de osd.13 no tenía degradación física antes de reparar (PASSED, Reallocated_Sector_Ct=0, Current_Pending_Sector=0, Offline_Uncorrectable=0)
• Ejecutado ceph pg repair 3.ec para reescribir la copia buena sobre la réplica dañada
• No se modificó osd_max_scrubs ni ninguna configuración de deep-scrub: los 407 pgs atrasados (la config ya tiene osd_scrub_load_threshold=8.0 y osd_deep_scrub_interval=15 días, ambos más permisivos que el default) son un trade-off de rendimiento vs. velocidad de scrub que compite con I/O de clientes reales de cephfs en horario laboral, no un bug — no se cambió sin consultar al equipo

Comandos relevantes (secretos redactados)

ceph -s
rados list-inconsistent-obj 3.ec
smartctl -H /dev/sda
smartctl -A /dev/sda
ceph pg repair 3.ec
ceph osd dump | grep flag

Validación

• smartctl -H y -A en el disco de osd.13 confirmaron salud del disco antes de reparar (sin sectores reasignados ni pendientes)
• rados list-inconsistent-obj 3.ec confirmó que sólo existía una copia válida (osd.10), sin ambigüedad entre réplicas, antes de ejecutar el repair

Riesgo y reversión

El pg repair no tiene una reversión directa una vez completado; si el repair fallara o el objeto siguiera inconsistent, requeriría intervención manual adicional (revisar de nuevo con rados list-inconsistent-obj y, si aplica, restaurar desde otra réplica sana).