Veeam Backup from Storage Snapshots 구성 가이드 - VMware Snapshot Stun 줄이는 방법

VMware 가상머신을 백업할 때 백업 작업 자체는 정상적으로 끝났는데, 마지막 VMware Snapshot 제거 과정에서 VM이 잠깐 멈추거나 Consolidation 시간이 길어지는 상황을 본 적이 있을 겁니다.

특히 데이터 변경량이 많은 DB 서버나 업무 시스템에서는 Snapshot이 오래 유지될수록 Delta Disk가 커지고, 마지막 Merge 과정에서 서비스 지연이 발생할 수 있습니다.

이럴 때 검토할 수 있는 기능이 Veeam Backup & Replication의 Backup from Storage Snapshots입니다. VMware Snapshot을 전혀 만들지 않는 기술은 아니고, Storage Array Snapshot을 만든 직후 VMware Snapshot을 빨리 제거한 뒤, 백업 데이터는 스토리지 Snapshot에서 읽는 방식입니다.

이번에는 VBR 13.1.2 공식 문서를 기준으로 동작 원리, 지원 조건, Job 설정 방법과 실제 적용 여부를 확인하는 과정을 정리해보겠습니다.

핵심: Backup from Storage Snapshots는 VMware VM을 대상으로 스토리지 Snapshot을 백업 데이터의 읽기 원본으로 사용합니다. 생성된 백업 파일은 별도의 Backup Repository에 저장됩니다. Storage Snapshot만 남겨놓는 Snapshot-Only Job과는 다릅니다.

1. 왜 일반 VMware 백업에서 Snapshot Stun이 발생할까?

일반적인 VMware 이미지 레벨 백업은 VM Snapshot을 생성한 뒤 그 시점을 기준으로 데이터를 읽습니다.

Snapshot이 유지되는 동안 VM의 새 쓰기 작업은 Delta Disk에 기록될 수 있습니다. 백업이 오래 걸리거나 VM 쓰기량이 많으면 Delta Disk도 커질 수 있습니다.

백업 데이터 전송이 끝난 뒤 VMware Snapshot을 제거할 때는 누적 변경 데이터를 통합해야 합니다. 이 과정에서 간헐적인 VM Stun이나 I/O 지연이 발생할 수 있습니다.

반면 Backup from Storage Snapshots를 사용하면 VMware Snapshot을 오래 유지하지 않아도 됩니다. 스토리지에서 시점이 고정된 복제본을 만든 뒤 원래 VM Snapshot을 바로 정리하고, 실제 백업 전송은 임시 Storage Snapshot을 통해 진행하기 때문입니다.

다만 Storage Snapshot도 같은 물리 스토리지 자원을 사용하는 경우가 많습니다. 따라서 프로덕션 스토리지의 I/O 영향이 완전히 0이 되는 것은 아닙니다. 정확하게는 VM Snapshot 유지 시간과 프로덕션 데이터 경로의 부담을 줄이는 설계입니다.

2. Backup from Storage Snapshots의 동작 순서

Veeam 공식 가이드는 기본 동작을 다음과 같이 설명합니다.

1. VBR이 대상 VM의 VMware Snapshot을 생성합니다.

2. VBR이 VM 디스크가 있는 Volume/LUN에 임시 Storage Snapshot 생성을 요청합니다.

3. Storage Snapshot이 생성되면 원본 VM의 VMware Snapshot을 제거합니다.

4. Backup Proxy가 Storage Snapshot에 접근해 필요한 VM 데이터를 읽습니다.

5. 데이터가 별도 Backup Repository에 저장됩니다.

6. 작업이 완료되면 임시 Storage Snapshot을 정리합니다.

Backup from Primary Storage Arrays 데이터 처리 흐름 — 출처: Veeam Help Center. 숫자는 공식 동작 단계를 나타냅니다.

여기서 VMware Snapshot을 빠르게 제거하는 것과 Backup Repository에 데이터를 저장하는 것은 별개의 단계입니다. Storage Snapshot은 작업 중 읽기 원본이고, 별도 Repository의 백업 파일이 장기 보존·독립 복구의 기반이 됩니다.

