---
date: 2026-05-17
topic: SafeLine RWX PVC ext4 호환성 인시던트 — Longhorn v1.11.2 strict fsck 거부
areas: [infra/platform/longhorn, infra/security/crowdsec-safeline]
---

# 2026-05-17 / SafeLine RWX PVC 손상 복구 — Longhorn 1.11.2 share-manager strict fsck

## 증상

`/sc:test` 클러스터 상태 점검 중 발견:

- `safeline-mgt` Pod: `CrashLoopBackOff` (restart 1008회, 3일 15시간)
- `safeline-luigi` Pod: `Init:0/1` (43시간 wait, mgt:1443 폴링)
- 그 외 SafeLine pods (chaos/database/detector/fvm) 정상

mgt 로그:
```
panic: failed to init models: init empty license error: database disk image is malformed (11)
  /work/initialize/pg_init.go:82
  SELECT * FROM `options` WHERE key = "license"
```

표면적으로는 SQLite SQLITE_CORRUPT(11). 실제 SafeLine 메인 DB(PostgreSQL `safeline-database-0`)는 정상.

## 근본 원인

mgt를 scale 0으로 내리고 디버그 pod로 PVC mount 시도하니 `FailedAttachVolume "Waiting for volume share to be available"` — Longhorn share-manager pod가 1초만에 Failed로 죽고 2분 backoff 사이클 반복. share-manager 로그 캡처:

```
/dev/longhorn/pvc-8534d9f3-...: Resize inode not valid.
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
        (i.e., without -a or -p options)
fatal: 'fsck' found errors on device but could not correct them
```

즉 **ext4 superblock metadata 손상** (`Resize inode not valid`)으로 share-manager가 자동 모드 fsck (`-a`/`-p`)로 거부 → NFS export 못함 → 모든 PVC mount 실패.

[[2026-05-07-longhorn-1-11-2-upgrade]] 업그레이드에서 share-manager 이미지가 v1.11.2로 바뀌면서 fsck strict 모드로 동작. 옛 fs metadata와 호환성 깨진 것이 주범으로 판단. 실제 데이터는 정상일 가능성 매우 큼 (수동 `fsck -y` 한 번이면 풀림).

## 영향 받은 PVC

같은 시점에 만들어진 `incus-hp2` 노드의 RWX PVC 3개 모두 동일 패턴:

| PVC | 옛 PV | 상태 |
|---|---|---|
| `safeline/safeline-mgt` | `pvc-8534d9f3-91b9-49c3-9acd-804581c51893` | Released (Retain 보존) |
| `safeline/safeline-tengine-logs` | `pvc-15af4f6d-6129-4858-ae51-a3aa3546c4c2` | Released (Retain 보존) |
| `safeline/safeline-luigi` | `pvc-3c39ef90-d8ea-402d-8363-772ddbaf56a2` | Released (Retain 보존) |

같은 노드의 다른 RWX 4개 (chaos/detector/detector-logs/8f9bfed6)는 mount 유지 중이라 영향 없음 — 다음 재기동 시 동일 에러 가능성.

## 시도한 조치

1. **Longhorn snapshot revert (2026-05-13 16:03, `52eb920e`, 손상 직전 시점)** — 실패. blockdev revert로 ext4 metadata도 같이 복원되어 동일 fsck 에러 재현.
2. **PVC 폐기 + 동일 이름 새 PVC 생성** — 성공. 새 mkfs.ext4로 만들어진 fs는 strict fsck 통과.

## 복구 절차 (재사용 가능)

```sh
NS=safeline
NAME=safeline-mgt      # 손상 PVC 이름
SIZE=1Gi               # 동일 사이즈

# 1. 워크로드 내림
kubectl -n $NS scale deploy $NAME --replicas=0

# 2. PV reclaim Retain으로 변경 (포렌식용 보존)
PV=$(kubectl -n $NS get pvc $NAME -o jsonpath='{.spec.volumeName}')
kubectl patch pv $PV -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'

# 3. PVC 삭제 (PV는 Released 상태로 살아남음)
kubectl -n $NS delete pvc $NAME

# 4. 동일 이름 새 PVC 생성
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: $NAME
  namespace: $NS
spec:
  accessModes: [ReadWriteMany]
  resources:
    requests:
      storage: $SIZE
  storageClassName: longhorn
  volumeMode: Filesystem
EOF

# 5. 워크로드 올림
kubectl -n $NS scale deploy $NAME --replicas=1
```

## 데이터 영향

- **mgt**: 라이선스/룰/설정 초기화 → SafeLine UI 첫 로그인 + 라이선스 재입력 필요. WAF 검출 룰 정본은 PG에 있으므로 검출 자체는 그대로 동작.
- **tengine-logs**: nginx access log 손실 (가치 없음).
- **luigi**: 검출 캐시 손실, 정본은 PG.

