Veeam Windows MSCS 단일 노드 복구 테스트 | Instant Recovery·공유 디스크·SQL Server

Windows MSCS 복구 테스트

Windows Failover Cluster(MSCS/WSFC) 환경을 백업할 때는 일반 서버와 달리 공유 디스크와 Quorum 구성을 함께 살펴봐야 합니다. 이번에는 2노드 SQL Server 클러스터에서 한 노드만 별도의 가상 머신으로 복구하는 테스트 흐름을 정리해봤습니다.

단순히 OS가 부팅되는지만 확인한 것이 아니라, Veeam Agent 백업을 이용한 Instant VM Recovery, 공유 디스크의 VMDK Export, 복구 VM에 디스크 연결, 클러스터 강제 시작, SQL Server 역할 상태 확인까지 진행한 사례입니다.

1. 테스트 환경과 복구 목표

원본 테스트의 데이터·Quorum 디스크 구성

운영 클러스터에서 한 노드가 사라지는 상황을 가정하고, 남은 백업으로 해당 노드를 독립된 복구 환경에 올려보는 것이 목표였습니다. 특히 OS 디스크만 복구해서는 공유 디스크에 있던 SQL 데이터가 그대로 따라오지 않을 수 있다는 점이 핵심입니다.

2. 클러스터를 보호 대상으로 백업 Job 생성

Veeam Backup & Replication 콘솔에서 Windows Agent Backup Job을 생성할 때 Failover cluster 유형을 선택했습니다.

Failover cluster 백업 작업 유형

이후 Protection Group에 등록된 Failover Cluster 객체를 선택했습니다. 멤버 노드 각각을 독립된 일반 서버로 백업하는 방식과 구분해야 합니다.

Protection Group의 클러스터 보호 객체 선택

Veeam의 현재 가이드에서도 클러스터 전체 백업은 VBR이 관리하는 전용 Failover Cluster Job을 권장합니다. 이렇게 구성해야 공유 디스크가 노드 간 이동하는 상황을 추적할 수 있고 불필요한 별도 백업 체인 생성을 줄일 수 있습니다.

3. Veeam Agent 백업 진행 화면 확인

클러스터 백업 진행 상태

4. Instant VM Recovery로 단일 노드 복구

백업의 Restore Point를 선택한 후 Instant VM Recovery를 실행했습니다. 이 방식은 백업 데이터를 이용해 vSphere 가상 머신을 빠르게 기동하는 데 유용합니다. Veeam Agent 백업에서 물리 서버를 가상 머신으로 복구하는 P2V 흐름이기도 합니다.

Instant Recovery 세션의 P2V 처리 로그

여기서 꼭 확인할 로그가 있습니다.

Skipping clustered disk ... instant recovery
Performing P2V conversion

테스트 화면에서는 클러스터 디스크를 건너뛰는 메시지가 표시됩니다. 즉, Instant Recovery로 노드 OS를 올린 뒤에도 공유 데이터 디스크는 별도 복구·연결 작업이 필요했습니다. Instant Recovery 단계와 공유 볼륨 복구 단계를 나눠서 살펴봐야 하는 이유입니다.

5. 임시 NFS 영역에서 운영 Datastore로 이관

Instant Recovery는 백업을 활용해 임시 VM을 제공하므로 일반 운영 VM처럼 계속 사용하는 것과 차이가 있습니다. 이번 기록에서는 복구 VM의 데이터스토어 위치가 임시 NFS 영역에서 VMFS 기반 운영 Datastore로 바뀐 화면을 확인할 수 있었습니다.

복구 VM의 운영 Datastore 위치

Veeam은 복구된 임시 VM을 운영 스토리지로 이동하기 위해 Storage vMotion 또는 Quick Migration 등의 방식으로 Instant Recovery를 마무리하도록 안내합니다. 실제 어떤 이관 옵션을 사용했는지는 이 기록에 남아 있지 않으므로 여기서는 이관 후 저장소 위치가 변경된 결과만 설명하겠습니다.

6. 공유 데이터·Quorum 관련 디스크 VMDK Export

