Veeam 저장소 용량 계산기 사용 가이드 - Repository Sizing부터 GFS·Immutable·SOBR까지

Veeam 백업 환경을 설계할 때 Repository 용량을 어떻게 잡아야 하는지 고민할 때가 많습니다. VM의 Used Space가 20TB라고 해서 백업 저장소를 20TB로 만들면 되는 것은 아닙니다. 매일 변경되는 데이터, 복구 지점 수, GFS 장기 보존, Synthetic Full, Immutable 기간, 향후 증가량까지 고려해야 하기 때문입니다.

이럴 때 활용하기 좋은 도구가 Veeam에서 제공하는 공식 Calculators입니다. 이번에는 기본 Calculator로 저장소 용량을 빠르게 계산하고, 여러 워크로드나 사이트가 있는 경우 Scenario Builder로 확장하는 방법까지 정리해보겠습니다.

• Veeam Calculators 공식 메인

• VM / Agent 백업 저장소 계산기 바로가기

• Veeam Repository Storage Best Practice Guide

핵심: 계산기의 결과는 필요한 저장소 용량을 추정한 값입니다. 실제 운영 용량은 데이터 변경률, 백업 체인, Data Reduction, Immutability, GFS, Working Space, 향후 증가량에 따라 달라집니다. 최종 구축 수량을 확정하기 전에 실제 Backup Job 통계와 공식 Best Practice Guide를 함께 확인하는 편이 좋습니다.

1. 어떤 계산기를 사용해야 할까요?

Veeam Calculators에는 여러 도구가 있습니다.

앞서 정리한 **Veeam Port Mapper 가이드**와 이번 계산기는 용도가 다릅니다. Port Mapper가 구성요소 간 통신을 보는 도구라면, Calculator는 Backup Repository의 저장소·일부 컴퓨팅 자원 규모를 추정하는 데 사용합니다.

오래된 calculator.veeam.com 또는 veeambp.com 계산기는 현재 공식 계산기의 계산 방식과 다를 수 있습니다. Veeam 커뮤니티의 Calculator 담당자는 이전 계산기는 더 이상 유지보수되지 않으므로 veeam.com/calculators의 최신 계산기를 사용하도록 안내하고 있습니다.

2. 계산 전에 필요한 정보

계산기부터 열기보다 아래 수치를 먼저 모으면 입력이 한결 쉬워집니다.

여기서 Source Data는 Datastore의 Provisioned 용량이 아니라 실제 보호할 데이터 크기를 기준으로 잡는 것이 중요합니다. 이미 스토리지 장비에서 압축·중복 제거된 물리 사용량을 그대로 입력하면 원본 데이터 규모를 작게 잡게 될 수 있습니다. Veeam Best Practice Guide도 스토리지의 자체 절감률을 반영한 숫자만으로 계산하지 않도록 권고합니다.

3. 공식 Calculator 화면에서 VM Backup 선택

1. Veeam Calculators에 접속합니다.

2. Calculator를 선택합니다.

3. Data Center → Machines → VM Backup을 선택합니다.

4. Agent 기반 백업을 산정한다면 Agent Backup으로 변경합니다.

5. 오른쪽에서 설정할 데이터와 정책을 확인합니다.

UI는 계산기 버전에 따라 달라질 수 있습니다. 다음 이미지는 Veeam Community에 공개된 VM Backup Calculator 실제 화면 예시입니다. 예시의 1TB 및 14일 설정은 화면 설명용이며, 아래에서 제시할 20TB 가상 사례와는 별개입니다.

Veeam 공식 Calculator의 Data Source·Policy·Advanced·Results 화면 예시 — 출처: Veeam Community (과거 버전 예시)

STEP 1. Data Source 입력

Source Data에 백업할 전체 Used Data 크기를 입력합니다. 예를 들어 VM 40대에서 백업 대상 Used Space가 합계 20TB라면 20TB를 입력합니다.

Daily Change Rate에는 하루 변경률을 설정합니다. 4%를 선택했다면 단순히 하루 약 0.8TB의 원본 블록이 변경된다고 가정하는 것입니다.

같은 VM 40대라도 파일 서버와 DB 서버가 섞여 있다면 변경률이 다를 수 있습니다. 파일 서버는 변경량이 적더라도 DB 또는 로그가 많은 서버의 변경률은 높을 수 있으므로, 가능하면 워크로드 유형별로 나누는 편이 좋습니다. 일반적인 환경에서는 2~5%가 자주 활용되지만, DB 서버는 10% 이상을 가정해야 할 수도 있습니다.