또한 Incremental Backup에서는 VMware CBT(Changed Block Tracking)가 유효한 경우 변경 블록만 읽을 수 있습니다. 단, CBT 상태와 스토리지 통합 방식에 따라 실제 읽기량이 달라질 수 있습니다.

3. 일반 백업, Storage Snapshot Backup, Snapshot-Only의 차이

이 세 가지를 구분하는 것이 중요합니다. 스토리지 장비 자체의 Snapshot만 보유하는 것은 독립적인 백업 사본을 확보한 것과 다릅니다. 스토리지 장비 전체가 손상되거나 접근할 수 없게 되면 Snapshot도 함께 영향을 받을 수 있기 때문입니다.

Backup from Storage Snapshots는 Snapshot의 속도를 이용하면서, 데이터는 별도 Backup Repository에 보관하는 방식입니다.

4. 적용 전에 확인할 구성요소

실제 사용하려면 다음 구성요소가 맞아야 합니다.

이 기능은 VMware vSphere 통합 기능입니다. Hyper-V나 Proxmox VM에 동일한 Job 옵션을 적용할 수 있다고 판단하면 안 됩니다. 다른 플랫폼에는 별도의 Snapshot/Backup 방식이 있습니다.

어떤 Storage Array가 지원될까요?

VBR 13 공식 문서의 Supported Storage Features for Backup and Orchestration에는 NetApp FAS/AFF/ASA, Dell Unity/PowerStore/PowerMax, HPE Alletra·Nimble·3PAR, IBM FlashSystem, Hitachi VSP, Everpure FlashArray 등 다양한 통합 스토리지가 안내됩니다.

다만 모델 이름만 같다고 바로 지원되는 것은 아닙니다. 지원되는 펌웨어, 프로토콜, 스토리지 플러그인 버전, Snapshot 기능이 모두 맞아야 합니다.

특히 스토리지마다 Backup from Storage Snapshots, Snapshot Orchestration, Secondary Array에서의 백업, Snapshot Immutability 지원 범위가 서로 다릅니다.

설계 전에 아래 공식 표에서 정확히 Backup from Storage Snapshots에 체크가 되어 있는지 확인하는 편이 안전합니다.

Veeam 공식 지원 스토리지 기능표

5. 스토리지 등록 및 Backup Proxy 구성

구성 순서는 단순히 Job의 옵션을 체크하는 것에서 끝나지 않습니다. VBR에 스토리지를 등록하고, Storage Snapshot을 실제로 읽을 수 있는 Proxy를 지정하는 것이 핵심입니다.

STEP 1. Storage System 등록

VBR Console에서 Storage Infrastructure로 이동한 뒤 Add Storage를 선택합니다.

1. 사용 중인 제조사 또는 Universal Storage API 통합 방식을 선택합니다.

2. Storage Management IP/FQDN을 지정합니다.

3. Snapshot 작업을 수행할 수 있는 계정 정보를 입력합니다.

4. 대상 Volume/LUN을 식별할 수 있는지 확인합니다.

5. Storage System과 연결할 Backup Proxy를 지정합니다.

6. Rescan 또는 Discovery 과정에서 Datastore/Volume 정보가 정상 조회되는지 확인합니다.

각 제조사의 Wizard는 서로 다릅니다. NetApp ONTAP과 Dell PowerStore, HPE 스토리지에서 요구하는 관리 API·자격 증명·플러그인이 동일하지 않으므로 공식 Storage Integration 문서를 함께 확인해야 합니다.

STEP 2. Proxy의 Snapshot 접근 경로 확인

Backup Proxy는 일반 Backup Job만 실행할 수 있으면 충분한 것이 아닙니다. 실제로 스토리지 Snapshot에 접근할 수 있어야 Backup from Storage Snapshots로 처리됩니다.

스토리지 프로토콜과 통합 방식에 따라 Direct SAN, NFS, NVMe-oF 등 지원되는 전송 경로가 달라집니다. 어떤 방식이든 해당 Storage Integration이 허용하는 Proxy와 Transport Mode여야 합니다.

