Veeam NFS File Share 백업 구성 가이드 - 공유 등록부터 Instant Recovery까지

Veeam에서 NFS 공유 폴더를 보호하려면 먼저 File Share를 백업 대상에 등록하고, 그다음 File Backup Job을 만들어야 합니다. 이번에는 직접 구성했던 NFS 테스트 환경을 기준으로 공유 경로 등록 → Proxy/Cache Repository 설정 → 백업 Job 생성 → 백업 결과 확인 → Instant File Share Recovery까지 순서대로 정리했습니다.

처음 설정할 때 가장 헷갈리는 부분은 'NFS 공유를 백업한다'는 것과 'NFS 공유를 백업 저장소로 사용한다'는 것이 서로 다른 설정이라는 점입니다. 여기서는 NFS 공유 폴더에 있는 파일과 디렉터리를 보호하는 NAS/File Share Backup을 다룹니다.

환경과 버전 구분: 화면 및 결과는 2025년 4월의 기존 Windows Console 기반 테스트 기록입니다. 당시 설치된 Veeam 정확한 빌드 번호와 NFS 서버 OS는 기록에 명시돼 있지 않습니다. 메뉴 설명·NFS 지원 버전·복구 제약 등은 현재 Veeam Backup & Replication 13.1.1.18 공식 가이드 기준으로 함께 설명합니다. 따라서 현재 Veeam 13에서 화면 배치가 완전히 같다고 단정하지 않습니다.

1. 먼저 백업 구성과 동작 방식 이해하기

Veeam의 File Share Backup은 일반 VM 이미지 백업과 처리 방식이 다릅니다. VM 디스크 블록 전체가 아니라 NFS 공유의 파일과 폴더 목록, 파일 버전, 데이터 변경 사항을 관리합니다.

Backup Proxy가 공유 데이터를 읽고 Cache Repository를 거쳐 Backup Repository에 저장하는 구조

기본 데이터 흐름은 다음과 같습니다.

1. 백업 세션이 시작되면 Veeam이 대상 파일 공유를 처리할 Backup Proxy를 배정합니다.

2. Proxy가 NFS 공유 내 파일·폴더를 열거하고 CRC 트리를 작성합니다.

3. CRC 트리를 Cache Repository에 전달해 이전 백업 세션의 트리와 비교합니다.

4. 변경된 파일이나 폴더에 대해 필요한 데이터를 읽고 Backup Repository에 저장합니다.

5. Repository에는 64MB 크기의 데이터 파일과 파일 이름·버전·데이터 할당 관계를 관리하는 메타데이터가 저장됩니다.

6. 보존 정책에 따라 오래된 버전을 삭제하거나, 별도 Archive Repository가 있다면 해당 정책에 맞춰 이동합니다.

CRC 트리는 변경 사항을 판단하는 데 활용되지만, CRC 트리 비교만으로 모든 데이터 무결성이 보장된다는 뜻은 아닙니다. 백업 세션과 Repository의 Health Check, 실제 복구 테스트도 함께 확인해야 합니다.

1-1. 각 구성요소가 맡는 역할

• NFS File Share: 원본 데이터가 저장된 NFS 공유 경로입니다.

• Backup Proxy: NFS의 파일과 폴더를 열거하고 백업 데이터를 읽어 전송합니다.

• Cache Repository: CRC 트리와 변경 추적용 임시 메타데이터를 저장합니다. 운영 환경에서는 Proxy와 네트워크상 가까운 저장소를 고려합니다.

• Backup Repository: 실제 백업 데이터와 복구에 필요한 메타데이터를 보관합니다.

• Archive Repository (선택): 오래된 파일 버전을 장기간 별도 저장하는 데 사용합니다.

여기서 Cache Repository와 Backup Repository는 이름이 비슷해도 용도가 다릅니다. 원본 NFS를 등록하는 단계에서 Cache를 선택하고, Job 생성 단계에서 실제 백업 저장소를 별도로 지정합니다.

2. 테스트 환경과 사전 확인

테스트 화면의 사설 IP와 서버 이름은 예시입니다. 실제 환경에서는 자신의 NFS Export 경로로 대체해야 합니다. NFS 서버 OS, 네트워크 대역, 제품의 정확한 Build는 이번 기록으로 확정할 수 없습니다.

현재 Veeam 13 문서 기준으로 NFS 3 및 4.1 공유를 지원하며 pNFS는 지원하지 않습니다. Proxy에서 Export에 접근할 수 있어야 하고, 파일 권한 복구가 필요하다면 root_squash 설정도 미리 검토해야 합니다.