STEP 2. Protection Policy 선택

Backup Window는 백업 작업을 끝내야 하는 시간입니다. 8시간 백업 창으로 설정하면 해당 시간 안에 데이터를 처리할 수 있도록 필요한 처리 성능을 추정하는 데 영향을 줍니다.

ReFS / XFS는 Fast Clone(블록 복제)과 관련됩니다. 이를 사용하면 Synthetic Full이나 GFS Restore Point 생성 시 같은 데이터 블록을 여러 번 물리적으로 저장하지 않아도 되는 구성이 가능합니다. 단순히 '모든 데이터가 무조건 절반으로 줄어든다'는 의미는 아닙니다.

Direct to Object Storage와 Capacity Tier도 구분해야 합니다.

• Direct to Object Storage: Object Storage를 직접 백업 대상으로 사용하는 구조

• Capacity Tier: SOBR의 Performance Tier와 연결해 Object Storage에 Copy/Move하는 구조

둘은 같은 '클라우드 저장소'라도 백업 체인과 보존 정책이 다를 수 있어, 계산기에서 혼동하면 산정 결과가 달라집니다.

Enable Immutability를 사용하는 경우 보존 기간도 입력합니다. 특히 Object Storage의 Object Lock 또는 Hardened Repository에서는 보존 만료가 실제 파일 정리 시점과 정확히 같지 않을 수 있으므로, 설정한 Restore Point 보존 기간과 Immutability 기간을 따로 확인하는 것이 좋습니다.

4. Retention과 GFS 설정하기

Repository 용량에 가장 큰 영향을 주는 항목 중 하나가 얼마나 많은 복구 지점을 유지할 것인가입니다.

계산기에서 Daily, Weekly, Monthly, Yearly 보존 값을 설정할 수 있는 항목이 표시되면 운영 정책에 맞게 입력합니다.

여기서 'Daily 30개'와 '30일 동안 항상 30개 파일'은 다릅니다. Veeam의 백업 체인에는 Full과 Incremental이 들어가고, Job 스케줄 및 정책에 따라 실제 Restore Point와 Backup File 수가 달라질 수 있습니다.

GFS 역시 단순히 'Weekly 4개니까 Full Backup 파일 4개를 추가로 저장'한다고 계산하면 정확하지 않습니다. ReFS/XFS Fast Clone이 사용되는 경우 Synthetic Full과 GFS의 공유 블록 처리 방식이 저장 공간에 영향을 줍니다.

GFS를 사용할 때: Daily 보존 값만 놓고 결과를 판단하지 말고 Weekly·Monthly·Yearly 정책까지 입력한 뒤 Details / Restore Point Simulator를 확인하는 편이 좋습니다. 장기 보존 시점마다 어떤 데이터가 유지되는지 함께 봐야 합니다.

5. Advanced에서 성장률과 압축률 입력

간단한 산정이라면 기본값으로 시작할 수 있지만, 실제 고객 구축이나 장기 운영 용량을 잡는다면 Advanced 항목을 확인하는 것이 좋습니다.

Forecast Period / Growth Rate

Forecast Period는 몇 년 뒤까지의 저장소를 예상할 것인지, Growth Rate는 보호할 원본 데이터가 매년 얼마나 증가할 것으로 보는지 지정하는 항목입니다.

예를 들어 현재 보호할 데이터가 20TB이고, 연간 10% 증가하며, 3년 뒤까지 계획한다고 하면 데이터 크기는 개념적으로 다음처럼 증가합니다.

Year 0: 20.00 TB
Year 1: 22.00 TB
Year 2: 24.20 TB
Year 3: 26.62 TB

위 값은 연 10% 복리 증가를 단순 적용한 원본 데이터 규모 예시입니다. Veeam 계산기의 결과 수치가 26.62TB가 된다는 뜻은 아닙니다. 실제 Repository 요구 용량은 증가한 데이터가 기존 Full·Incremental·GFS 체인에 어떻게 반영되는지까지 고려해야 합니다.

Compress by: Compression / Data Reduction

Compress by 항목은 압축 및 중복 제거에 의해 원본 대비 저장 공간을 얼마나 절감할지를 가정하는 설정입니다.