이때 다음 항목을 점검합니다.

• Storage System 등록 과정에서 해당 Proxy가 허용된 Proxy 목록에 포함됐는지

• Proxy가 Snapshot LUN/Share에 실제로 접근 가능한지

• iSCSI/FC SAN 환경에서 ESXi 호스트용 Initiator Group과 Proxy용 Initiator Group이 안전하게 분리됐는지

• SAN의 Snapshot Clone이 실수로 프로덕션 ESXi 호스트에 노출되지 않도록 구성됐는지

• Array와 Proxy 간 네트워크·권한·Multipath 구성이 맞는지

스토리지 접근 주의: Veeam 공식 문서는 Storage Snapshot Clone이 운영 ESXi 호스트에 잘못 제공되면 프로덕션 인프라에 문제가 생길 수 있다고 경고합니다. Snapshot LUN 접근 권한과 SAN Initiator Group을 분리한 뒤 작업하는 것이 중요합니다.

STEP 3. Repository와 VM 위치 확인

Storage Snapshot은 백업의 읽기 원본이고 Repository는 백업의 저장 대상입니다.

예를 들어 VMware VM의 VMDK가 NetApp iSCSI Datastore에 있어도 실제 백업 파일은 별도 Linux Hardened Repository에 저장하도록 구성할 수 있습니다. Storage Array Snapshot이 Repository 역할까지 하는 것은 아닙니다.

또한 같은 VM에 여러 VMDK가 있고 일부만 지원 Storage에 위치한다면, Veeam은 그 VM 전체를 일반 백업 방식으로 처리할 수 있습니다. VM의 디스크들이 실제로 어느 Datastore에 있는지 확인하는 것이 좋습니다.

6. VMware Backup Job에서 Storage Snapshot 활성화

기본 인프라 구성이 끝났다면 Job 설정을 확인합니다.

1. VBR Console에서 Home → Backup Job → Virtual Machine → VMware로 새 Job을 생성하거나 기존 Job 속성을 엽니다.

2. 백업 대상 VM을 추가하고 Storage 단계로 이동합니다.

3. Repository 및 Retention 정책을 설정합니다.

4. Backup Proxy를 자동 선택 또는 Storage System에 등록한 Proxy로 지정합니다.

5. Advanced → Integration 탭을 선택합니다.

6. Enable backup from storage snapshots를 활성화합니다.

7. 필요하면 Limit processed VM count per storage snapshot to N을 설정합니다.

8. 정책에 따라 Failover to standard backup을 선택하고 Job을 저장합니다.

Veeam 13 문서에서는 새 Backup Job을 만들 때 Enable backup from storage snapshots가 기본적으로 활성화돼 있다고 안내합니다.

하지만 체크돼 있다는 사실만으로 Storage Snapshot 기반 백업이 실제로 실행됐다는 뜻은 아닙니다. 스토리지와 Proxy 연결이 적합하지 않으면 일반 방식으로 처리될 수 있습니다.

Veeam Backup Job의 Advanced Settings → Integration 화면 예시 — Veeam Community 자료의 이전 UI입니다. 현재 VBR 13과 메뉴 구성은 다를 수 있습니다.

Limit processed VM count per storage snapshot

동일한 Volume/LUN 위에 VM이 아주 많다면 한 번에 모든 VM을 처리하는 대신 VM 그룹마다 별도 임시 Storage Snapshot을 만드는 방식을 선택할 수 있습니다.

예를 들어 동일 Volume에 VM 30대가 있고 제한을 10대로 지정했다면, 10대씩 나눠 Snapshot을 준비하는 구성을 생각할 수 있습니다.

이는 VMware Snapshot을 유지하는 시간과 Array Snapshot 생성 시점, 각 Job의 병렬 작업 흐름에 영향을 줍니다. 최적의 값은 VM 수와 저장소 성능, 동시 작업 수에 따라 달라지므로 일률적으로 10을 권장하는 것은 아닙니다.

특히 Veeam은 동일 그룹 안에서 VM 우선순위를 유지하지만, 서로 다른 그룹은 병렬 처리되어 앞 그룹보다 뒤 그룹이 먼저 시작될 수 있다고 설명합니다. 중요한 VM의 실행 순서가 엄격하다면 별도 Job으로 나누는 편이 낫습니다.

