Veeam Kasten 9.0.7 업데이트 - Export·Restore 주요 수정

Kasten 9.0.6에서 Kubernetes 1.35 지원과 여러 운영 개선이 들어간 뒤, 바로 다음 유지보수 릴리스인 9.0.7이 10월 2일 공개됐습니다. 이번 버전은 기능 추가보다 운영 중 멈추거나 오래 끌 수 있는 작업을 정리하는 쪽에 무게가 있습니다. 특히 Export가 많이 겹치는 환경이라면 이번 수정은 꽤 눈여겨볼 만합니다.

이번 글에서 가장 중요한 부분은 대량 Export 동시 실행 시 executor thread가 고갈되면서 다른 Backup/Restore까지 진행되지 않을 수 있었던 문제입니다. 9.0.7에서는 동시성 한도를 넘는 Export를 대기 후 재큐잉하도록 동작이 바뀌었습니다.

이번 9.0.7에서 먼저 볼 내용

Veeam Kasten 9.0.7은 2026년 10월 2일 공개됐습니다. 운영 관점에서는 아래 네 가지 수정이 핵심입니다.

많은 Export 작업이 동시에 실행될 때 executor thread가 소진되어 다른 Backup/Restore 작업까지 진행되지 못할 수 있던 문제 수정

취소한 Restore 또는 Import 작업이 오랫동안 계속 실행될 수 있던 문제 수정

Azure Infrastructure Profile에서 선택 입력값을 비웠을 때 validation error가 발생하던 문제 수정

KubeVirt VM의 Run Strategy가 RerunOnFailure 또는 Manual인 환경에서 Restore 시 기존 VM을 정상적으로 scale down하지 못하던 문제 수정

9.0.7의 보안 변경에는 auth-svc 권한의 Namespace 범위 축소, Go 1.27.1 업데이트, Prometheus·Operator의 기본 seccomp 설정, 컨테이너 Base Image 보안 업데이트가 포함됩니다. 9.0.7 릴리스 노트

Export가 몰릴 때 Backup·Restore까지 막히던 문제

이번 릴리스에서 가장 운영 영향이 큰 부분입니다.

대량의 Export 작업이 동시에 실행될 경우 executor thread를 계속 점유하면서, Export뿐 아니라 다른 Backup이나 Restore 작업까지 실행되지 못하는 상황이 발생할 수 있었습니다.

9.0.7에서는 limiter.snapshotExportsPerCluster 동시성 한도를 초과한 Export 작업을 executor thread에서 계속 붙잡고 있는 대신 defer 후 다시 queue에 넣는 방식으로 처리합니다.

쉽게 보면 기존에는 다음과 같은 상황이 가능했습니다.

Export 작업 대량 실행
        ↓
Executor Thread 점유
        ↓
동시성 제한을 넘은 Export도 Thread 대기
        ↓
가용 Thread 부족
        ↓
Backup / Restore 작업까지 대기

9.0.7에서는 한도를 초과한 Export를 다시 대기열로 넘기기 때문에, 특정 Export 부하가 전체 작업 실행부를 막는 상황을 줄이는 방향으로 수정됐습니다.

이런 환경이면 우선순위를 높게 보는 게 좋습니다

하나의 클러스터에서 여러 Policy가 비슷한 시간대에 Export를 수행하는 환경

Object Storage 또는 외부 Repository로 Export가 집중되는 환경

Backup Window가 짧아 작업이 한꺼번에 몰리는 환경

Export와 Restore를 동시에 운영하는 환경

과거에 Action이 대기 상태로 오래 남거나 다른 작업까지 같이 밀리는 현상이 있었던 환경

이번 수정은 단순 UI 변경이 아니라 실제 작업 스케줄링과 실행 여유에 영향을 주는 부분이라, 작업량이 많은 클러스터일수록 체감이 클 수 있습니다.

취소한 Restore·Import가 오래 남는 문제도 수정

운영 중 Restore나 Import를 취소했는데도 Action이 바로 종료되지 않고 한동안 계속 남는 경우가 꽤 번거롭습니다.

9.0.7에서는 취소된 Restore 또는 Import Action이 장시간 계속 실행될 수 있던 문제가 수정됐습니다.

취소 작업이 길게 남으면 다음 작업을 시작할 때 상태 판단이 애매해지고, 장애 대응 중에는 실제 진행 중인 작업과 이미 취소한 작업을 구분하기도 불편합니다. 이런 유형의 문제를 겪고 있었다면 9.0.7 적용 후 Action 종료 흐름을 같이 확인해보는 게 좋습니다.

KubeVirt VM Restore 환경도 확인

KubeVirt VM을 보호하고 있다면 이번 수정도 체크할 부분입니다.

기존에는 VM의 Run Strategy가 아래 중 하나인 경우 Restore 과정에서 기존 VM을 scale down하지 못해 실패할 수 있었습니다.

RerunOnFailure

Manual

9.0.7에서 이 Restore 문제가 수정됐습니다.