이제 클러스터가 사용하던 디스크를 확인합니다. 원본 구성에는 데이터용 D: 볼륨과 Quorum 관련 Q: 볼륨이 있었고, 테스트에서는 Veeam의 Disk Export 기능으로 가상 디스크를 내보냈습니다.

VMDK Disk Export 완료 세션

Export 로그에는 Disk export completed, Success가 표시됩니다. 여기서 확인한 것은 디스크 Export 작업이 완료되었다는 사실입니다. 디스크 자체의 무결성이나 SQL DB의 정상 동작은 이후 단계에서 따로 확인해야 합니다.

Veeam에서는 Agent 백업에 포함된 디스크를 VMDK/VHD/VHDX 형태로 변환해 복구할 수 있습니다. 단, 클러스터 Disk Witness는 일반 공유 볼륨 복구와 취급 방식이 다릅니다. 현재 공식 문서에서는 Failover Cluster 공유 디스크의 Volume Restore 과정에서 Disk Witness가 복구 대상으로 표시되지 않는다고 안내합니다. 따라서 이 기록의 Quorum 관련 디스크 Export를 모든 버전에서 Witness를 자동 복구할 수 있다는 의미로 해석하면 안 됩니다. 테스트 시점과 제품 버전, 실제 디스크 종류를 반드시 별도로 확인해야 합니다.

7. 복구 VM에 데이터 디스크 연결 후 부팅

Export한 VMDK를 vSphere에서 복구된 VM의 디스크 장치로 추가하고, 부팅 후 Windows가 볼륨을 인식하는지 확인했습니다. 이때는 디스크 순서, SCSI 컨트롤러, 드라이브 문자, 기존 RDM 매핑 정보가 원본과 일치하는지 살펴보는 것이 좋습니다.

이 단계에서 주의할 점은 복구 VM을 원본 클러스터 네트워크와 격리해야 한다는 것입니다. 복구된 서버가 원본 서버와 같은 이름, IP, 클러스터 구성을 가진 상태에서 운영망에 연결되면 충돌이나 데이터 손상이 발생할 수 있습니다.

8. Quorum 없이 클러스터 서비스 강제 시작

단일 노드만 따로 복구했기 때문에 정상적인 쿼럼 투표가 성립하지 않을 수 있습니다. 해당 테스트 기록에서는 관리자 명령 프롬프트에서 다음 명령을 사용했습니다.

net stop clussvc
net start clussvc /fq

이는 당시 기록에 남은 강제 시작 방식입니다. 현재 Microsoft 문서에서 안내하는 PowerShell 방식은 다음과 같습니다.

Start-ClusterNode -ForceQuorum

이 명령은 반드시 격리된 복구 테스트이거나 Microsoft의 복구 조건을 충족하는 실제 장애 상황에서만 신중하게 사용해야 합니다. 강제 쿼럼은 보통의 '서비스 시작'과 달리 투표 기반 안전장치를 우회합니다. 다른 노드가 동시에 클러스터를 구성해 실행되지 않도록 해야 하고, 운영 클러스터 복원 시 노드 투표와 Quorum 설정을 재검토해야 합니다. 강제 시작 후 다른 노드를 합류시킬 때는 -PreventQuorum 등 공식 복구 절차도 확인해야 합니다.

9. 클러스터 노드와 공유 디스크 상태 확인

복구 테스트의 클러스터 노드 상태

클러스터 관리 화면에는 한 노드가 실행 중이고 다른 노드는 중지된 상태가 표시됩니다. 단일 노드만 기동한 테스트의 결과로 이해해야 합니다.

공유 디스크 2개 온라인 상태

공유 디스크 화면에서는 두 디스크 모두 온라인으로 표시되었습니다. 이 상태를 통해 클러스터 관점의 디스크 인식까지는 확인할 수 있었습니다. 다만 SQL 데이터의 실제 정합성은 별도 검사해야 합니다.

10. SQL Server 역할과 클러스터 코어 리소스 검증

SQL Server 클러스터 역할 실행 중

