Files
obsidian/history/2026-04-15-longhorn-backup-label-typo.md
heimdall f55e1cffb4 Longhorn recurring job 라벨 오타 수정 + history 기록
critical/standard 18 볼륨이 recurringjob-group (대시 누락) 으로 라벨
붙어 3주간 백업 전무. recurring-job-group 으로 재라벨 + backup.md 에
라벨 키 규약 명시.
2026-04-15 10:52:06 +09:00

4.1 KiB

date, topic, areas
date topic areas
2026-04-15 Longhorn recurring job 라벨 오타로 백업 전면 미동작
infra/backup.md
infra/storage-plan.md

요약

2026-04-15 02:00 UTC 기준 점검에서 critical/standard 그룹 recurring 백업·스냅샷이 약 3주간 전혀 실행되지 않고 있었음을 발견. 원인은 Longhorn 볼륨에 부착된 라벨 키가 컨트롤러가 인식하는 형식과 달라서 그룹 셀렉터가 0건을 리턴.

증상

  • BackupTarget default 는 AVAILABLE, R2 접근 정상
  • K8s CronJob critical-snapshot/backup, standard-snapshot/backup 발화 정상 (매시/6h/24h 주기)
  • 각 job pod 는 3~4초 내 Complete, 로그상 Found 0 volumes with recurring job <name>
  • 결과: production 볼륨 18개(critical 13 + standard 5) 전부 BackupVolume CR 미존재, R2 버킷에 e2e-test 3 볼륨·100KB 만 존재

근본 원인

운영 볼륨에 다음 라벨이 붙어 있었음:

  • recurringjob-group.longhorn.io/critical=enabled
  • recurringjob-group.longhorn.io/standard=enabled

Longhorn 1.8 recurring-job 컨트롤러가 기대하는 키는 recurring-job-group.longhorn.io/<group> (recurringjob 사이 대시 포함). 두 번째 형식은 완전히 다른 라벨로 간주되어 셀렉터 매칭 실패.

정상 키로 라벨링된 동일 그룹 볼륨은 0개였기에 어떤 recurring job 도 대상 볼륨을 찾지 못함.

유입 경로 조사

  • Helm chart (longhorn 1.8.2): helm get values longhorn → null (기본값), 라벨 정의 없음
  • ArgoCD: longhorn 애플리케이션 없음 (Helm 직접 설치)
  • StorageClass longhorn/longhorn-static: recurringJobSelector 파라미터 없음
  • PVC metadata.labels: 해당 라벨 없음
  • ops-agents-tofu repo: grep 무결, runbook 에만 일반 설명
  • 기타 kaffa 소유 gitea repo (k3s-apps, helm-charts, k8s, infra-apps, runbooks, server-docs): grep 무결
  • obsidian vault: grep 무결

결론: 타이포 라벨은 수동 kubectl label 또는 Longhorn UI 로 볼륨마다 직접 부착된 것으로 추정. 업스트림 manifest 수정 불필요.

조치

  1. 18개 volumes.longhorn.io 전체에 대해 재라벨:

    kubectl -n longhorn-system label volumes.longhorn.io <vol> \
      recurringjob-group.longhorn.io/<group>- \
      recurring-job-group.longhorn.io/<group>=enabled --overwrite
    

    실행 시각: 2026-04-15 01:37 UTC. 13 critical + 5 standard 전부 성공.

  2. 01:44 UTC 수동 트리거 (kubectl create job --from=cronjob/critical-snapshot ...) 에서 13 볼륨 전부 snapshot 생성 확인. standard-snapshot 수동 트리거에서도 5 볼륨 전부 snapshot 생성.

  3. 01:46 UTC critical-backup 수동 트리거 → 13 볼륨을 concurrency=1 로 순차 업로드. 첫 볼륨 (pvc-c4bb2746) Completed 100% 확인. 나머지 12 볼륨 backup CR 생성 후 진행.

  4. 02:00 UTC 정규 스케줄 critical-snapshot run 에서도 13 볼륨 매칭 (로그 Found 13 volumes 확인 예정 — 이 문서 작성 시점 직전에 발화).

검증 방법 (재발 감시)

# 주기적으로 돌려 볼륨이 실제로 매칭되는지 검증
kubectl -n longhorn-system get volumes.longhorn.io \
  -l recurring-job-group.longhorn.io/critical=enabled --no-headers | wc -l
# → 기대: 13 (현 기준). 0 이 나오면 즉시 조사

# R2 버킷 오브젝트 수 — 꾸준히 증가해야 정상
aws s3 ls s3://longhorn-backup --recursive --summarize \
  --endpoint-url=$(kubectl -n longhorn-system get secret longhorn-backup-r2 \
    -o jsonpath='{.data.AWS_ENDPOINTS}' | base64 -d) | tail -3

재발 방지

  • ../infra/backup.md Longhorn 섹션에 라벨 키 규약 명시. 신규 PVC 를 critical/standard 그룹에 넣을 때 반드시 recurring-job-group.longhorn.io/<group> 을 쓸 것.
  • 향후 Longhorn UI 에서 볼륨 group 설정 시 UI 가 어떤 키를 쓰는지 확인 필요 (UI 가 타이포 키를 쓰는 경로였다면 upstream 이슈) — 현 시점 미확인 액션.
  • 모니터링: VictoriaMetrics/Grafana 에 "최근 24h BackupVolume 신규 생성 0건" 알람 추가 검토 (별도 작업).