Linux에서 NFS 서버의 Export를 미리 확인하려면 다음 명령을 참고할 수 있습니다. 아래 명령은 운영 사전점검용 예시로, 이번 테스트 기록에서 실제로 실행된 명령은 아닙니다.

# NFSv3 export 조회 기능이 활성화된 서버에서 사용
showmount -e 172.22.3.118

# 필요한 경우 읽기 전용으로 공유 마운트 테스트
sudo mkdir -p /mnt/nfs-check
sudo mount -t nfs -o ro,vers=4.1 172.22.3.118:/nfs_share /mnt/nfs-check
findmnt /mnt/nfs-check
sudo umount /mnt/nfs-check

showmount는 NFSv4 전용으로 구성된 서버에서 응답하지 않을 수 있습니다. 이때 명령 실패만으로 백업이 불가능하다고 판단하지 말고, NFS 버전·Export·방화벽·Proxy 접근 권한을 각각 확인합니다.

3. Veeam에 NFS File Share 등록하기

3-1. Inventory에서 파일 공유 추가

기존 콘솔에서는 Inventory → Unstructured Data → Add untrusted data source → File share 순서로 진행했습니다.

Inventory의 Unstructured Data에서 신규 데이터 소스 추가

데이터 소스 유형에서 File share 선택

Veeam 13 콘솔에서는 Inventory → File Shares → Add File Share → NFS share 흐름을 확인할 수 있습니다. 기존 화면과 명칭이 다르더라도 'NFS 공유를 원본 소스로 추가한다'는 목적은 동일합니다.

3-2. NFS Share와 Export 경로 입력

NFS share를 선택한 후 백업할 서버와 공유 경로를 입력합니다.

NFS share 유형 선택

NFS 공유 경로 입력

이번 테스트 입력값은 다음과 같습니다.

172.22.3.118:/nfs_share

Veeam이 요구하는 NFS Share 경로는 일반적으로 server:/folder 형식입니다. Linux 호스트의 로컬 디렉터리(/nfs_share)와 Veeam이 접속할 NFS Export 경로(172.22.3.118:/nfs_share)를 구분해서 입력합니다.

최신 Veeam에서는 스토리지에서 이미 제공하는 Snapshot 경로를 백업 원본으로 활용하는 옵션도 제공됩니다. 다만 Veeam File Backup Job 자체가 해당 스토리지 Snapshot을 자동 생성·삭제한다는 의미는 아니므로 별도 스토리지 기능과 스크립트 정책을 검토해야 합니다.

3-3. Backup Proxy, Cache Repository, I/O Control 설정

다음 단계에서는 실제 데이터를 처리하는 Backup Proxy와 변경 추적 메타데이터가 저장될 Cache Repository를 설정합니다.

Backup Proxy 및 Cache Repository 설정과 I/O Control 슬라이더

NFS 공유 등록 Apply 진행 화면

이번 테스트에서는 Proxy를 All proxies로, Cache를 Default Backup Repository로 선택했습니다. Backup I/O Control은 백업 속도를 높일지, 원본 NFS 시스템에 가해지는 부하를 줄일지 조절하는 항목입니다.

• 백업 시간 단축이 우선이라면 Proxy 수와 병렬 처리를 확장할 수 있습니다.

• 업무 시간에 NAS 부하를 줄여야 한다면 Lower impact 방향을 고려합니다.

• Cache Repository는 메타데이터 접근이 빈번하므로 성능과 배치를 점검합니다.

Veeam 13 공식 가이드에서는 Proxy 장애에 대비해 2개 이상의 Backup Proxy 선택을 권장하고, I/O Control의 단계별 병렬 스레드 수도 안내하고 있습니다. 무조건 Faster Backup을 선택하기보다 NAS I/O와 네트워크 부하를 함께 보고 조정하는 것이 좋습니다.

3-4. 등록 완료 확인

설정을 적용하고 Summary에서 Finish를 누릅니다.

NFS 공유 설정 Summary 및 Finish

Inventory에서 등록된 172.22.3.118 NFS 공유 확인

Inventory의 File Shares 목록에 원본 NFS 공유가 보이면 등록 단계가 끝난 것입니다. 여기까지는 백업 원본 등록 성공이며, 파일 데이터의 백업을 완료한 것은 아닙니다.

4. NFS File Backup Job 생성하기

4-1. 백업 대상 파일과 폴더 준비

