Veeam Kasten 9.0.10 업데이트 - restorePrehook·Repository 관리·복구 오류 수정

10월 29일 Veeam Kasten 9.0.10이 공개됐습니다. 9.0.9에서 인증서와 Export 오류를 정리했다면, 이번 버전은 복구 직전에 애플리케이션을 정리하는 작업과 Repository 유지보수에 조금 더 초점이 맞춰져 있습니다.

특히 Operator가 관리하는 DB나 애플리케이션을 복구할 때 기존 리소스가 계속 재생성되거나 충돌해서 골치 아팠던 환경이라면 새로운 restorePrehook을 살펴볼 만합니다. 다만 이 기능은 잘못 작성하면 기존 리소스를 먼저 삭제할 수도 있기 때문에, 단순히 '복구가 편해졌다'고만 볼 수는 없습니다.

Kasten 9.0.10 주요 내용 — restorePrehook 추가, 대용량 Repository Index 유지보수 개선, VBR 인증서 갱신 후 Restore/Retire 오류 수정, k10tools repository inventory 오류 처리 개선, OpenShift Operator 업데이트 경로 개선입니다.

9.0.10에서 바뀐 부분부터 확인

이번 버전에 새로운 CVE 수정이 발표됐다는 뜻은 아닙니다. 릴리스 노트상 9.0.10은 New Features / Improvements / Bug Fixes 중심의 유지보수 릴리스입니다. 보안 패치는 바로 전 버전인 9.0.9의 eMudhra 대응과 구분해서 보는 게 좋겠습니다.

1. restorePrehook: Restore 시작 전에 필요한 작업 수행

기존 Kasten Blueprint에는 백업을 시작하기 전 실행하는 backupPrehook이 있었습니다. 9.0.10에서는 Restore 쪽에도 대응되는 restorePrehook이 추가됐습니다.

이 Hook은 BlueprintBinding 또는 워크로드의 kanister.kasten.io/blueprint Annotation으로 연결된 리소스 단위 Blueprint에서 사용합니다. Kasten이 일치하는 리소스를 복구하기 직전에 실행되며, 예를 들면 다음과 같은 작업에 활용할 수 있습니다.

• Operator의 Reconcile 동작으로 충돌하는 리소스를 사전 정리

• 복구를 방해하는 Finalizer 처리

• 복구 대상 애플리케이션 Quiesce

• 기존에 생성된 충돌 리소스 처리

restorePrehook이 실패하면 이후 Restore가 진행되지 않습니다. 그래서 Hook 스크립트의 실패 조건과 실행 권한까지 고려해야 합니다.

기존 Blueprint 관리 위치

Kasten Dashboard에서 Blueprints 메뉴로 이동하면 등록된 Blueprint를 확인할 수 있습니다. 아래 이미지는 이전 버전의 공식 화면 예시로, restorePrehook을 추가한 9.0.10 화면 자체를 캡처한 것은 아닙니다.

Kasten Dashboard의 Blueprints 관리 화면 — 출처: Veeam Kasten 공식 Blueprints 가이드 (이전 버전 UI 예시)

BlueprintBinding이 있는 환경에서는 개별 Annotation보다 Binding이 우선 적용됩니다. 두 가지 설정이 동시에 존재하는지 확인하고, 어떤 Blueprint가 실제 연결되는지도 함께 살펴보는 게 좋습니다.

restorePrehook을 적용하기 전에 꼭 알아둘 제약

공식 Kanister Action Reference에 주의할 내용이 꽤 자세히 나와 있습니다.

첫째, 대상 리소스가 아예 없으면 Hook은 실행되지 않습니다. 복구 대상 Namespace에 기존 Resource가 없는 경우 Kasten은 Hook을 건너뛰고 복구를 진행합니다.