• 50% 절감: 원본 20TB를 약 10TB로 줄인다고 가정

• 60% 절감: 원본 20TB를 약 8TB로 줄인다고 가정

• 2:1 Data Reduction: 원본의 약 절반 크기, 즉 50% 절감에 해당

여기서 이미 스토리지 Array에서 중복 제거된 물리 사용량을 Source Data로 입력하고 또 Veeam Data Reduction을 크게 잡으면, 절감 효과를 이중 계산할 위험이 있습니다.

영상·암호화 데이터·이미 압축된 파일이 많은 환경과 일반 업무 파일 환경은 절감률이 다를 수 있습니다. 실제 Job 이력이 있다면 과거 Backup Session의 Data Reduction 통계를 참고하되, 신규 환경이라면 보수적으로 설정하는 편이 안전합니다.

6. 실무 예시: VM 데이터 20TB라면?

다음과 같이 가상의 고객 구축 환경을 가정해보겠습니다.

개념을 이해하기 위한 단순 계산

최초 Full과 이후 Incremental이 차지하는 공간을 아주 단순하게 계산하면 다음과 같습니다.

초기 Full(절감 후)
= 20 TB × (1 - 0.50) = 10 TB

하루 변경 데이터(절감 후)
= 20 TB × 0.04 × (1 - 0.50) = 0.40 TB

Full 1개 + Incremental 29개를 단순 합산
= 10 TB + (0.40 TB × 29)
= 21.60 TB

21.60TB는 계산기의 실제 산출 결과가 아닙니다. Full 1개와 Incremental 29개라는 매우 단순한 구조를 전제로, 데이터 절감률도 매일 동일하다고 가정한 개념 설명용 숫자입니다.

실제 Veeam Repository에는 백업 체인의 유지 방식, Synthetic Full 생성·Merge, Metadata, 파일시스템, 작업 공간, GFS, Immutability 등의 요인이 추가됩니다. 따라서 스토리지 발주 용량을 21.60TB로 확정하면 안 됩니다.

계산기를 이용해 비교하는 순서

1. 위의 20TB·4%·30개·50% 조건을 입력하고 ESTIMATE를 실행합니다.

2. Results의 Repository 용량과 Proxy 요구사항을 기록합니다.

3. Details를 열어 백업 체인과 Working Space를 확인합니다.

4. ReFS/XFS 설정을 해제한 뒤 다시 계산하여 차이를 비교합니다.

5. Weekly 4, Monthly 12 등 실제 GFS 정책을 추가해 결과를 비교합니다.

6. Immutability를 적용하고 보존 기간을 입력한 뒤 결과를 비교합니다.

7. 마지막으로 Growth와 Forecast Period를 반영해 최종 예상치를 확인합니다.

이렇게 한 번에 값을 다 넣기보다 한 항목씩 바꾸면서 결과가 어떻게 변하는지 보면, 운영 정책의 어떤 부분이 저장소 용량을 늘리는지 파악하기 쉽습니다.

주의: 아래에 표시한 과거 Calculator 화면의 수치는 해당 이미지 작성자가 설정한 별도 조건에서 나온 예시입니다. 여기서 설명한 20TB 구성의 실행 결과가 아니며, 현재 Calculator 버전에 그대로 적용된다는 뜻도 아닙니다.

7. Results 카드와 Details를 함께 봐야 합니다

ESTIMATE를 실행하면 우측의 결과 카드에 저장소 용량과 일부 Proxy CPU/RAM 요구량이 표시됩니다. 그러나 카드에 나온 용량만 보고 설계를 끝내지 않는 것이 좋습니다.

특히 SOBR의 Capacity Tier나 Archive Tier를 활성화하면 요약 카드에서 보이는 숫자가 전부가 아닐 수 있습니다. Details에서는 다음 내용을 확인합니다.

• Repository가 요구하는 총 저장 공간

• 필요 시 Performance Tier와 Capacity/Archive Tier별 공간

• Backup Chain 및 Restore Point 구성

• Working Space, 보존 정책 및 Immutability로 인한 추가 요구량

• 해당 워크로드의 처리 시간·컴퓨팅 요구사항

Veeam Calculator 담당자의 안내에 따르면 Results의 Storage Required와 Restore Point 시뮬레이터에 보이는 데이터 합계는 다를 수 있습니다. 실제 필요 공간에는 Working Space와 저장소 Immutable 관련 여유분 등이 포함될 수 있기 때문입니다.