테스트 당시 NFS 공유에는 B, c, d, e, Test_Server, Test_Client 등의 폴더와 1GFile.txt, 200GBFile.txt, 4GBFile.txt 등 테스트 파일을 만들어 두었습니다.

NFS 공유의 테스트용 대용량 파일과 디렉터리 목록

테스트 파일은 크기와 실제 데이터 패턴이 다를 수 있으므로 파일의 표시 크기만 보고 백업 데이터 전송량이나 압축률을 예측해서는 안 됩니다.

4-2. NFS 공유에서 신규 Job 만들기

등록된 NFS 공유를 우클릭한 뒤 Add to backup job → New Job을 선택합니다. Job 이름은 테스트 목적을 알 수 있도록 TEST_NFS로 지정했습니다.

NFS File Share에서 Add to backup job 선택

새 File Backup Job에 TEST_NFS 이름 지정

현재 Veeam 13의 File Backup Job도 NFS 또는 SMB 공유를 백업하는 Job이라는 큰 흐름은 같습니다. 버전에 따라 마법사 UI의 화면 배치나 버튼 이름이 달라질 수 있습니다.

4-3. Objects와 Backup Repository

Objects에서는 백업할 NFS 공유를 선택합니다. 이어서 Backup Repository에서 백업 데이터를 저장할 실제 Repository와 보존 기간을 지정합니다.

Objects에서 보호할 NFS 공유 선택

Backup Repository와 보존 기간, Advanced 진입

원본 화면에는 Keep all versions for the last 28 days와 같은 보존 기간 예시가 보입니다. 이것은 테스트 화면에 입력된 설정이지 모든 운영 환경의 권장 보존 기간을 뜻하지 않습니다. 업무 RPO/RTO, 랜섬웨어 복구 시점, 저장소 용량에 맞춰 결정해야 합니다.

4-4. Advanced - 파일 버전과 ACL 처리

File versions에서는 보관할 파일 버전 수와 정책을 설정합니다. 화면에는 모든 버전을 유지하거나, 아카이브된 버전 수를 제한하거나, 최근/아카이브 버전의 개수를 함께 제한하는 선택지가 보입니다.

File versions 보존 방식과 제한 옵션

ACL Handling에서는 파일과 폴더의 권한·속성을 어디까지 백업할지 정합니다.

ACL Handling의 Folder-level only와 Files and folders 옵션

• Folder-level only: 폴더 권한과 속성 위주로 백업하며 복원된 파일은 대상 폴더 권한을 상속받는 방식입니다.

• Files and folders: 각 파일의 권한·속성까지 포함해 백업하는 대신 백업 성능이 떨어질 수 있습니다.

파일 단위 ACL이 중요한 환경에서는 편의상 Folder-level only를 유지하지 말고 복구 후 권한 요구사항을 확인해야 합니다. 또한 Veeam 문서에서는 기존 Job의 ACL 처리 방식을 변경한 경우 다음 세션에서 Full Backup이 생성될 수 있다고 안내합니다.

4-5. Advanced - Storage, Maintenance, Scripts, Notifications

Storage에서는 압축 레벨과 백업 파일 암호화 옵션을 지정합니다. 테스트 캡처에서는 Optimal (recommended) 압축 레벨이 표시됩니다.

Storage 설정의 압축 레벨과 백업 파일 암호화

Maintenance의 Health Check는 백업 데이터 손상을 탐지하고 점검하는 기능입니다. 운영 환경에서는 Job 수행 시간과 Repository 부하를 고려해 주기를 잡는 것이 좋습니다.

Maintenance에서 Backup Files Health Check 구성

Scripts에서는 Job 실행 전후 실행 스크립트를 지정할 수 있습니다. 스토리지 Snapshot을 별도로 관리해야 하거나 사용자 정의 작업이 필요한 경우 활용할 수 있지만, 스크립트 실패 시 처리 정책까지 함께 검토해야 합니다.

Job 실행 전후 스크립트 설정

Notifications에서 이메일과 SNMP 등 알림 설정을 검토할 수 있습니다. 작업이 성공하더라도 일부 파일이 Skip됐는지 세부 로그를 함께 확인하는 것이 좋습니다.

작업 결과에 대한 알림 및 경고 설정

4-6. Archive Repository와 실행 스케줄

Archive Repository는 장기 보관용 선택 항목입니다. Archive를 구성하지 않아도 기본 Backup Repository에 지정한 보존 정책으로 File Backup Job을 운영할 수 있습니다.

선택 사항인 Archive Repository 단계