둘째, Hook은 Restore 시점의 Live Blueprint를 읽습니다. 백업 이후 restorePrehook을 새로 추가하거나 수정하면 과거 Restore Point를 복구할 때도 변경된 Hook이 실행될 수 있습니다. 반면 restorePosthook과 restore는 Restore Point에 보관된 Blueprint 버전에 따라 실행됩니다. 과거 Restore Point에 restorePosthook이 없다면, restorePrehook으로 애플리케이션을 멈춘 후 수동으로 재개해야 하는 경우도 고려해야 합니다.

셋째, 실패 시 실행했던 변경이 자동으로 되돌아가지 않습니다. 여러 리소스가 매칭되면 하나씩 순서대로 Hook을 실행합니다. 중간 Hook이 실패하면 이후 Hook과 Restore가 중단되지만, 앞서 Hook이 삭제하거나 변경한 리소스는 자동 복구되지 않습니다.

넷째, Data-only Restore에서는 삭제 Hook을 사용하지 않는 편이 안전합니다. Data-only 또는 Volume Clone 복구는 Custom Resource 구성을 다시 만들지 않습니다. 이 모드에서 Hook이 기존 CR을 삭제했다면 복구가 끝나도 다시 생성되지 않을 수 있습니다. Kasten은 파괴적인 Hook을 Full Restore에서만 사용하도록 안내합니다.

다섯째, 재시도 가능하게 작성해야 합니다. 실패한 Restore를 다시 실행할 때 Hook이 반복 실행될 수 있습니다. 이미 없는 리소스를 삭제하려다가 실패하지 않도록, 예를 들어 kubectl delete --ignore-not-found 같은 방식으로 멱등성까지 설계하는 것이 좋습니다.

주의: restorePrehook으로 운영 리소스를 삭제하는 작업은 단순 복구 전처리가 아닙니다. 테스트 Namespace에서 Full Restore / 실패 후 재시도 / Data-only Restore의 차이를 이해하고 적용해야 합니다. 삭제 대상이 복구 과정에서 재생성되는지도 확인해야 합니다.

Blueprint 연결 상태 확인

다음 명령어는 리소스를 변경하지 않고 현재 Blueprint와 Binding 상태를 확인하는 예시입니다.

# Kasten 설치 Namespace 기준
kubectl get blueprintbindings.config.kio.kasten.io -n kasten-io

# Blueprint CR 확인
kubectl get blueprints.cr.kanister.io -n kasten-io

# 실제 Binding 상세 확인
kubectl describe blueprintbindings.config.kio.kasten.io -n kasten-io

BlueprintBinding은 Label, Namespace, Resource Type 등의 Selector를 통해 적용 대상을 결정합니다. Custom Resource의 Label을 사용하는 환경에서는 9.0.10에서 Restore 중 Label Selector를 잘못 처리하던 문제도 수정됐습니다.

아래는 Kasten Dashboard에서 개별 리소스의 Blueprint Annotation을 지정하는 공식 예시입니다. Binding을 함께 사용하는 경우에는 해당 Binding이 우선할 수 있다는 점을 기억해두면 됩니다.

Kasten 워크로드의 Configure Blueprints 화면 — 출처: Veeam Kasten 공식 가이드 (9.0.10 이전 UI 예시)

2. 대용량 Repository Index 유지보수 개선

9.0.10에서는 Storage Repository의 매 Full Maintenance 실행 전에 Quick Maintenance 단계를 먼저 수행하도록 변경됐습니다.

핵심은 Repository Index를 좀 더 이른 시점에 Compact하는 것입니다. Index가 큰 Repository에서는 유지보수 지연이나 성능 문제를 완화하는 데 도움이 될 수 있습니다.

다만 이 변경을 Repository 용량을 자동으로 줄여주는 기능으로 설명하면 안 됩니다. 어떤 Repository에서 얼마나 시간이 단축되는지는 저장된 데이터 구조와 작업량에 따라 달라집니다. 정기적으로 Export가 누적되고 Index 규모가 큰 환경에서 유지보수 완료 시간과 오류 발생 여부를 중심으로 보는 편이 좋습니다.

repository inventory도 장애 상황에서 더 유용해졌습니다

