블로그 홈

Veeam Kasten 9.0.9 보안 업데이트

Kasten 9.0.9의 eMudhra 보안 대응, Block Mode Export 오류 수정, VBR 13.2 연동, 업그레이드 체크포인트를 정리합니다.

운영자12분 읽기1회
Veeam Kasten 9.0.9 보안 업데이트

10월 22일 Veeam Kasten 9.0.9가 공개됐습니다. 이번 릴리스는 새 기능보다 보안 대응, 다중 볼륨 Export 오류 수정, VBR 연동 호환성에 더 집중한 유지보수 업데이트입니다.

특히 eMudhra 인증서 이슈를 대응해야 하거나, 여러 PVC를 Block Mode로 Export하는 환경이라면 확인해둘 만합니다. Kasten을 VBR 저장소와 연동하고 있다면 향후 VBR 13.2 이상과의 호환성도 함께 봐야 합니다.

9.0.9 핵심: eMudhra CA Trust Store 수정 및 Go 1.27.3, VBR 13.2 이상 Data Mover 인증서 교환 지원, 다중 볼륨 Block Mode Export 오류 수정, 일부 VM 백업 실패 수정, Timeout 설정 검증 강화.

이번 버전에서 달라진 점

구분

변경 내용

운영 시 확인할 사항

보안

eMudhra 인증서 차단 및 Go 보안 업데이트

Kasten 컨테이너 이미지 업데이트

VBR 연동

13.2 이상 Data Mover 인증서 교환 방식 지원

VBR Repository Export 연결

Export

다중 볼륨 Block Mode Export 오류 수정

다중 PVC 워크로드

VM 보호

Live Migration 직후 RWO PVC VM 백업 오류 수정

KubeVirt VM 보호

Timeout

0·음수 값 검증 및 기본값 대체

기존 Helm Values

모니터링

Action 종료 시각 오류의 Prometheus 지표 누락 수정

Action Metrics

보안: eMudhra 인증서와 Go 1.27.3

eMudhra 인증서 문제는 Kubernetes Node OS만 패치한다고 끝나지 않습니다. Kasten 서비스는 자체 컨테이너 이미지 안의 인증서 신뢰 저장소를 사용하기 때문입니다.

9.0.9에서는 컨테이너 이미지의 Trust Store에서 문제가 된 emSign ECC Root CA - G3 인증서를 제거했습니다. 별개의 Comodo AAA Services Root 인증서도 예방 차원에서 제거했습니다. Go 1.27.3으로 업데이트해 CVE-2026-111943에 대응했고, 컨테이너 Base Image의 보안 업데이트도 포함됐습니다.

Veeam KB4825에는 프런트엔드의 @vue/server-renderer 관련 GHSA-g2v6-rqmx-r4w6 수정 이력도 별도로 정리되어 있습니다. 보안 업데이트가 필요한 환경이라면 9.0.9 적용을 우선 검토할 만합니다.

기존 컨테이너 내부 CA 저장소를 임의로 편집하거나 문제가 있는 CA를 다시 신뢰하도록 예외 설정하는 방식은 피하는 것이 좋습니다. 공식 수정 이미지로 업그레이드하는 것이 권장 방향입니다.

VBR 13.2 이상과의 Data Mover 인증서 교환

Kasten 9.0.9는 Veeam Backup & Replication 13.2 이상에서 요구하는 Data Mover 인증서 교환 방식을 지원합니다.

VBR Repository로 Kubernetes 데이터나 VM Volume을 Export하는 환경이라면 이번 변경을 같이 챙겨야 합니다. 현재 연결이 정상이라는 이유만으로 앞으로의 VBR 업그레이드에도 무조건 문제가 없다고 판단하지 않는 편이 좋습니다.

아래 이미지는 공식 가이드의 Block Mode Export 설정 화면입니다. 이전 버전의 설명용 화면이며 9.0.9의 실제 화면을 캡처한 것은 아닙니다.

Kasten Policy에서 Block Mode Export와 VBR Location Profile을 설정하는 화면 — 출처: Veeam Kasten 공식 가이드(이전 버전 예시)

Kasten Policy에서 Block Mode Export와 VBR Location Profile을 설정하는 화면 — 출처: Veeam Kasten 공식 가이드(이전 버전 예시)

업그레이드 전에는 VBR Location Profile의 연결 상태와 기존 Policy의 Export Action을 먼저 확인하고, 적용 후 같은 유형의 작업이 정상 완료되는지 비교하면 됩니다. 이번 공식 안내는 '새 인증서 교환 방식 지원'이며, 구버전 조합이 모두 실패한다고 단정하지는 않습니다.

여러 볼륨이 포함된 Block Mode Export 오류