Schedule에서는 수동 실행 또는 주기적 자동 실행을 선택합니다. 처음 등록하는 공유라면 한 번 수동으로 실행해 Proxy의 읽기 권한과 Job 결과를 확인한 다음 정기 스케줄을 적용하는 것도 방법입니다.

NFS File Backup Job 실행 스케줄 지정

5. 실제 백업 실행과 결과 확인

Job 생성 후 TEST_NFS를 시작했습니다. 작업 목록에 Starting 상태가 표시되는 것을 확인할 수 있습니다.

TEST_NFS File Backup Job의 Starting 상태

최종 실행 결과 화면에서는 백업된 파일 4개, 폴더 7개로 정리돼 있습니다. 화면의 높은 압축률이 999x로 표시됐지만, 이는 테스트용 대용량 파일에 실제 데이터가 거의 없거나 반복되는 패턴이 많았기 때문일 가능성이 있습니다.

NFS 백업 Job 완료 세션 및 처리 통계

따라서 이 결과를 일반적인 사내 파일 서버의 예상 압축률로 사용하면 안 됩니다. 화면의 Bottleneck이 Source 쪽으로 표시된 부분도 원본 디스크 I/O 병목 가능성을 시사할 뿐, 별도 계측 없이 디스크 성능이 원인이라고 확정할 수는 없습니다.

운영 환경에서는 최소한 Job Success 여부 외에도 Read/Transferred 데이터량, Processing Rate, Backup I/O Control, Warning/Skipped 파일, Repository 용량을 함께 확인합니다.

6. Instant File Share Recovery로 복구하기

이번 테스트에서 실제 수행하고 파일까지 확인한 복구는 Instant File Share Recovery입니다. 백업 시점을 선택한 뒤 파일 공유 형태로 빠르게 게시해 접근하는 방식입니다.

중요한 점은 NFS 원본을 복원하더라도, Instant Recovery 게시 경로는 SMB 공유로 제공될 수 있다는 점입니다. 최신 Veeam 13 공식 문서에서도 NFS 공유에 대한 Instant Recovery는 복구 시점의 데이터를 읽기 전용(Read-only) 으로 제공한다고 설명합니다.

6-1. 복구 마법사와 복구 시점 선택

Home → Backups에서 NFS 백업을 선택하고 Instant file share recovery를 실행합니다. 기존 테스트 자료에서는 Disk (Orphaned) 하위의 복구 지점에서 실행했습니다. 일반 운영 환경에서는 실제 백업이 존재하는 노드에서 수행해야 하며 Orphaned 표시가 반드시 필요하지는 않습니다.

백업 복구 지점에서 Instant file share recovery 선택

Instant Recovery Wizard의 복구 대상 및 Point 선택

원하는 Restore Point를 선택합니다.

특정 날짜/시간의 Restore Point 선택

6-2. SMB로 게시된 공유 확인

복구 세션의 로그에는 마운트와 게시 절차가 진행됐고, 최종적으로 File Share 게시가 성공했다는 메시지가 남아 있습니다.

Instant File Share Recovery 세션의 게시 성공 로그

Veeam Instant Recovery 목록에서 Mount 상태 확인

기존 테스트에서는 복구가 게시된 Windows 호스트의 \\WIN-7RQ50KJCVQ9\nfs_share 형태로 접근했습니다. 이 UNC 경로는 원본 NFS 경로가 아니라 임시로 게시된 SMB 복구 공유입니다. 원본과 게시 대상의 프로토콜을 혼동하지 않는 것이 중요합니다.

6-3. Linux에서 복구 파일을 확인한 결과

Linux 클라이언트에서는 CIFS 방식으로 복구된 SMB 공유를 마운트했고, 복구한 테스트 파일과 폴더가 보이는 것을 확인했습니다.

Linux에서 복구된 SMB 공유를 CIFS로 마운트

복구된 공유 내 대용량 파일 및 폴더 목록 확인

다음은 운영 환경에서 적용 형태를 보여주는 참고용 명령어입니다. 기존 화면의 실제 명령을 그대로 재현한 것이 아니며, 호스트 이름과 계정을 환경에 맞게 변경해야 합니다.

sudo mkdir -p /mnt/nfs-restore
sudo mount -t cifs //RECOVERY_HOST/nfs_share /mnt/nfs-restore \
  -o ro,vers=3.0,username=RECOVERY_USER
ls -alh /mnt/nfs-restore
sudo umount /mnt/nfs-restore

NFS 백업에 대한 Instant Recovery는 복구 데이터 확인을 위한 읽기 전용 게시입니다. 원본 NFS 서버의 운영 공유를 바로 대체하는 영구적 복원으로 해석하지 말고, 복구 완료 후 적절히 게시를 중지해야 합니다.