예를 들어 Restore Point 시뮬레이터에 보이는 용량을 모두 더했는데 결과 카드의 Repository 값이 더 크다고 해서, 그 차이를 곧바로 계산 오류로 판단할 수는 없습니다.

아래는 공식 Veeam Community에 공유된 Calculator의 NAS Result Detail 예시 화면입니다. 입력 조건과 기능이 VM Backup과는 다르지만, Repository뿐 아니라 Proxy·Cache Repository·Compute 요구사항이 함께 표시될 수 있다는 점을 보여줍니다.

Veeam Calculator의 NAS Result Detail 화면 예시 — 출처: Veeam Community. 표시된 용량은 해당 게시글 작성자의 별도 NAS 구성 결과입니다.

8. 여러 저장소를 산정한다면 Scenario Builder

VM Backup 하나를 빠르게 계산하는 경우라면 기본 Calculator가 편합니다. 하지만 다음처럼 구성요소가 많아지면 결과를 통합 관리하기가 어려워집니다.

• 본사·DR센터 등 여러 사이트를 운영

• VMware VM, Windows/Linux Agent, NAS Backup이 혼재

• 업무별 Daily Change Rate와 GFS 정책이 서로 다름

• Linux Hardened Repository와 Object Storage를 함께 사용

• Backup Copy와 Capacity Tier, Archive Tier가 각각 필요

• 향후 3년 증설 계획까지 포함해야 함

이런 상황에서는 Veeam Scenario Builder로 이동해 사이트와 워크로드를 나눠 입력하는 편이 좋습니다.

STEP 1. Scenario 생성 및 사이트 정의

계산기 메인에서 Scenario Builder를 선택합니다. Scenario 이름을 지정한 다음 필요한 Site를 추가합니다.

예를 들어 다음처럼 구분할 수 있습니다.

Scenario Builder는 사이트별 연결, 워크로드, 저장소 계층을 설정해 통합 요구량을 보여주는 도구입니다. 단일 Calculator에서 여러 결과를 머릿속으로 더하는 방식보다 설계 누락을 줄이기 좋습니다.

STEP 2. Workload 등록

각 사이트에서 보호할 워크로드 유형을 추가합니다. 예를 들어 VM Backup, Agent Backup, NAS Backup을 별도 Workload로 등록하고 Source Data, Change Rate, Backup Window, Retention, Compression 등 해당 범주의 입력값을 지정합니다.

서버별 정책이 다르다면 단순히 Used Capacity만 더해서 하나의 Workload로 합치지 않는 편이 좋습니다. 예를 들어 DB 서버의 변경률이 10%이고 일반 업무 VM이 2%라면 각각 별도로 계산할 때 차이를 더 정확하게 볼 수 있습니다.

STEP 3. Universal Import 활용

Veeam Calculators 1.5에서는 Universal Import 기능이 추가됐습니다.

• XLSX: Scenario 전체 입력 데이터를 수집하고 가져올 때

• CSV: 개별 Workload의 입력 데이터를 수집할 때

• 템플릿 생성 후 별도 Excel 작업이나 스크립트로 데이터를 채우고 다시 Import

예를 들어 고객사가 VM 수백 대의 정보와 부서별 보존 정책을 전달해야 한다면 XLSX 템플릿을 활용할 수 있습니다. Import할 때 기존 Workload 데이터가 업데이트될 수도 있으므로 어떤 범위를 덮어쓸지 확인해야 합니다.

아래는 실제 Veeam Community에 공개된 Scenario Builder의 Workload Detail 예시입니다. 보호 데이터 크기, 변경률, 보존 기간, Immutability, 성장률 등을 워크로드별로 확인하는 형태를 보여줍니다.

Scenario Builder의 NAS Workload Detail 예시 — 출처: Veeam Community. 화면 속 수치는 해당 게시글의 별도 NAS 시나리오이며 실제 운영 측정값이 아닙니다.

STEP 4. 사이트별 결과 및 저장소 계층 확인

설계가 완료되면 Results와 상세 항목에서 워크로드별 Repository 용량과 사이트별 네트워크·컴퓨팅 자원 요구량을 살펴봅니다.