하나의 애플리케이션이나 VM에서 여러 PVC를 함께 사용하는 환경이라면 눈여겨볼 수정입니다.

이전 버전에서는 여러 Volume을 포함한 Block Mode Export에서 concurrent map writes 오류가 간헐적으로 발생할 수 있었습니다. 9.0.9에서는 이 문제가 수정됐습니다.

운영 중 다음 항목이 있었다면 확인해두는 편이 좋겠습니다.

  • 다중 PVC 애플리케이션의 Export Action 실패 이력

  • Block Mode Export를 사용하는 Policy 및 VBR Location Profile

  • Export 실패 시점의 Executor/Data Mover 로그

  • 패치 후 동일한 형태의 Export 및 Restore Point 생성 여부

이 문제는 여러 Volume을 대상으로 한 Block Mode Export라는 조건이 있습니다. 모든 Snapshot이나 모든 Export 오류가 같은 원인이라고 볼 수는 없습니다.

광고

Live Migration 직후 VM 백업 실패 수정

VM 보호 쪽 수정도 있습니다. RWO(ReadWriteOnce) Storage의 Persistent State PVC를 사용하는 VM이 최근 Live Migration된 경우, 백업이 실패할 수 있던 문제가 수정됐습니다.

KubeVirt 기반 VM을 Kasten으로 보호하고 있다면 Migration 후 보호 작업을 살펴보는 게 좋습니다. VM이 정상 실행 중이라는 사실과 Kasten Backup이 정상 완료됐다는 사실은 별개이므로, 실제 Restore Point 생성까지 확인해야 합니다.

Action 메트릭이 누락되던 문제

Action Manifest에 종료 시각이 없거나 생성 시각보다 과거로 기록된 경우, Catalog 서비스가 복구 가능한 Panic을 기록한 뒤 해당 전환의 Prometheus Action 메트릭을 누락하던 문제가 수정됐습니다.

대시보드에서 실제 Action 상태와 집계 지표가 맞지 않는 현상이 있었다면 관련 수정입니다. 다만 이전에 누락된 모든 과거 지표가 자동으로 복원된다는 뜻은 아닙니다.

Helm Timeout 값이 0 또는 음수라면 먼저 확인

9.0.9에서 실수하기 쉬운 부분이 Timeout 설정 검증입니다. 이전 Values 파일에 0 또는 음수가 들어 있으면, 새로운 Helm Chart의 검증 규칙 때문에 설치·업그레이드 과정에서 오류가 발생할 수 있습니다.

영향받는 파라미터는 다음과 같습니다.

  • timeout.backup, timeout.restore, timeout.retire

  • timeout.blueprintResourceHooks

  • timeout.checkRepoPodReady, timeout.statsPodReady

  • timeout.efsRestorePodReady, timeout.workerPodReady

  • timeout.imageStreamImageResolveSec

해당 값은 최소 1 이상이어야 합니다. timeout.jobWait은 빈 값이거나 최소 1 이상이어야 합니다. 반면 오래된 timeout.blueprint* 및 kanister.*Timeout 항목은 이번 검증 규칙에서 제외됩니다.

또 하나의 차이가 있습니다. 잘못된 설정이 수동으로 편집한 k10-config ConfigMap을 통해 실행 중인 서비스로 전달되면, 일부 서비스는 기본값을 사용하고 경고를 남깁니다. 하지만 timeout.workerPodReady는 Helm Chart에서만 검사합니다.

기존 설정부터 백업하고 확인합니다.

helm get values k10   --namespace kasten-io   --output yaml > k10-values-before-9.0.9.yaml

grep -nE 'timeout:|jobWait:|workerPodReady:|blueprint'   k10-values-before-9.0.9.yaml

위 명령은 Values 파일에서 설정 위치를 찾는 용도입니다. 실제 설정이 유효한지는 YAML 구조와 Chart Validation 결과도 같이 확인해야 합니다.

업그레이드 전에 확인할 것

Kasten은 Catalog Storage 여유 공간이 최소 50% 필요합니다. 오래된 버전에서 한 번에 최신 버전으로 올리는 대신 단계 업그레이드가 필요한 경우도 있으므로, 현재 버전과 권장 경로부터 확인하는 편이 좋습니다.

1. 현재 Helm Release와 Pod 상태 확인

helm list --namespace kasten-io
kubectl get pods -n kasten-io
kubectl get pvc -n kasten-io

2. Upgrade Status / 권장 경로 확인

Kasten Dashboard의 Settings → System Information → Upgrade Status에서 Catalog 여유 공간과 권장 업그레이드 정보를 확인할 수 있습니다.

k10tools primer upgrade