기존에는 접근할 수 없는 Repository가 하나 있으면 k10tools repository inventory가 중간에 중단될 수 있었습니다. 예를 들어 과거 Location Profile이 삭제된 Repository가 그런 사례입니다.

9.0.10에서는 접근할 수 없는 Repository를 INACCESSIBLE로 표시하고, 나머지 Repository에 대한 Inventory를 계속 작성하도록 수정됐습니다.

또한 --output json 옵션 사용 시 Progress 메시지나 Warning이 JSON 본문 앞에 출력되던 문제도 해결됐습니다. 이제 표준 출력(stdout)에는 JSON 문서만 기록되므로 자동화 스크립트에서 파싱하기도 쉬워졌습니다.

# Repository 목록 및 접근 상태 확인
k10tools repository inventory

# JSON 형식 저장 (권한·실행 환경 확인 후)
k10tools repository inventory --output json > repository-inventory.json

참고: Inventory에서 INACCESSIBLE이 표시됐다는 것은 접근 문제가 해결됐다는 뜻이 아닙니다. 점검이 멈추지 않고 결과에 표시되도록 바뀐 것이므로, 해당 Location Profile과 인증 정보·네트워크·Repository 상태는 따로 확인해야 합니다.

3. VBR 인증서 갱신 후 Restore/Retire 오류 수정

VBR Repository를 이용하는 환경에서는 이번 수정도 중요합니다.

기존에는 Veeam Backup & Replication 서버의 TLS 인증서를 갱신한 뒤, 해당 VBR Restore Point의 Restore 또는 Retire 작업이 Self-signed certificate 오류로 실패할 수 있었습니다.

원인은 Export 당시 기록된 예전 인증서 Thumbprint를 계속 사용하던 동작과 관련이 있습니다. 9.0.10에서는 과거 Export에 저장된 Thumbprint 대신 현재 Location Profile에 기록된 인증서 Thumbprint를 사용하도록 변경됐습니다.

운영 중 VBR 서버 인증서를 갱신했거나 새 인증서로 교체한 이력이 있고, 그 이후 Kasten Restore/Retire가 실패했다면 확인할 부분입니다. 다만 인증서 체인이 실제로 잘못되었거나 Profile에 저장된 Thumbprint가 틀린 경우까지 모두 자동으로 해결된다는 뜻은 아닙니다.

확인 순서는 간단합니다.

1. Kasten에서 VBR Location Profile 연결이 정상인지 확인합니다.

2. VBR 서버의 현재 TLS 인증서와 해당 Profile에 저장된 인증서 정보를 대조합니다.

3. 기존 VBR Restore Point를 사용해 격리된 복구 대상에서 Restore를 점검합니다.

4. Retire는 실제 데이터를 삭제할 수 있으므로 운영 Restore Point로 임의 테스트하지 않고, 별도 테스트 데이터와 보존 정책을 확인합니다.

4. OpenShift Operator 업데이트 경로 개선

OpenShift에서 Certified Veeam Kasten Operator를 사용하는 경우에는 OLM(Operator Lifecycle Manager)의 skipRange 설정이 추가됐습니다.

이에 따라 Operator 버전 8.0.0 이상을 사용 중인 클러스터는 여러 중간 Operator 버전을 차례로 설치하지 않고 최신 지원 버전으로 바로 업데이트할 수 있도록 경로가 개선됐습니다. 공식 릴리스 노트에는 OpenShift 4.22를 포함한 지원 Catalog 환경에 적용된다고 안내되어 있습니다.

여기서 말하는 것은 Operator의 OLM 업데이트 경로입니다. 모든 Kubernetes 환경에서 Kasten의 데이터·Catalog Schema Upgrade Path를 무조건 건너뛸 수 있다는 의미는 아닙니다. Helm으로 설치했다면 Helm 기준의 지원 경로를, Operator로 설치했다면 Subscription과 InstallPlan, Catalog Source를 확인해야 합니다.

5. 업그레이드 전후 확인 사항