Failover to standard backup

이 옵션을 켜두면 지원 스토리지에 문제가 있거나 Storage Snapshot을 만들지 못했을 때 일반 VMware 백업 방식으로 전환할 수 있습니다.

반대로 해당 기능을 활성화하지 않으면 Storage Snapshot 처리 실패로 Job 자체가 실패할 수 있습니다.

어떤 정책이 더 맞는지는 운영 기준에 달려 있습니다.

• 백업 성공 유지가 최우선이라면 일반 백업 Failover를 검토

• Snapshot Stun 방지가 매우 중요한 서비스라면 일반 백업으로 전환해도 되는지 사전 판단

• 장애 원인 확인이 중요한 테스트라면 Failover 사용 여부와 실제 처리 방식을 함께 기록

Failover가 성공하면 Job은 정상으로 보일 수 있으므로, 세션 로그를 확인하지 않으면 Storage Snapshot이 실제 사용됐는지 놓치기 쉽습니다.

7. Secondary Storage Array에서 백업하는 경우

일부 스토리지 구성에서는 운영 Array Snapshot을 다른 Secondary Array로 복제한 뒤, Secondary Array를 Backup Source로 사용할 수 있습니다.

대표적으로 지원 기능에는 NetApp SnapMirror/SnapVault, HPE 계열 Snapshot Replication, 일부 Dell PowerStore 및 IBM FlashSystem의 복제 기능 등이 있습니다. 지원 여부는 스토리지의 모델과 Veeam 버전별로 다릅니다.

Primary Storage Snapshot을 Secondary Storage로 복제해 백업 원본으로 사용하는 흐름 — 출처: Veeam Help Center 공식 개념도

Secondary Array 백업을 사용하려면 해당 Secondary Storage System도 VBR에 등록하고, 대상 Volume/LUN이 Rescan Scope에 포함돼야 합니다.

Job에서는 Configure secondary destinations for this job 및 Use as data source 같은 설정을 추가로 사용합니다. Secondary Snapshot 작업이 실패했을 때 Primary Snapshot 또는 Standard Backup으로의 Failover를 허용할지도 결정해야 합니다.

여기서 Secondary Array에 복제된 Snapshot 자체가 독립된 백업 Repository를 대체하는 것은 아닙니다. 최종 Backup File이 별도 Repository에 저장되는지와 해당 사본의 보존 정책을 분리해서 관리해야 합니다.

8. Direct SAN Access와 Backup from Storage Snapshots 차이

둘 다 VMware 백업에서 스토리지에 직접 접근할 수 있어 비슷해 보이지만 목적은 다릅니다.

Direct SAN Access는 Backup Proxy가 SAN을 통해 VM 데이터를 직접 읽는 Transport Mode입니다. 반면 Backup from Storage Snapshots는 백업 시점에 임시 Storage Snapshot을 만들어 읽기 원본으로 사용하는 Storage Integration 기능입니다.

Direct SAN이 설정돼 있다고 해서 Backup from Storage Snapshots가 자동으로 수행되는 것은 아닙니다. 반대로 Storage Snapshot 통합을 설정해도 Proxy가 해당 Snapshot을 읽지 못한다면 기대한 처리 방식으로 진행되지 않을 수 있습니다.

9. 운영에서 놓치기 쉬운 제한 사항

공식 문서는 다음 상황에서 Backup from Storage Snapshots를 사용할 수 없거나 제한된다고 안내합니다.

VMware 디스크 및 VM 구성

• vRDM 디스크: 해당 디스크는 Storage Snapshot 방식으로 처리되지 않고 건너뜁니다.

• VVol Datastore: Backup from Storage Snapshots를 지원하지 않습니다.

• VM Template: 이 방식으로 백업할 수 없습니다.

• Encrypted VM: 일반적인 암호화 VM에는 사용할 수 없습니다. 다만 vTPM이 포함됐다는 이유만으로 제외되는 것은 아닙니다.