아래는 Veeam Kasten 공식 가이드의 Upgrade Status 예시 화면입니다. 예시 화면의 Kasten 버전과 Catalog 수치는 과거 문서의 샘플 값이며, 이번 9.0.9 환경을 실제 측정한 결과는 아닙니다.

Kasten Upgrade Status에서 버전과 Catalog Storage 여유 공간을 확인하는 예시 — 출처: Veeam Kasten 공식 가이드(과거 버전 화면)

Kasten Upgrade Status에서 버전과 Catalog Storage 여유 공간을 확인하는 예시 — 출처: Veeam Kasten 공식 가이드(과거 버전 화면)

3. Helm Values 보관 및 Chart 버전 확인

helm get values k10 --namespace kasten-io   --output yaml > k10-values-before-9.0.9.yaml

helm repo update
helm search repo kasten/k10 --versions | head -15

실제 설치 환경의 Helm Release 이름이 k10이 아니라면 해당 이름으로 변경해야 합니다. Image Registry, 인증 설정, License, StorageClass, 기존 Timeout 값도 같이 확인합니다.

4. Helm 기반 업그레이드 명령 예시

helm upgrade k10 kasten/k10   --namespace kasten-io   -f k10-values-before-9.0.9.yaml   --version 9.0.9

이 명령은 일반적인 Helm 배포 환경의 예시입니다. 해당 Chart가 저장소에 제공되고, 현재 설치 버전에서 9.0.9로 바로 이동할 수 있는 경우에만 사용해야 합니다. Operator, Marketplace, Air-Gapped 환경에서는 해당 배포 방식의 공식 업그레이드 경로를 따라야 합니다.

5. 적용 후 확인

helm list --namespace kasten-io
kubectl get pods -n kasten-io
kubectl get events -n kasten-io --sort-by=.lastTimestamp

Pod가 Running인지 확인하는 것에서 끝내지 말고 기존 Policy의 Backup/Export, Restore Point 생성, 필요 시 격리된 대상에 대한 Restore, VBR 연동을 순서대로 확인하는 게 좋습니다.

체크 포인트: 다중 Volume Block Mode Export, Live Migration 이력이 있는 KubeVirt VM, VBR Repository 연동, Prometheus Action 지표, Timeout 경고 로그를 사후 확인 항목으로 잡으면 좋습니다.

버전별 주의사항

9.0.8에서는 Kubernetes 1.36 지원이 추가되는 동시에 x86-64 환경의 최소 CPU 요구 사항이 x86-64-v3로 상향됐습니다. 구형 물리 서버나 오래된 CPU 호환 모드로 생성된 VM 위에서 Kubernetes를 운영한다면, 9.0.9 자체 변경뿐 아니라 직전 릴리스의 요구 사항도 확인할 필요가 있습니다.

아울러 Kasten 9.0 계열 릴리스에는 Block Mode Export Repository에서 k10tools repository cleanup을 사용할 때 유효한 Restore Point 데이터를 잘못 정리할 수 있다는 Known Issue가 안내된 이력이 있습니다. 해당 유형 Repository에서는 Cleanup을 임의로 수행하지 말고 현재 설치 버전의 제한 사항을 먼저 확인하는 것이 안전합니다.

정리

Kasten 9.0.9는 보안 패치와 실제 백업 작업 안정성을 함께 개선한 유지보수 릴리스입니다. 특히 eMudhra 인증서 대응이 필요하거나 여러 PVC를 Block Mode로 Export하고 있다면 적용 우선순위를 높게 볼 만합니다.

VBR 13.2 이상과의 연동을 계획하고 있는 환경도 이번 인증서 교환 방식 변경을 알아둘 필요가 있습니다. 다만 업그레이드 전에는 Catalog 여유 공간, CPU 요구 사항, Helm Timeout 설정, 권장 업그레이드 경로를 함께 확인하는 편이 좋겠습니다.

공식 참고자료

버전 기준: Kasten 9.0.9 (2026년 10월 22일 릴리스). 문서의 예시 화면은 이전 버전의 공식 가이드 화면입니다.

광고

운

운영자

운영자

엔터프라이즈 인프라, 가상화, 백업 솔루션 및 데이터 아키텍처를 연구하고 기록합니다.

이전

다음

관련 게시글

V

Veeam Kasten 9.0.7 업데이트 - 대규모 Export 병렬 처리와 Restore 지연 수정

Veeam Kasten 9.0.7에서 대량 Export 동시 실행 시 executor thread 고갈로 Backup·Restore까지 지연될 수 있던 문제가 수정됐습니다. 취소된 Restore/Import 장기 실행, KubeVirt Restore, Azure Infrastructure Profile 수정 사항과 업그레이드 전 체크포인트를 함께 정리합니다.

9분 읽기3

댓글

또는 로그인

첫 번째 댓글을 남겨보세요!