## 옛 PV 데이터 복구 가능성

3개 옛 PV는 reclaim Retain으로 `Released` 상태 보존 중. 향후 시간 있을 때 `fsck.ext4 -y /dev/longhorn/pvc-...` 로 메타 복구 후 디버그 pod에 mount해서 데이터 추출 시도 가능. 특히 mgt 라이선스 파일(`/app/data/license`) 회수 가능성.

## Longhorn HTTP API 작업 노트

snapshot revert 시도 시 사용. port-forward는 longhorn-manager 포트 9500이 0.0.0.0이 아닌 다른 인터페이스에 bind되어 macOS에서 직접 forward 실패 → in-cluster pod에서 호출 필요.

```sh
# in-cluster curl pod
kubectl -n longhorn-system run lh-curl --image=curlimages/curl:8.10.1 \
  --command -- sleep 7200

# Volume detach → maintenance attach → snapshot revert
VOL=pvc-XXX
LH=http://longhorn-backend:9500
kubectl -n longhorn-system exec lh-curl -- sh -c "
  curl -X POST $LH/v1/volumes/$VOL?action=detach -d '{}'
  curl -X POST $LH/v1/volumes/$VOL?action=attach \
    -d '{\"hostId\":\"<node>\",\"disableFrontend\":true,\"attachedBy\":\"manual\"}'
  curl -X POST $LH/v1/volumes/$VOL?action=snapshotRevert \
    -d '{\"name\":\"snapshot-<uuid>\"}'
  curl -X POST $LH/v1/volumes/$VOL?action=detach -d '{}'
"
```

## 잠재 위험 (TODO)

- 같은 노드/같은 시점 mkfs된 다른 RWX 볼륨도 share-manager 재기동 시 동일 에러 가능. 사전 점검 가치 있음 — 한 번씩 detach/reattach 사이클 돌려 fail하는 PVC 식별 후 미리 교체.
- 또는 share-manager의 fsck 옵션을 `-y`로 patch (Longhorn 자체 코드 수정 필요, upstream 이슈로 보고 권장).

## 2026-05-18 후속 — detector PVC 폭발 (예측 적중)

어제 명시한 4개 위험 PVC 중 `safeline/safeline-detector` (옛 PV `pvc-8f9bfed6`)가 **2026-05-17 23:12 KST부터 6시간 이상 VolumeAttachment finalizer hang** (`Waiting for volume share to be available`) 후 **2026-05-18 14:18 KST 동일 절차로 복구**됨. 신규 PV `pvc-d2654f70-01e2-4a40-8336-1b56ddacb2cb` 바인딩, detector 파드 정상 기동(rskynet hyperscan 47 패턴 로드, NFSv4.1 클라이언트 정상 등록). 데이터 영향 없음(detector PVC는 룰셋/캐시, 이미지에 포함).

복구 actor 미상 — helm/Argo 변경 없음(generation/RS 변동 없음), K3s audit log 부재로 PVC 삭제 호출자 식별 불가. csi-plugin이 attach 강제 시도까지는 자동, PVC delete/recreate는 사람 또는 다른 자동화로 추정.

### 남은 시간폭탄

| PVC | PV | 노드 | mkfs 시점 | 위험 |
|---|---|---|---|---|
| `safeline/safeline-chaos` | `pvc-0440758f-f056-46d0-9733-dbb77f2e9101` | incus-hp2 | 55d (2026-03-24) | 다음 share-manager 재기동 시 동일 ext4 fsck 거부 예상 |
| `safeline/safeline-detector-logs` | `pvc-384dd143-05b6-4cd6-a0dd-3edf5dca3acc` | incus-hp2 | 55d (2026-03-24) | 동일 |

어제 위험 명단의 `detector`와 `8f9bfed6`은 동일 PVC(`safeline-detector`)에 옛 PV였고 이번에 해소됨. 남은 둘은 어제 절차로 사전 교체 가능 — 데이터 가치 낮음(chaos = 검출 룰 캐시 / detector-logs = nginx access 로그).

### 학습

- v1.11.2 share-manager strict fsck는 옛 ext4 metadata와 호환 안 됨 — 같은 시점 mkfs된 RWX 볼륨은 **share-manager 재기동을 절대 트리거하지 말거나** 사전에 강제 교체해야 함.
- 같은 노드 RWX share-manager 6개 집중 위험은 별건 — incus-hp2 share-manager 이슈 시 SafeLine 전체 영향.

## 관련

- [[../infra/platform/longhorn]] — Longhorn 플랫폼 정본
- [[../infra/security/crowdsec-safeline]] — SafeLine ↔ CrowdSec 연동
- [[2026-05-07-longhorn-1-11-2-upgrade]] — 직전 업그레이드