• 지원/비지원 Storage에 VM 디스크가 혼재: 해당 VM 전체가 일반 백업 방식으로 처리될 수 있습니다.

NFS 기반 Storage Integration

NFS Storage System에 VM이 저장된 경우에는 다음 조건을 따로 확인해야 합니다.

• VM에 이미 VMware Snapshot이 존재하면 일반 Backup으로 처리될 수 있습니다.

• Windows VM에서 VMware Tools Quiescence를 활성화한 일부 조건에는 Storage Snapshot 방식이 사용되지 않을 수 있습니다.

• 제조사와 Integration에 따라 지원되는 Proxy와 Transport 경로가 달라집니다.

기존 VMware Snapshot이 있다고 해서 모든 Snapshot을 강제로 삭제해도 된다는 뜻은 아닙니다. 백업·복제·애플리케이션이 사용하는 Snapshot인지 먼저 확인한 뒤 정리해야 합니다.

임시 Snapshot 공간과 정리

Storage Snapshot은 생성 직후 공간 소비가 작더라도 원본 Volume의 변경량이 늘어나면 사용량이 증가할 수 있습니다.

Job 실행 전후에는 Array의 Snapshot 용량과 Free Space를 확인합니다. 특히 Job 실패 또는 강제 중단 후 임시 Storage Snapshot이 그대로 남아 있는지 살펴봐야 합니다.

문제가 의심돼도 Array에서 Snapshot을 곧바로 수동 삭제하는 것은 위험할 수 있습니다. 먼저 VBR Job 및 Storage Integration의 참조 상태를 확인하고 공식 정리 절차를 따르는 것이 좋습니다.

10. Storage Snapshot 방식이 실제 사용됐는지 검증

설정 이후에는 Backup Job을 실제 실행하고 결과를 확인해야 합니다.

Backup Job 세션 로그

VBR Console의 History / Job Session에서 대상 VM의 상세 기록을 살펴봅니다.

• Storage Snapshot 생성 과정이 실행됐는지

• VMware Snapshot이 Storage Snapshot 생성 후 빠르게 제거됐는지

• 어떤 Backup Proxy와 Transport 경로가 사용됐는지

• 일반 백업 모드로 Failover한 메시지가 있는지

• 최종 백업 파일이 Repository에 정상 저장됐는지

• 실패·경고가 없고 임시 Storage Snapshot이 정리됐는지

Backup Job이 Success로 종료됐다는 사실만으로 Storage Snapshot 방식이 실제로 사용됐다고 판단하면 안 됩니다. Failover to standard backup이 허용된 경우 일반 방식으로 작업이 끝났을 수도 있습니다.

Storage Array 이벤트와 Snapshot 목록

Array 관리 화면에서 Backup Job 실행 시각과 일치하는 Snapshot 생성·삭제 이력을 확인합니다. 같은 Volume/LUN 위의 여러 VM이 하나의 Storage Snapshot 그룹으로 처리됐는지, Job 이후 불필요한 임시 Snapshot이 남아 있지 않은지도 보면 좋겠습니다.

VMware Snapshot 유지 시간 비교

이 표에는 임의의 성능 개선 수치를 넣지 않았습니다. 얼마나 단축되는지는 실제 워크로드와 스토리지·네트워크 상태에 따라 달라지기 때문입니다.

복구 테스트까지 확인

Backup Repository의 Restore Point에서 File-Level Recovery나 격리된 VM Restore를 수행해봅니다.

VMware Snapshot을 짧게 유지하는 것은 백업 부하를 줄이기 위한 방법이지 복구 가능성 자체를 보장하지는 않습니다. Restore Point 존재와 실제 복구 결과를 함께 확인하는 것이 좋습니다.

11. 일반 백업으로 전환되거나 오류가 발생한다면

Job은 정상인데 Storage Snapshot 처리가 수행되지 않았거나 관련 경고가 나타나면 다음 순서로 확인합니다.

1. 지원 스토리지: VBR 13 Storage Feature 지원표와 Firmware/Plug-in 버전을 대조합니다.

2. VM 디스크 위치: 모든 백업 대상 VMDK가 지원 Datastore에 있는지 확인합니다.