SQL Server 역할은 실행 중으로 표시되었습니다. 이어서 클러스터 코어 리소스 화면에서는 네트워크 이름과 IP 주소 리소스가 온라인 상태인 것을 확인했습니다.

클러스터 코어 리소스 온라인 상태

따라서 이번 테스트에서는 복구한 단일 노드의 OS 기동 → 공유 디스크 온라인 → 클러스터 역할 실행 → SQL Server 역할 실행 상태 표시까지 확인한 셈입니다.

단, SQL Server 역할이 실행 중이라는 것만으로 모든 데이터베이스의 무결성과 애플리케이션 접속이 입증되지는 않습니다. 이를 위해서는 SQL Server 접속, 데이터베이스 상태, 서비스 계정 및 실제 업무 쿼리 테스트가 추가로 필요합니다.

11. 운영 환경에서 추가 확인할 사항

• 네트워크 격리: 복구 VM과 원본 클러스터가 같은 IP·호스트명으로 동시에 운영망에 존재하지 않도록 구성합니다.

• 공유 디스크 방식: 원본이 RDM이면 내보낸 VMDK를 어떻게 다시 연결할지, SCSI 버스 공유 및 지원 구성이 무엇인지 복구 설계에 반영합니다.

• Disk Witness: 공유 볼륨 데이터 복구와 Witness 재구성은 구분합니다. Get-ClusterQuorum으로 현재 쿼럼 구성을 확인합니다.

• 디스크 확인: Windows 디스크 관리, Failover Cluster Manager에서 온라인 여부와 소유 노드를 확인합니다. 강제 온라인이나 기존 클러스터 메타데이터 삭제는 충분한 격리 및 사전 검증 없이 진행하지 않습니다.

• SQL 정합성: FCI 서비스 시작 후 SSMS 접속, sys.databases 상태, SQL Server 오류 로그 및 필요 시 DBCC CHECKDB 등을 별도로 확인합니다.

• 고가용성: 이번 기록은 한 노드 서비스 기동 테스트이며, 나머지 노드의 가입·Failover·자동 장애 조치까지 시험한 결과는 아닙니다.

• 버전 확인: 기록의 테스트 화면과 현재 제품에서는 메뉴·지원 범위·복구 동작이 다를 수 있습니다. 실제 적용 전에 VBR/Agent 빌드와 지원 매트릭스를 확인합니다.

확인용 명령은 격리된 테스트 환경에서 다음처럼 사용할 수 있습니다.

Get-ClusterNode
Get-ClusterGroup
Get-ClusterResource
Get-ClusterQuorum
Get-ClusterSharedVolume

DB 상태는 권한이 있는 SQL Server 세션에서 확인합니다.

SELECT name, state_desc
FROM sys.databases;

위 PowerShell/SQL 쿼리는 독자가 후속 확인에 사용할 수 있도록 덧붙인 예시이며, 당시 테스트 기록에 실행 결과가 남아 있는 명령은 아닙니다.

정리

일반 서버의 P2V 복구는 부팅 후 서비스 확인으로 끝날 때도 있지만, WSFC/MSCS는 OS와 공유 디스크, Quorum, 클러스터 역할을 분리해서 봐야 합니다. 특히 이번 기록에서는 Instant Recovery 중 클러스터 디스크가 제외되는 로그를 확인했고, 이후 Disk Export와 수동 연결을 거쳐 디스크 온라인 및 SQL 역할 실행 상태까지 확인했습니다.

최종적으로 이번 환경의 단일 노드 복구 및 SQL Server 역할 기동 확인은 진행됐지만, 2노드 고가용성 복구나 모든 데이터베이스의 정합성 검사까지 완료한 것으로 확대 해석하지 않는 것이 좋겠습니다.

공식 참고자료

• Veeam — Backup and Restore of Failover Clusters

• Veeam — Failover Cluster Support

• Veeam — Restoring Veeam Agent Backup to vSphere VM

• Veeam — Instant Recovery to VMware vSphere

• Veeam — Exporting Disks

• Microsoft — Recover a failover cluster without quorum

• Microsoft — Force a WSFC Cluster to Start Without a Quorum