---
date: 2026-04-15
topic: Longhorn recurring job 라벨 오타로 백업 전면 미동작
areas: [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>`** (`recurring` 과 `job` 사이 대시 포함). 두 번째 형식은 완전히 다른 라벨로 간주되어 셀렉터 매칭 실패.

정상 키로 라벨링된 동일 그룹 볼륨은 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 전체에 대해 재라벨:
   ```bash
   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` 확인 예정 — 이 문서 작성 시점 직전에 발화).

## 검증 방법 (재발 감시)

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