3. Proxy 매핑: Job의 Proxy가 Storage System 연결 설정에 허용된 Proxy인지 확인합니다.

4. Transport: Proxy에서 Snapshot Volume에 접근할 수 있는 경로와 권한이 있는지 확인합니다.

5. Storage 계정: Snapshot 생성·삭제 API 권한, 자격 증명 만료 여부를 확인합니다.

6. 스토리지 공간: Snapshot Capacity와 기존 Snapshot 개수를 확인합니다.

7. Failover 정책: Job Integration의 일반 백업 전환 여부를 확인합니다.

8. VMware Snapshot: 기존 Snapshot이나 Consolidation 경고, NFS 예외를 확인합니다.

실제 SAN에서는 네트워크가 연결돼 있어도 Initiator Group 또는 Snapshot Clone 매핑이 잘못돼 Proxy에 Volume이 마운트되지 않을 수 있습니다. 연결 문제를 방화벽 Port만의 문제로 단정하지 않는 것이 좋겠습니다.

12. 운영 적용 전 최종 체크리스트

• ☐

  VBR Build, Storage 모델, Firmware 및 Plug-in이 지원 매트릭스에 맞는지

• ☐

  Snapshot 생성·삭제 권한이 있는 Storage 계정을 확보했는지

• ☐

  Proxy가 해당 Storage Snapshot에 접근할 수 있는지

• ☐

  SAN Initiator Group과 운영 ESXi 호스트의 Snapshot Clone 접근 범위를 분리했는지

• ☐

  임시 Snapshot용 Array 여유 공간이 충분한지

• ☐

  vRDM, VVol, Encrypted VM 및 NFS 제한을 확인했는지

• ☐

  Job의 Enable backup from storage snapshots가 활성화됐는지

• ☐

  VM 그룹당 Storage Snapshot 제한값의 필요 여부를 검토했는지

• ☐

  Failover to standard backup 운영 정책을 결정했는지

• ☐

  세션 로그에서 실제 Storage Snapshot 경로로 처리됐는지

• ☐

  Job 종료 후 임시 Snapshot 정리 여부를 확인했는지

• ☐

  Repository Restore Point로 테스트 복구를 수행했는지

정리

Veeam의 Backup from Storage Snapshots는 VMware Snapshot을 아예 사용하지 않는 기능이 아닙니다. VM Snapshot으로 시점을 확보한 뒤 Storage Snapshot을 생성하고, VMware Snapshot을 빠르게 제거한 다음 백업 데이터를 스토리지 쪽에서 읽는 방식입니다.

이 구조 덕분에 VM Snapshot 유지 시간이 줄어들고 Delta Disk 증가와 Consolidation 지연을 줄일 수 있습니다. 특히 쓰기량이 높은 업무 VM의 백업 영향을 완화하는 데 도움이 될 수 있습니다.

다만 지원 Array와 Proxy 접근 경로, Job 실행 로그가 무엇보다 중요합니다. 설정 화면에서 체크돼 있더라도 실제로 Snapshot 기반 백업이 수행됐는지까지 확인해야겠습니다.

공식 참고자료

• Veeam Blog — Backup from Storage Snapshots: How It Works and When to Use It (2026-11-05)

• Veeam Help Center — Backup from Storage Snapshots

• Veeam Help Center — Configuring Backup from Storage Snapshots

• Veeam Help Center — Backup from Primary Storage Arrays

• Veeam Help Center — Supported Storage Features

• Veeam Help Center — General Requirements and Limitations

• Veeam Help Center — Direct SAN Access

• Veeam Help Center — Configuring Backup from Secondary Storage Arrays

작성 기준: 2026년 11월 9일 · 공식 Veeam Blog 및 VBR 13.1.2 User Guide 기준. 본문 이미지는 공식 문서·Veeam Community의 설명용 자료이며 특정 운영 환경에서 직접 수행한 테스트 화면이 아닙니다. 실제 지원 여부는 사용 중인 VBR과 Storage Firmware/Plug-in의 지원 매트릭스를 확인해야 합니다.