이번 릴리스가 비교적 작은 유지보수 업데이트라고 해도 Catalog 저장 공간과 기존 Hook 구성은 확인해두는 게 안전합니다.

설치 버전과 Pod 상태

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

위 명령은 Helm 설치 및 기본 Namespace kasten-io 기준입니다. Operator 또는 다른 Namespace에 설치한 환경이라면 실제 배포 구성을 기준으로 확인합니다.

Helm Values 백업과 Upgrade Path 확인

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

k10tools primer upgrade

기존 Values 파일은 업그레이드 전 보관해두고, Catalog의 여유 공간과 권장 업그레이드 경로를 먼저 확인합니다. Kasten Upgrade 가이드에는 Catalog Volume에 최소 50% 이상의 여유 공간을 확보하도록 안내되어 있습니다.

아래는 Kasten Dashboard의 Upgrade Status 예시 화면입니다. 그림에 표시된 수치는 이전 공식 문서의 샘플 값이므로 9.0.10 환경에서 측정한 결과가 아닙니다.

Kasten Dashboard의 Upgrade Status 및 Catalog Storage 확인 화면 — 출처: Veeam Kasten 공식 가이드 (이전 버전 예시)

Helm 업그레이드 명령 예시

현재 설치 버전에서 바로 업그레이드할 수 있는지, Helm 저장소에 해당 Chart가 제공되는지 먼저 확인합니다.

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

지원 경로를 확인한 Helm 기반 환경이라면 다음과 같은 형태로 적용할 수 있습니다.

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

이 명령은 일반적인 Helm 설치 예시이며, 실제 Chart Version과 현재 배포 환경에서 지원되는 경로가 일치할 때만 적용해야 합니다. Private Registry, Air-Gapped, Operator 기반 환경은 각각의 공식 설치 절차가 우선입니다.

적용 후에는 기능별로 확인

• ☐

  Kasten Pod와 Catalog 서비스가 정상으로 올라왔는지

• ☐

  기존 Backup Policy 실행과 Restore Point 생성이 정상인지

• ☐

  Blueprint / BlueprintBinding 매핑이 기존과 동일한지

• ☐

  restorePrehook을 사용하는 경우 격리된 대상에서 Full Restore가 정상인지

• ☐

  restorePrehook 실패 및 재시도 시 리소스가 어떻게 남는지

• ☐

  Repository Maintenance Action과 Inventory가 정상인지

• ☐

  VBR Location Profile과 기존 Restore Point 복구가 정상인지

• ☐

  OpenShift Operator 구성이라면 OLM 업데이트 상태가 정상인지

운영 관점에서 정리

Kasten 9.0.10은 겉으로 보면 작은 릴리스지만, Restore 전처리와 Repository 관리에 직접적인 변화가 있습니다.

특히 restorePrehook은 Operator 기반 애플리케이션 복구에서 활용도가 높을 수 있습니다. 대신 실패 후 원상복구가 자동으로 보장되지 않는다는 점, 과거 Restore Point에도 현재 Live Blueprint의 Hook이 실행될 수 있다는 점은 반드시 기억해둘 필요가 있습니다.

Repository Index가 크거나 VBR 인증서 갱신 이후 복구 오류가 있었던 환경이라면 이번 수정은 적용할 만한 가치가 있습니다. 업데이트 전에 Catalog 공간, Blueprint 연결 관계, 유지보수 정책을 점검하고, 적용 후에는 실제 Restore 경로까지 확인하면 좋겠습니다.

공식 참고자료

• Veeam Kasten 9.0.10 Release Notes

• Reserved Action Names and Timeouts — restorePrehook 주의사항

• Blueprint Bindings

• Blueprints 관리 가이드

• Kasten Dashboard Overview

• Veeam Kasten Upgrade Guide

버전 기준: Veeam Kasten 9.0.10, 2026년 10월 29일 릴리스. 본문의 UI 이미지는 공식 가이드에서 제공하는 예시 화면이며 특정 운영 환경에서 실행한 테스트 증적은 아닙니다.