Kasten을 VM 보호 용도로 사용하고 있고 KubeVirt 기반 워크로드가 있다면 단순 버전 업데이트 후 끝내기보다, 기존 Restore Point를 이용해 테스트 VM 또는 격리된 Namespace에서 Restore 동작을 한 번 확인하는 편이 좋습니다.

Azure Infrastructure Profile을 쓰는 환경

Azure Infrastructure Profile 설정 화면에서 선택값인 다음 Endpoint 항목을 비우면 validation error가 발생하는 문제가 있었습니다.

Resource Manager Endpoint

Entra ID Endpoint

Entra ID Resource

9.0.7에서는 해당 값이 비어 있어도 정상적으로 허용되며, 빈 값이면 기본 Azure Endpoint가 사용됩니다.

일반 Azure 환경에서 별도 Endpoint를 사용하지 않는 구성이라면 설정 수정 시 불필요하게 값을 채워 넣어야 했던 문제가 줄어듭니다.

업그레이드 전에 확인할 것

Kasten 업그레이드는 버전만 바꾸고 바로 진행하기보다 Catalog 공간부터 보는 게 좋습니다. Kasten의 Upgrade 안내에서는 Catalog Storage에 최소 50% 이상의 여유 공간을 요구하며, Dashboard의 Settings > System Information > Upgrade Status 또는 k10tools primer upgrade를 통해 현재 상태와 권장 업그레이드 경로를 확인할 수 있습니다.

먼저 현재 릴리스와 Pod 상태를 확인합니다.

helm list --namespace kasten-io

kubectl get pods -n kasten-io

9.0.7 기준 일반 사전 점검은 공식 Primer를 이용할 수 있습니다.

curl https://docs.kasten.io/downloads/9.0.7/tools/k10_primer.sh | bash

업그레이드 경로를 확인하려면 k10tools primer upgrade도 같이 활용할 수 있습니다.

k10tools primer upgrade

Helm으로 설치한 환경에서는 현재 values를 백업한 뒤 업그레이드하는 방식이 공식 가이드에 안내되어 있습니다.

helm repo update

helm get values k10 \
  --output yaml \
  --namespace=kasten-io > k10_val.yaml

helm upgrade k10 kasten/k10 \
  --namespace=kasten-io \
  --version 9.0.7 \
  -f k10_val.yaml

실제 업그레이드 전에 현재 Kasten 버전과 권장 Upgrade Path를 먼저 확인하는 편이 안전합니다. 버전이 많이 뒤처져 있다면 한 번에 최신 버전으로 올리기보다 단계 업그레이드가 필요할 수 있습니다.

이 예시는 9.0.7을 지정합니다. --version을 생략하면 실행 시점의 최신 차트가 선택될 수 있습니다. Helm 설치 환경 업그레이드

Azure Blob 불변 백업 복구 주의사항

9.0.7 Known Issues에는 Azure API 변경으로 Azure Blob의 불변 백업 복구가 실패할 수 있다고 안내되어 있습니다. 백업 데이터 자체는 영향을 받지 않습니다. 안내된 우회 방법은 같은 컨테이너를 가리키는 별도 Location Profile에서 immutability를 비활성화하고, 복구 시 Alternate Location Profile로 선택하는 것입니다. 기존 버킷·컨테이너의 보존 정책을 해제하라는 의미로 해석하면 안 됩니다. Known Issues

적용 후 체크할 부분

업데이트 이후에는 단순히 Pod가 Running인지 보는 것보다 이번 릴리스에서 수정된 동작을 중심으로 확인하는 게 좋습니다.

여러 Export Action이 동시에 실행될 때 Backup/Restore가 함께 밀리지 않는지 확인합니다.

Export 동시성 제한을 넘는 작업이 대기 후 정상적으로 다시 실행되는지 확인합니다.

Restore 또는 Import 취소 후 Action이 불필요하게 오래 남지 않는지 봅니다.

KubeVirt를 사용한다면 RerunOnFailure / Manual Run Strategy VM의 Restore를 테스트합니다.

Azure Infrastructure Profile을 사용한다면 기본 Endpoint 사용 시 설정 저장이 정상인지 확인합니다.

Dashboard에서 Upgrade Status와 Catalog 공간 상태를 다시 확인합니다.

같이 알아둘 점

9.0.6에서 이미 Kubernetes 1.35 지원, API Client QPS/Burst 조정, RestorePoint 만료 관리 같은 변화가 들어갔습니다. 9.0.7은 그 다음 단계의 유지보수 릴리스로 보는 게 자연스럽습니다.

특히 이번 릴리스는 새 기능보다 Export 부하가 다른 보호 작업까지 영향을 주는 문제와 취소된 Restore/Import가 오래 남는 문제를 줄이는 것이 핵심입니다. Kasten을 실제 운영 환경에서 여러 Policy와 Export 작업을 동시에 돌리고 있다면 우선 적용 후보로 잡아둘 만합니다.