광고
테스트 환경: Veeam Backup & Replication 12.2, VMware vSphere, Windows Server 2016, Ubuntu 22.04.5 LTS. 아래 작업 화면은 해당 버전에서 진행한 VM 백업 및 복구와 Windows/Linux Agent 백업·복구 과정을 보여줍니다.
이번에는 Veeam Backup & Replication 12.2 환경에서 VMware VM 이미지 백업부터 복원, Windows와 Linux Agent 백업 및 복구까지 진행했던 과정을 정리했습니다. 단순히 Job 생성 화면만 소개하는 것이 아니라 VM 전체 복원 / Instant Recovery / Agent Volume Restore / File-Level Restore까지 실제 작업 순서로 묶었습니다.
1. 실습 환경과 버전
실습 구성도: 백업 서버 및 Windows·Linux 대상
Veeam Backup & Replication Console 설치 시작
Veeam Console 설치 요구사항 확인
Console 설치 진행 및 완료
Veeam Console 서버 연결
VBR: Veeam Backup & Replication 12.2, Windows Console
백업 서버: Windows Server 2016, VBR 1대
네트워크: 172.22.3.0/24 사설 테스트 구간
가상화: VMware vCenter로 등록한 ESXi 호스트와 VM, 복구 예제에 Rocky Linux 64-bit VM 등장
Windows Agent: Windows Server 2016, 테스트 IP 172.22.3.15
Linux Agent: Ubuntu 22.04.5 LTS, 테스트 IP 172.22.3.17
Backup Repository: Default Backup Repository
테스트 화면 기록 시기: 2025년 2월 전후
여기서 설명하는 메뉴는 VBR 12.2에서 직접 사용했던 화면입니다. 현재 VBR 13.x와 동일하다고 볼 수는 없으니 실제 운영할 때는 설치 빌드, OS 지원 목록, 커널 및 방화벽 정책을 따로 확인해 주세요.
VBR Console 설치와 연결
Veeam 설치 ISO를 탑재한 뒤 관리자 권한으로 설치 프로그램을 실행합니다. Veeam Backup & Replication Console 설치 항목을 선택하고 라이선스 동의, 시스템 구성 확인, 설치 완료까지 진행했습니다. 이후 백업 서버의 Console 접속 화면에서 서버 주소와 포트 9392를 입력해 연결했습니다. 이 과정에서 캡처한 것은 Console 설치 과정이며 VBR 서버의 모든 구성요소를 처음부터 설치하는 절차와 구분해야 합니다.
2. VM 이미지 백업의 데이터 흐름과 파일 형식
Veeam Data Platform 구성요소
VM 백업 데이터 흐름 및 Proxy 동작
Veeam 이미지 백업 구조
VBR / Proxy / Repository
백업 서버는 백업 Job과 스케줄을 제어하고, VMware Backup Proxy는 VM 데이터 블록을 읽어 Repository로 전송합니다. VMware 데이터 전송 방식에는 SAN, HotAdd, Network(NBD) 방식이 있습니다. VMware 스냅샷은 일관된 VM 시점의 데이터를 읽기 위한 과정 중 하나이며, 스냅샷 자체가 장기 보관용 백업 파일은 아닙니다.
백업 체인 이해하기
Forever Forward Incremental(FFI): 첫 Full Backup
.vbk뒤에 증분.vib가 누적되고 보존 기간에 따라 체인이 변환됩니다.Forward Incremental(FI): Full과 증분을 기반으로 구성하며 Synthetic Full 또는 Active Full을 주기적으로 추가할 수 있습니다.
Reverse Incremental(RI): 최신 복구 지점을 Full
.vbk로 유지하고 이전 복구 시점에는.vrb역증분을 사용합니다.
이 세 개는 백업 방식 비교를 위해 함께 정리한 개념입니다. 실제 백업 Job 화면에서는 Incremental을 선택한 부분을 확인할 수 있으나 세 방식 모두 별도로 테스트했다고 볼 수는 없습니다.
3. VMware vCenter와 Agent Protection Group 등록
vCenter 등록 메뉴
vCenter 등록 성공 화면
Agent Protection Group 추가
Windows 서버 보호 그룹 대상 지정
Windows 관리 계정 연결 테스트
Windows Protection Group의 Agent 설정
Windows Agent 원격 배포 완료
Windows Agent 서비스 상태 확인
Linux SSH 접속 계정 추가
Linux Guest Credentials Test
Linux Agent 및 구성요소 배포 로그
Ubuntu Agent Installed / Online 확인
vCenter 등록
Inventory → Virtual Infrastructure → Add Server → VMware vSphere를 선택합니다.
vCenter 주소나 DNS 이름을 입력합니다.
Credential Manager에서 등록된 관리 계정을 선택하거나 새로 추가합니다.
연결 테스트 후 마법사를 완료합니다.
Inventory에 vCenter, ESXi, VM 목록이 나타나는지 확인합니다.
vCenter가 목록에 보이더라도 VM 스냅샷 권한, 변경 블록 추적(CBT), 저장소 접근 및 Proxy 경로가 적합한지 추가로 점검하는 것이 좋습니다.
Windows Agent Protection Group
Physical Infrastructure → Add Protection Group에서 개별 컴퓨터를 추가합니다.
Windows 서버
172.22.3.15의 관리 계정을 지정합니다.Guest Credentials Test에서 Success를 확인합니다.
Agent 및 관리 서비스 설치를 진행합니다.
화면에 Windows Agent의 Installed / Online 상태가 표시되는지 확인합니다.
대상 서버 내부에서는 Veeam Agent for Microsoft Windows, Veeam Data Mover Service, Veeam Installer Service가 실행 중인 화면까지 확인했습니다.
Linux Agent Protection Group
Linux 테스트 대상 172.22.3.17에는 SSH 자격 증명을 등록했습니다. Guest Credentials Test가 성공한 뒤 Transport 구성요소, Linux 커널 모듈 관련 패키지와 Agent가 배포되는 로그를 확인했습니다. Inventory에 Ubuntu 22.04.5 LTS, Agent Installed, 대상 Online으로 표시됐습니다.
Ubuntu 내부에서도 아래와 유사한 방식으로 Veeam 프로세스를 확인할 수 있습니다. 명령어는 추가 점검 예시입니다.
ps aux | grep '[v]eeam'Linux 커널이 업그레이드되었다면 Snapshot 모듈, Secure Boot, DKMS/kmod, 지원 파일시스템 조건을 다시 확인해야 합니다.
4. VMware VM 백업 Job 만들기
VM Backup Job 생성
백업할 VM 지정
VM Backup Repository 선택
VM Job Advanced 설정
VM 백업 스케줄 및 Summary
VM 복구 지점 생성 확인
Home → Job → Backup → Virtual machine으로 새 Job을 시작합니다.
Name에서 구분 가능한 Job 이름을 입력합니다.
Virtual Machines 단계에서 백업할 VM을 추가합니다.
Storage에서 Repository와 보존할 복구 지점을 설정합니다.
Advanced에서 Incremental, Synthetic/Active Full 설정을 확인합니다.
Guest Processing에서 필요한 경우 Application-aware processing 또는 Guest File System Indexing을 설정합니다.
Schedule을 확인하고 Summary에서 최종 설정을 점검합니다.
Job 실행 후 세션 로그와 VM의 Restore Point 생성 여부를 확인합니다.
백업 세션의 성공은 복구 가능성 검증의 시작입니다. 실제로 VM을 복구할 수 있는지도 이어서 확인했습니다.
광고
5. Entire VM Restore — 전체 가상머신 복원
Restore from backup 선택
Entire VM Restore 복구 방식
VM Restore Point 선택
복구 가상머신 대상 지정
Entire VM Restore 복원 위치 선택
복원 가상머신 이름·네트워크 설정
VMware 인벤토리 복원 VM 확인
복원된 가상머신 상태
복원 작업
Home → Restore → VMware vSphere → Restore from backup → Entire VM restore로 들어갑니다.
백업 VM과 복구 시점을 선택합니다.
실습에서는 원본 덮어쓰기 대신 Restore to a new location / with different settings를 선택했습니다.
복구 대상 Host, Resource Pool, Datastore를 선택합니다.
복구 VM의 이름, 폴더, 디스크 형식과 네트워크 매핑을 확인합니다.
Summary 확인 후 복원을 실행합니다.
복구 로그에서 Success가 표시됐고, 이후 VMware 인벤토리에 별도 이름으로 생성된 VM까지 확인했습니다. 다만 응용 프로그램 서비스까지 모두 정상이라는 뜻은 아닙니다.
운영 팁: 원본 VM과 동일한 네트워크/IP를 사용하는 복구본은 충돌할 수 있으므로, 운영에서 전체 복원을 시험할 경우 격리된 네트워크를 사용하고 필요한 사전 승인을 받는 편이 안전합니다.
6. Instant Recovery — 백업 파일에서 VM 먼저 기동하기
Instant Recovery 메뉴
Instant Recovery 마법사
복구할 VM 및 Restore Point
복구할 VM 위치·이름
Host·Datastore 및 Network
Instant Recovery 실행 세션
Migrate to production / Stop publishing
Entire VM Restore가 백업 이미지를 프로덕션 저장소로 복구하는 방식이라면, Instant Recovery는 백업 저장소 데이터를 이용해 먼저 VM을 기동하는 방식입니다.
Restore 메뉴에서 Instant recovery → Instant recovery to VMware vSphere를 시작합니다.
VM과 Restore Point를 선택합니다.
새 위치를 사용하는 경우 Host, VM 이름, Datastore, 네트워크 등을 지정합니다.
Summary에서 설정을 확인하고 복구를 시작합니다.
세션 로그에서 임시 저장소 게시 및 VM 등록 진행 상태를 확인합니다.
VMware 인벤토리에서 복구된 VM을 확인합니다.
화면에는 Instant Recovery(1) 세션과 복구된 VM이 나타납니다. 이후에는 Migrate to production으로 운영 Datastore에 데이터를 옮기거나, 검증만 수행했다면 Stop publishing으로 세션을 종료합니다.
중요한 점은 Instant Recovery가 켜졌다는 것과 최종 복구가 완전히 마무리된 것은 다르다는 것입니다. 운영 전환 후 백업 저장소 의존이 해제됐는지도 확인해야 합니다.
7. Windows Agent 백업 Job 생성
Windows Agent 백업 Job 생성
Windows Agent Job Mode
Windows Entire computer 백업 범위
Windows Agent Guest Processing
VSS 및 백업 스케줄
Windows Agent 백업 실행
Windows Agent 백업 완료
Windows Agent Restore Point 확인
등록된 Windows 컴퓨터에서 Add to backup job → New job을 선택합니다.
Server / Managed by backup server를 선택해 중앙 관리 방식으로 진행합니다.
백업할 Windows 서버를 Computers 단계에서 지정합니다.
Backup Mode에서는 Entire computer를 선택했습니다.
Storage에서 Default Backup Repository와 Retention을 지정합니다.
Guest Processing에서 Application-aware processing, VSS 및 데이터베이스 로그 처리 조건을 확인합니다.
Schedule을 적용하고 Job을 실행합니다.
세션에는 VSS 처리, 디스크 읽기, 백업 파일 작성과 Full backup created / Processing finished 로그가 기록됐고, Windows Agent 백업의 Restore Point를 확인했습니다.
여기서 Application-aware 옵션이 보였다는 것과 SQL 등 특정 DB의 애플리케이션 정합성이 모두 확인됐다는 것은 별개의 사실입니다. 실제 DB 환경에서는 VSS Writer, 로그 처리 결과, DB 복구 테스트가 필요합니다.
8. Windows Agent — Volume Restore
Windows Volume Restore 시작
복구할 Windows 서버 선택
Volume Restore Point 확인
원본 디스크와 대상 디스크 매핑
기존 파티션 및 비할당 공간
Recovery 파티션 복원 설정
Windows Recovery Volume Restore 진행
Volume Restore 성공 로그
디스크 관리에서 복구 결과 확인
Windows 볼륨 복구는 대상 디스크를 수정하므로 Disk Mapping 단계에서 특히 주의해야 합니다.
Restore → Agent → Disk restore → Volume restore를 선택합니다.
백업 컴퓨터와 Restore Point를 지정합니다.
복구 대상 컴퓨터를 선택합니다.
Disk Mapping에서 백업 원본 파티션과 대상 디스크를 비교합니다.
새 디스크/비할당 공간의 용량과 파티션 배치를 확인하고 복구를 실행합니다.
복원 완료 로그를 확인한 뒤 Windows 디스크 관리에서 실제 결과를 확인합니다.
이번 화면의 정확한 복구 범위: 테스트 화면에는 원본 및 대상 90GB 디스크와 Recovery 파티션(약 450MB) 매핑이 나타납니다. 실제 복구 완료를 확인할 수 있는 대상은 이 Recovery 파티션입니다. 이를 E: 데이터 볼륨 전체 복원이나 완전한 BMR 복원 성공 증빙으로 해석해서는 안 됩니다.
운영 환경에서는 복구 대상에 기존 데이터가 있는지 확인한 뒤 매핑을 확정해야 하며, 실수로 파티션을 제거하면 기존 데이터가 손실될 수 있습니다.
9. Windows Agent — File Restore
Windows File Restore 실행
백업 파일 브라우저에서 복원 대상 선택
복구할 파일·폴더 선택
파일 복원 성공 로그
Windows Explorer 파일 확인
Windows Agent 백업에서 Restore guest files → Microsoft Windows를 선택합니다.
Restore Point를 지정합니다.
Veeam Backup Browser에서 복구할 파일 또는 폴더를 찾습니다.
Restore / Restore to / Copy to 가운데 목적에 맞는 동작을 선택합니다.
로그에서 Restore completed successfully를 확인합니다.
실제 Windows 파일 탐색기에서 파일 또는 폴더가 복원됐는지 확인합니다.
실습에서는 복구 로그가 성공으로 종료됐고 Windows Explorer에 복원 폴더가 표시됐습니다. 기존 운영 파일을 덮어쓰는 것보다는 먼저 별도 경로에 복구한 뒤 차이를 비교하는 편이 안전합니다.
10. Linux Agent 백업 Job 생성
Linux 컴퓨터 선택
Linux Entire computer 및 Backup Repository
Linux Guest Processing 및 Schedule
Linux Agent 백업 진행 세션
Linux 백업 완료 결과
Linux Agent Restore Point 확인
Protection Group에 등록된 Ubuntu 서버를 대상으로 진행했습니다.
Linux 대상을 선택하고 Add to backup job → Linux → New job을 선택합니다.
Server / Managed by backup server로 설정합니다.
Computers에서 Ubuntu 대상을 지정합니다.
Backup Mode에서는 Entire computer를 선택합니다.
Repository와 보존 정책을 설정합니다.
Guest Processing 및 Schedule을 확인합니다.
Job을 실행해 세션 결과와 Restore Point를 확인합니다.
이번 환경에서는 Linux 백업 세션이 완료되고 Default Backup Repository에 Restore Point 1개가 생성된 화면을 확인했습니다.
11. Linux — Veeam Recovery Media를 이용한 볼륨 복원
Veeam Linux Recovery Media 부팅
Recovery Media 라이선스 및 Volume Restore
VBR 서버 연결
복원할 Ubuntu Backup Restore Point
Linux Volume Restore 진행
복구 후 재부팅
Recovery Media 복원 완료 확인
Ubuntu 시스템 재부팅 및 로그인
OS가 정상 부팅되지 않는 상황까지 고려하면, Linux는 Veeam Recovery Media를 이용한 복구 흐름을 익혀두는 것이 좋습니다.
대상 컴퓨터를 Veeam Recovery Media로 부팅합니다.
필요 시 라이선스·서드파티 구성요소 조건을 승인합니다.
메인 메뉴에서 Restore volumes를 선택합니다.
백업 파일 위치에서 Add VBR server로 Veeam Backup Server에 연결합니다.
복구할 백업과 Restore Point를 지정합니다.
원본 및 대상 디스크·파티션을 비교하고 복원할 위치를 지정합니다.
복원 후 Reboot를 실행합니다.
실습에서는 복원 작업 뒤 Ubuntu 로그인 화면을 확인했고, VMware 환경에서 대상 VM의 구성이 보이는 화면까지 기록했습니다. 이것은 시스템이 다시 부팅되는 지점까지의 확인이며, 모든 Linux 서비스와 애플리케이션의 정상 동작을 보증하는 테스트는 아닙니다.
운영 시에는 UEFI/BIOS 방식, 부트로더 GRUB, EFI 파티션, RAID/LVM, 파일시스템 지원 여부를 확인해야 합니다.
12. Linux Agent — File Restore
Linux File Restore 시작
Linux Helper Host 선택
Linux File-Level Restore Browser
Linux 파일 복원 성공 로그
Ubuntu 디렉터리 복구 결과 확인
Linux의 특정 파일을 복구할 때는 Restore guest files → Linux and other를 선택합니다.
백업 컴퓨터와 Restore Point를 지정합니다.
Linux 파일시스템을 탐색할 Helper Host를 선택합니다.
File Level Restore Browser에서 복구할 파일과 디렉터리를 찾습니다.
원본 위치 또는 별도 경로로 Restore/Copy합니다.
작업 로그와 Linux 디렉터리를 확인합니다.
복원 결과 화면에는 Success 1 / Errors 0으로 표시됐으며 복구 후 Linux 터미널에서 디렉터리 내용을 확인한 기록이 있습니다. Linux에서는 파일 내용뿐 아니라 소유자, 접근 권한, SELinux Context 등이 필요한 환경인지도 같이 확인하면 좋습니다.
운영 점검용 명령어 예시는 아래와 같습니다. 실습에서 전부 실행했다는 의미는 아닙니다.
uname -r
lsblk -f
findmnt
ls -l13. 운영 환경의 추가 확인사항
VM 백업: vCenter·ESXi 접속 권한, 스냅샷/CBT 상태, HotAdd/NBD/SAN 경로 및 Proxy 성능
Windows Agent: RPC/관리자 권한, VSS Writer, Repository 연결, 애플리케이션 정합성 및 작업 로그
Linux Agent: 배포 계정/SSH, 커널·Snapshot 모듈·Secure Boot, 지원 파일시스템, Recovery Media
복원 작업: 격리 네트워크, 복원 대상 디스크/Datastore, 중복 IP, 최종 파일·DB 데이터 검증
백업 저장소: 용량, 성능, 보존 정책, 오프사이트 보관, 필요 시 Immutable Repository
관리·데이터 전송 포트로 VMware 443/902, Linux 22, Windows 135, Veeam 관련 6160/6162 등이 등장하지만 모든 제품/버전의 고정 포트 목록은 아닙니다. 실제 통신 방향과 복구 시나리오에 따라 필요한 범위가 달라지므로 현재 설치 빌드의 Ports 가이드를 확인해야 합니다.
14. 버전 주의사항과 정리
이번 내용은 Veeam Backup & Replication 12.2 당시의 Windows Console 화면과 테스트 결과를 기반으로 합니다. 최신 Veeam 13 계열에는 설치 방식과 지원 조건, UI가 달라진 부분이 있습니다.
공식 Lifecycle 기준 VBR 12 제품군의 End of Fix는 2025년 11월, End of Support and Security Fix는 2027년 2월로 안내되고 있습니다. 이 날짜가 특정 구형 12.2 빌드에 대한 모든 취약점 수정 제공을 보장하지는 않으므로 최신 패치·업그레이드 정책을 함께 봐야 합니다.
이번 테스트에서 VM 전체 복구 성공 로그, Instant Recovery를 통한 VM 게시, Windows Agent 백업과 파일 및 Recovery 파티션 복구, Linux Agent 백업과 Recovery Media 복원·파일 복구까지 확인했습니다. 다만 모든 서비스의 운영 정상화나 DB별 애플리케이션 무결성까지 검증한 결과는 아닙니다.
백업은 Job 성공으로 끝나는 것이 아니라 원하는 방식으로 실제 데이터를 되살릴 수 있는지까지 확인하는 편이 좋겠습니다.
공식 참고자료
광고