7. 다른 복구 방식은 어떻게 다를까?

백업 복구 메뉴에는 Instant Recovery 외에도 복구 범위에 따라 다음 선택지가 있습니다.

기존 기록에는 Entire File Share 복구의 실제 완료 결과가 포함되지 않습니다. 따라서 이 항목들까지 성공했다고 작성하지 않았습니다. 운영 환경에서는 별도 Restore Test로 덮어쓰기, 권한, 파일 잠금, 복구 대상 경로를 확인해야 합니다.

8. 운영 환경에서 주의할 사항

8-1. NFS 프로토콜과 권한

최신 Veeam 13 기준 지원 NFS 버전은 3과 4.1이며 pNFS는 지원 대상이 아닙니다. Proxy가 Export를 읽을 수 있는지, 방화벽 및 NFS 서버 접근 제어가 올바른지 확인합니다. 원본 NFS의 소유권·권한을 복원해야 한다면 Veeam 문서에서 안내하는 root squash 비활성화 조건이 복원 작업에 주는 영향도 검토해야 합니다. 운영 보안 정책과 충돌하지 않도록 복원 전용 경로 또는 일시적인 설정 변경 절차를 준비하는 편이 안전합니다.

8-2. 압축률보다 실제 복원 가능성을 먼저 확인

테스트 파일의 999x 비율은 원본 파일의 내용이 없거나 반복되는 데이터일 때도 나타날 수 있습니다. 운영 기준으로 삼아야 할 지표는 평균 전송량, 변경률, Repository 증가량, Job 소요 시간 그리고 실제 파일 복구 가능 여부입니다.

8-3. Cache Repository와 원본 NAS의 부하

파일과 디렉터리 수가 많은 공유는 최초 열거와 CRC 트리 처리에 시간이 걸릴 수 있습니다. Cache 저장소의 성능이 낮거나 네트워크 경로가 길면 백업 효율이 저하될 수 있습니다. I/O Control 역시 동일한 NAS에서 서비스 중인 다른 워크로드에 영향을 주므로 초기 운영에는 보수적인 값으로 시작해 조정하는 것이 좋습니다.

8-4. 보존 정책과 삭제된 파일

파일 공유 백업은 파일의 변경과 삭제 이력, 보존 기간, 장기 보관 여부가 서로 연관됩니다. '28일' 설정 하나만 보고 특정 파일 버전이 어느 시점까지 남는다고 단순화하지 말고, File versions·Archive 정책과 실제 Restore Point를 같이 확인해야 합니다.

8-5. 랜섬웨어 대응과 별도 복구 경로

원본 NAS 안에만 데이터를 두거나, 동일한 접근 권한에만 의존하는 구성은 장애·랜섬웨어에 취약할 수 있습니다. 별도 저장소 보호, 백업 복사본, Immutable Repository 가능 여부, 계정 분리, 정기적인 복구 리허설을 함께 설계하는 것이 좋습니다. 다만 NFS 원본 등록만으로 Immutable Backup이 자동 적용되지는 않습니다.

9. 정리

이번 구성에서는 NFS 공유 등록 → File Backup Job 생성 → 파일 4개와 폴더 7개의 백업 결과 확인 → 특정 복구 시점의 SMB 공유 게시 → Linux에서 복구 파일 접근까지 진행했습니다.

특히 기억할 사항은 세 가지입니다. 첫째, NFS 백업 Source와 NFS Backup Repository는 서로 다른 설정입니다. 둘째, Proxy와 Cache Repository가 원본 변경 파일을 찾고 전송하는 데 중요한 역할을 합니다. 셋째, NFS Instant Recovery는 복구 시점 데이터를 SMB 경로로 읽기 전용 게시하는 방식이라 원본 공유를 바로 교체하는 복원과 구분해야 합니다.

기존 테스트 기록에서 확인되지 않은 Entire File Share와 Rollback의 성공 여부는 별도 복구 테스트가 필요합니다. 현재 환경에서는 Veeam 13.1.1.18 제품 문서와 실제 빌드를 대조하면서 적용하면 됩니다.

공식 참고자료

• Veeam 13 - Adding NFS File Share

• Veeam 13 - Specify NFS File Share Settings

• Veeam 13 - File Share Processing Settings

• Veeam 13 - How Unstructured Data Backup Works

• Veeam 13 - Unstructured Data Support

• Veeam 13 - Instant File Share Recovery

• Veeam 13 - File Share Data Recovery