Performance Tier, Capacity Tier, Archive Tier는 목적이 다릅니다. 실제 정책에서 Copy, Move, 장기 보존이 어떻게 적용되는지 확인한 뒤 각각의 용량을 판단해야 합니다. 같은 데이터가 둘 이상의 Tier에 함께 존재할 수 있으므로, 한 곳의 용량만 보고 전체 백업 저장소를 산정하면 부족할 수 있습니다.

공식 Calculator 팀은 Scenario Builder가 Repository마다 디스크 또는 Storage Tier별 결과를 표시할 수 있다고 안내합니다. 그러므로 여러 Tier를 운영한다면 기본 Calculator 요약 카드보다 Scenario Builder의 상세 결과를 우선 검토하는 편이 좋습니다.

STEP 5. 저장 및 내보내기

Scenario Builder의 입력 내용은 브라우저 로컬 캐시에 저장될 수 있습니다. 브라우저 캐시를 정리하거나 환경을 변경하면 작업 내용이 손실될 수 있으므로, 시나리오를 구성한 뒤 주기적으로 Export해 별도 보관하는 것이 좋습니다.

9. NAS·M365·Object Storage는 따로 계산해야 합니다

NAS / File Share

NAS 백업은 일반 VM Backup과 저장 형식 및 보존 방식이 다릅니다. Primary Repository, Secondary Copy Repository, Archive Repository의 역할을 나누고, 파일 변경률 외에도 파일 수, Metadata, Cache, Working Space를 고려해야 합니다.

따라서 VM Used Data 20TB와 NAS 데이터 20TB를 동일한 입력값으로 계산해 같은 크기의 Repository가 필요하다고 해석하면 안 됩니다. NAS Backup을 사용한다면 Calculator의 Unstructured Data / NAS 관련 항목을 선택하고, NAS Backup Repository 공식 Best Practice Guide도 함께 확인해야 합니다.

2026년 10월 Calculator 1.7 계열에서는 NAS 산정 로직의 변경과 표시 오류 수정에 관한 공식 커뮤니티 논의도 있었습니다. 같은 입력값인데 예전 Calculator와 결과가 크게 다르다면, 사이트의 현재 버전과 변경 사항, 결과 카드와 Details의 일치 여부를 확인하는 것이 안전합니다.

Microsoft 365

Veeam Backup for Microsoft 365는 Exchange Mailbox, OneDrive, SharePoint, Teams 등의 데이터 유형과 Retention 구조가 VBR VM Backup과 다릅니다.

Microsoft 365 저장소가 필요하다면 VBR의 VM Backup Calculator 대신 SaaS / Microsoft 365 관련 계산기 또는 해당 제품 Best Practice Guide를 사용하는 것이 좋습니다.

Object Storage / Veeam Data Cloud Vault

Cloud Object Storage는 저장 용량뿐 아니라 API 요청, 데이터 보존 기간, Immutability, Restore 시 Egress 등 비용 구조가 다릅니다. 필요한 GB/TB만 계산해서 월 비용을 확정하면 안 됩니다.

특히 Direct to Object Storage와 SOBR Capacity Tier, Archive Tier는 Object 단위와 작업 방식이 다를 수 있습니다. 계산기가 제공하는 API 호출량 등의 추정치를 참고하되, 실제 비용은 Cloud Provider의 지역·스토리지 클래스·계약 단가 기준으로 따로 산정해야 합니다.

10. Repository 발주 전에 추가로 확인할 사항

용량 계산 결과를 확보했더라도 바로 스토리지 발주 수량으로 사용하지 않는 편이 좋습니다.

① 실제 사용 가능한 용량으로 환산

스토리지 장비가 제공하는 Raw Capacity와 파일시스템에서 사용할 수 있는 Usable Capacity는 다릅니다. RAID 또는 Erasure Coding, 파일시스템과 Metadata, 예약 공간이 존재합니다.

계산기에서 요구한 Repository 용량은 장비 Raw Capacity와 같은 뜻이 아닙니다. 스토리지 공급업체가 보장하는 실제 Usable Capacity를 기준으로 대조해야 합니다.

② 일시적인 Full Backup과 여유 공간

Job 재구성, Backup Chain 이동, Active Full 실행, Merge/Transform 과정에 추가 공간이 필요할 수 있습니다. Veeam Best Practice Guide는 별도 Full Backup이나 향후 증가량을 위한 여유 공간을 고려하도록 안내합니다.

또한 Health Check와 복구 테스트는 저장소의 Read I/O 및 동시 처리 성능에 영향을 주므로 용량만으로 성능 적합성을 판단하면 안 됩니다.

③ Immutable 보존 기간과 작업 기간

Immutable 기간과 Backup Retention 기간이 완전히 동일한 의미는 아닙니다. 특히 Object Storage에서 보존 기간과 Block Generation 때문에 물리적으로 데이터를 지울 수 있는 시점이 더 늦어질 수 있습니다.

새로 Immutable 설정을 적용한다면 기존 Backup Chain의 수명, Retire 작업 및 정책 변경 시점까지 고려해서 Calculator를 다시 실행하는 편이 좋습니다.

④ 3-2-1 계열 백업 정책과 Backup Copy

Primary Repository에서 30일 동안 보존하고 DR센터로 90일 Backup Copy를 수행한다면, Primary와 Secondary를 동일 용량으로 단순 계산하면 안 됩니다. 두 저장소의 Retention과 GFS, Immutability 조건을 각각 적용해 계산해야 합니다.

⑤ 실제 백업 Job 통계와 비교

이미 Veeam을 운영 중이라면 신규 Calculator 결과보다 신뢰할 수 있는 실제 데이터가 있습니다. 기존 Full Backup 파일 크기, Incremental 평균, Daily Change Rate, Data Reduction, Active Full 시점, Repository Free Space를 확인합니다.

실측과 Calculator 결과가 크게 다르다면 어떤 설정이 달랐는지 먼저 살펴보고, 합리적인 근거가 있다면 입력값을 보수적으로 조정합니다.

운영 체크리스트

• ☐

  실제 백업할 Used Data와 이미 압축된 스토리지 사용량을 구분했습니다.

• ☐

  VM/Agent, NAS, Microsoft 365 등의 워크로드를 구분했습니다.

• ☐

  Daily Change Rate와 실제 Retention/GFS 정책을 입력했습니다.

• ☐

  ReFS/XFS Fast Clone 사용 여부를 확인했습니다.

• ☐

  Direct to Object와 Capacity Tier Copy/Move 정책을 구분했습니다.

• ☐

  Immutability 및 Forecast/Growth 가정을 기록했습니다.

• ☐

  Results뿐 아니라 Details와 Restore Point Simulator도 확인했습니다.

• ☐

  NAS Cache, Object API 비용 등 별도 요구량을 점검했습니다.

• ☐

  Raw Capacity와 실제 Usable Capacity를 구분했습니다.

• ☐

  Backup Copy와 DR Repository를 별도 계산했습니다.

• ☐

  계산기 버전, 산정 일자, 사용한 입력값을 설계 문서에 보관했습니다.

정리

Veeam Repository를 설계할 때 필요한 것은 단순히 '백업 데이터가 몇 TB인가'가 아니라, 그 데이터를 얼마 동안, 어떤 방식으로, 어느 저장소에 보관할 것인지입니다.

간단한 VM/Agent 백업 규모는 Calculator로 빠르게 가늠하고, 여러 워크로드나 사이트, GFS·SOBR·Backup Copy 정책이 들어간 설계는 Scenario Builder를 활용하면 좋겠습니다.

계산기를 여러 번 실행해 Retention, 변경률, Data Reduction, Immutability 조건을 하나씩 바꾸어 비교하는 방식이 실제 저장소 설계에 큰 도움이 됩니다. 다만 최종 장비 용량과 성능은 계산 결과 외에 실제 데이터·스토리지 특성·운영 여유 공간까지 함께 판단해야 합니다.

공식 참고자료

• Veeam Calculators — 공식 메인

• Veeam VM/Agent Backup Capacity Calculator

• Veeam Repository Storage — Best Practice Guide

• Veeam Data Gathering — Best Practice Guide

• Veeam NAS Backup Repository Sizing — Best Practice Guide

• Veeam Calculators Update — 공식 Calculator 소개

• Calculators 1.5 — Universal Import / Scenario Builder

• Veeam Calculator Results / Details에 관한 운영 설명

• Veeam Calculators v1.7 NAS 입력·산정 관련 Q&A

정리 기준: 2026년 11월 5일. 본문 이미지와 설명용 수치는 서로 다른 공식 커뮤니티 예시이며, 사용 중인 계산기의 버전·구성에 따라 화면 및 추정 결과는 달라질 수 있습니다.