• 아티클

Virtualization

서버 가상화를 위한 백업 및 재해 복구

Adam Fazio

 

한 눈에 보기:

  • 재해 복구 계획을 위한 고려 사항
  • 재해 복구를 위한 고가용성 솔루션
  • Windows Server Backup을 사용한 백업 및 복원

목차

재해 복구 계획 101
재해 복구 및 가상화
실제 컴퓨터를 가상 컴퓨터로 변환
가상 컴퓨터 스냅숏
Hyper-V 백업
Windows Server 백업
WSB로 VM 백업
고려 사항
WSB로 VM 복원
Data Protection Manager
스크립트를 사용한 백업
DiskShadow
요약

서버 가상화 기술이 발전하고 업계 도입이 증가함에 따라 여러 조직에서는 인프라 비용 절감과 IT 민첩성 향상이라는, 가장 널리 알려진 가상화의 장점 이외에도 더 많은 혜택이 있음을 인식하고 있습니다. 다음 개척지는 DR(재해 복구)을 구현 또는 강화하기 위한 방편으로 가상화 플랫폼을 사용하는 것입니다.

DR 준비도가 계속해서 IT 업계 최대의 화두 중 하나로 꼽히는 이유는 무엇일까요? 연구에 따르면 시스템 가동이 한 시간 중지될 때마다 기업이 입는 평균 손실액은 80,000달러에서 90,000달러에 이르며, 심각한 데이터 손실을 입은 회사가 장기적으로 생존하는 경우는 극소수에 불과합니다. 이 기사에서는 Microsoft 가상화 플랫폼을 사용한 DR을 소개하고 Windows Server 2008 Hyper-V의 백업 및 복원 옵션과 고려 사항을 자세히 살펴보겠습니다.

재해 복구 계획 101

DR은 시스템 가동이 중단되었을 때 중요한 서비스를 복원하는 프로세스이며, 모든 회사는 재해 발생 중 또는 그 이후 어떻게 회사 기능을 지속할지를 정의하는 비즈니스 연속성 계획의 일부로 DR을 포함해야 합니다. 이러한 계획은 모든 DR 이니셔티브의 토대입니다.

일부 공급업체는 자사의 DR 자동화 기술이 충분한 시연을 거친 세부적인 계획의 필요성을 최소화하거나 아예 없애 준다고 주장합니다. 자동화를 통해 복구 시간을 단축하고 사용자 조작에 대한 의존성을 낮출 수 있는 것은 분명 사실이지만 잘 알려진 바와 같이 기술만으로 재해를 완화할 수는 없으며 사람과 프로세스도 기술 못지않게 중요합니다.

실제로 DR 계획 프로세스의 모든 제약과 목표에 대한 지식이 없으면 올바른 기술을 선택하는 것조차 거의 불가능하다는 것을 알 수 있습니다. 이 기사에서 전체 DR 계획을 정의할 수는 없지만 올바른 기술과 구현을 선택하는 데 필요한 이러한 요소를 집중적으로 살펴볼 것입니다. 우선 DR 계획과 관련된 몇 가지 중요한 기술 동력을 간단히 알아보겠습니다.

서비스 정의 및 우선 순위 여러분이 보호하려는 전체 서비스와 조직에 있어서 이러한 서비스의 중요도를 정의하는 요소는 정확히 무엇일까요? 그림 1에는 모든 DR 계획에 일반적으로 포함되는 회사 서비스의 예가 나와 있습니다.

그림 1 서비스 정의 및 우선 순위 예

서비스 주 구성 요소 종속성 업무 용도 SLA
공용 웹 사이트 네트워크 부하 분산 장치, 웹 서버 3개, 데이터베이스 서버 2개 DNS, 네트워크, 방화벽, 디렉터리, SAN(저장 영역 네트워크) 저장소 제품 구입 및 주문 추적, 전자 상거래, 고객 지원 포털, 회사 정보 99.99%
재무 시스템 데이터베이스 서버 2개, 응용 프로그램 서버 1개 DNS, 네트워크 법 규정에 따라 회사 수익 기록 99.99%
전자 메일 시스템 전자 메일 서버 3개, 웹 서버 1개 DNS, 네트워크, 방화벽, 디렉터리 회사 통신, 고객 지원 99.5%

서비스를 정의한 다음에는 어떤 유형의 DR 전략을 위해 어떤 시스템과 종속성을 대상으로 해야 하는지를 알아낼 수 있습니다. 예를 들어 전체 서비스와 종속성 집합을 살펴본 후 모든 중요 업무용 서비스를 위한 단일 DR 솔루션은 비용이 너무 많이 들고 복잡하므로 몇 가지 다른 DR 기능 수준을 고려할 필요가 있음을 알게 될 수 있습니다.

SLA(서비스 수준 계약) SLA는 서비스 공급자(IT)와 고객(조직) 간에 지정된 서비스의 가용성 목표를 정의하는 협약 또는 계약입니다. SLA는 길수도, 짧고 간결할 수도 있습니다. 예를 들어 "전자 메일 시스템은 일반적인 업무 시간에는 99.95% 사용 가능하고 일반적이지 않은 업무 시간에는 98% 사용 가능합니다. 단, 매월 측정되는 예약된 유지 관리 시간은 계산에서 제외합니다."와 같이 정의할 수 있습니다. 일반적으로 SLA는 IT 서비스를 할당할 수 있는 여러 계층으로 분할되며 미리 정의된 기간에 걸쳐 측정됩니다.

OLA(운영 수준 계약) OLA는 기본적으로 SLA를 지원하기 위해 작업하는 여러 IT 그룹 간의 계약을 기술합니다. 이 계약에는 해당 서비스 제공을 위한 처리 및 응답 시간이 포함됩니다. 예를 들어 중요 업무용 웹 사이트의 SLA 목표는 99.99%이지만 이 사이트의 콘텐츠를 제공하기 위해 사용되는 데이터베이스의 가용성 목표는 95%일 수 있습니다. OLA는 이러한 불일치를 밝혀내고 IT 팀이 같은 목표를 향하도록 조율합니다.

RPO(복구 지점 목표) 및 RTO(복구 시간 목표) RTO는 연속성이 끊어지기 전까지 허용되는 서비스 중단 시간을 정의하며 RPO는 조직에서 수용할 수 있다고 간주하는 데이터 손실의 수준을 정의합니다. 예를 들어 매달 측정하는 SLA가 99%라면 RTO는 7시간 18분입니다. 이를 가령 24시간 RPO와 조합하면 백업 기술과 일정을 정확하게 정의할 수 있습니다.

데이터 보존 정책 조직의 데이터 보존 정책은 백업을 저장해 두는 기간 및 그 위치를 지정합니다. 데이터 보존 정책은 일반적으로 법률 및 규정 요구 사항에 따라 결정됩니다.

데이터 분류 데이터의 성격에 대해서도 고려해야 합니다. 데이터를 범주별로 분류해 보면 모든 데이터에 대해 같은 수준으로 DR을 고려할 필요는 없다는 사실을 금방 알 수 있습니다. 예를 들어 단일 데이터베이스의 가용성 요구 사항은 각각 디렉터리 복제본을 포함하는 여러 개의 도메인 컨트롤러가 있는 Active Directory의 가용성 요구 사항과는 다를 것입니다. 마찬가지로, 파일 서버 데이터를 복원하는 절차는 CRM 데이터를 복원하는 절차와는 많은 부분에서 다를 것입니다.

재해 시나리오 각 시나리오는 복원 절차, 비즈니스에 미치는 영향 및 관련 비용이 서로 다르므로 계획하려는 모든 시나리오를 정의하는 것이 중요합니다. 환경에 맞는 DR 계획을 수립할 때는 가능한 모든 시나리오를 살펴보고 대상 시나리오를 결정하는 방법이 도움이 됩니다.

  • 전체 사이트 손실
  • 단일 데이터 센터 손실
  • 시스템 손실(운영 체제 또는 하드웨어 오류)
  • 데이터 손실(데이터 삭제 또는 손상)
  • 중요 종속성 손실

물론 전체 사이트 손실을 복구할 때의 고려 사항은 단일 시스템을 복구할 때와는 판이하게 다릅니다. 또한 SLA를 기반으로 복구 임계값도 정의해야 합니다. 예를 들어 대규모 ISP 네트워크 중단으로 인해 전체 사이트가 오프라인 상태가 되었다고 가정해 보겠습니다. 영향을 받는 서비스에 대한 SLA가 서비스 복원에 8시간, 데이터 복원에 48시간인 경우 아마 여러분은 백업 사이트로의 장애 조치 절차는 수행하겠지만 다시 프로덕션 사이트로의 전환이 신속히 이루어지리라 예상하고 데이터 복구 프로세스는 실행하지 않을 것입니다.

이런! 이렇게 많은 내용을 다루었는데 정작 기술에 대한 내용은 시작도 하지 못했네요. 계획의 중요성을 과소평가해서는 안 됩니다. 문서화된 계획이 없는 DR 구현은 단지 "DR 희망 사항"일 뿐입니다.

재해 복구 및 가상화

이것으로 DR 계획에 대한 기본 사항은 모두 설명했습니다. 여기에서 가상화는 어떤 역할을 할까요? 많은 회사에서는 실제 서버의 복원 시간이 일 또는 주 단위인데 반해 가상화된 서버를 이용할 경우의 복원 시간은 분 단위에 불과한 것으로 보고하고 있습니다. 가상화된 서버에서는 전체 서버 운영 체제가 기본 실제 하드웨어로부터 추상화된 단순한 파일 집합에 불과하므로 복구 기능에 있어 새로운 문이 열리게 됩니다.

현재 일반적인 이론은 HA(고가용성) 솔루션으로 일부 또는 모든 DR 목표를 달성할 수 있다는 것입니다. 여기에서의 기본 개념은 분리된 물리적 위치에 클러스터 노드가 있고 두 사이트 간에 데이터가 동기화된다면 오류가 발생할 경우 패시브 노드가 작업을 다시 시작하므로 거의 실시간으로 복구가 가능하다는 것입니다.

이는 사실이지만 앞에서 정의한 재해 시나리오를 감안하면 모든 재해 시나리오에 대한 솔루션은 아니라는 점을 알 수 있습니다. 모든 시나리오에 대비하려면 여러 기술을 조합해야 하며 일반적으로 여기에는 일종의 정기적인 백업이 포함됩니다. HA가 가능한 모든 가동 중단에 대한 보호를 제공하는 것은 아니며 백업 전략의 필요성을 완전히 없애는 것도 아닙니다.

Hyper-V를 포함하는 HA에서는 저장소 계층을 신중하게 계획해야 합니다. 저장소 계층은 복구 기능을 사용하기 위한 핵심 요소이기 때문입니다. 예를 들어 공유 저장소가 있는 2노드 Hyper-V 클러스터의 경우 클러스터 노드가 별도의 데이터 센터에 있는 경우라도 저장소 하위 시스템과 데이터가 여전히 단일 실패 지점입니다.

그러나 비공유 저장소를 사용하는 2노드 Hyper-V 클러스터는 둘 중 한 노드에 저장소 손실이나 데이터 손실이 발생하더라도 유지될 수 있습니다. 이를 위해서는 저장소를 동기화하기 위한 복제 기술이 필요하며 이에 따른 복잡성이 추가됩니다(그림 2 참조).

fig02.gif

그림 2 다중 사이트 Hyper-V 클러스터 (더 크게 보려면 이미지를 클릭하십시오.)

데이터 복제 및 동기화 영역에는 몇 가지 매우 흥미로운 개발이 진행 중이지만 현재 Microsoft에서 제공하는 것은 아닙니다. Windows Server 2008 다중 사이트 클러스터링 페이지(microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx)에 소개된 파트너 업체를 확인해 보십시오. 또한 Windows Server 카탈로그(windowsservercatalog.com 참조)에는 Windows Server 2008 인증을 받은 복제 기술을 제공하는 저장소 공급업체 목록이 나열되어 있습니다.

여기에서 볼 수 있듯이 가능한 HA와 저장소 구성은 많습니다. 이 부분 역시 비즈니스 요구 사항을 먼저 정의하고 여기에 맞추어 기술 요구 사항을 정의해야지 그 반대로 하면 안 되는 이유입니다.

실제 컴퓨터를 가상 컴퓨터로 변환

가상화는 몇 가지 뛰어난 복구 민첩성을 제공하지만 가상화에 적합하지 않은 실제 시스템의 경우에는 어떻게 해야 할까요? SCVMM(System Center Virtual Machine Manager)에는 실행 중인 Windows 서버에 대해 P2V(실제 컴퓨터에서 가상 컴퓨터로) 변환을 수행하여 실제 원본 서버의 완전한 복사본인 부팅 가능 Hyper-V VM(가상 컴퓨터)을 만드는 기능이 포함되어 있습니다. 이 VM을 해당 가상화 항목과 마찬가지로 한 부지 또는 전국에 걸쳐 복제하여 비슷한 복구 시간을 달성할 수 있습니다.

이 방법은 복구 위치에 프로덕션 위치와 같은 수 또는 유형의 실제 시스템이 필요 없다는 점에서 기존 BMR(Bare Metal Restore)과 다릅니다. 따라서 복구 하드웨어를 추가 구독하여 재해의 영향에 따라 필요한 만큼 이를 확장할 수 있습니다.

SCVMM에는 P2V 변환을 위한 스케줄러가 포함되어 있지 않지만 GUI가 완전히 Windows PowerShell을 기반으로 실행되므로 New-P2V cmdlet을 사용하여 간단하게 스크립트로 작성할 수 있습니다. 사실 SCVMM의 모든 마법사는 작업을 실행하는 데 사용하는 코드를 보여 주므로 여러분 환경의 테스트 P2V에서 코드를 복사하고 향후 자동화 작업에서 수정하여 사용할 수 있습니다. 그림 3에는 일부 샘플 코드가 나와 있습니다. SCVMM P2V 마법사를 여러분의 환경에서 실행하여 고유하고 사용자 지정이 가능한 Windows PowerShell 스크립트를 얻을 수 있습니다.

그림 3 SCVMM P2V 마법사에 의해 생성된 코드

$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>" 
-Credential $Credential -RunAsynchronously 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F" 
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External" 
-MachineConfig $MachineConfig 

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig 

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path 
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup 
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig 
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM 
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

가상 컴퓨터 스냅숏

VM 스냅숏은 기술적으로 말해 백업은 아니지만 차이점 보관용 디스크와 VM 구성 파일 복사본을 사용하여 되돌릴 수 있는 특정 시점을 제공합니다. 재해가 발생하여 VM 내의 데이터가 뜻하지 않게 삭제된 경우 VM이 스냅숏으로 롤백을 수행하여 피해를 복원할 수 있으므로 이를 DR 기능으로 볼 수 있습니다. VSS(볼륨 섀도 복사본 서비스) 스냅숏에 대해서는 조금 뒤에 살펴보겠습니다.

Hyper-V 백업

호스트 기반 백업 서버 가상화의 흥미로운 이점 중 하나는 가상화된 시스템을 더 이상 개별적으로 백업할 필요가 없어질 수 있다는 가능성입니다. 이러한 시스템은 호스트의 파일 시스템에 위치한 파일에 불과하므로 이러한 파일을 백업하면 끝나는 것 아닐까요? 그렇지 않습니다. 이러한 시스템은 메모리 내 데이터, 디스크의 데이터, 시스템 구성, 열려 있는 파일 등으로 구성된 실제 작동 중인 컴퓨터이므로 몇 가지 고려해야 할 사항이 있습니다. 이렇게 유동적인 부분들로 구성되어 있는데 어떻게 백업 데이터 일관성을 보장할 수 있을까요?

Windows Server 백업에 있어 중요한 발전은 Windows Server 2003과 VSS의 등장에 따라 이루어졌습니다. VSS는 VSS 기록기(일관적인 섀도 복사본을 제공하는 데 도움이 되는 응용 프로그램과 서비스에 연결)가 열려 있는 파일과 응용 프로그램의 백업을 만드는 데 사용하는 확장 가능 API의 표준 집합을 제공합니다. 백업 응용 프로그램은 VSS 서비스, 공급자 및 기록기의 도움을 받아 특정 시점의 볼륨 복사본을 매우 신속하게 생성할 수 있으며 응용 프로그램에서는 이 복사본을 인식하고 적절하게 처리할 수 있습니다.

Hyper-V는 소프트웨어 개발 업체가 강력한 백업 솔루션을 만들 수 있도록 지원하는 자체 VSS 기록기를 제공합니다. 백업 응용 프로그램에서는 이 기록기를 사용하여 실행 중인 VM의 호스트 기반 VSS 백업을 얻을 수 있습니다. VM 내에서 실행 중인 운영 체제에 Hyper-V 통합 구성 요소와 VSS 서비스(Windows XP SP1 및 Windows Server 2003 이상에서 제공)가 설치되어 있는 경우 호스트 기반 백업은 게스트 내에서 실행되는 경우와 동일하게 수행됩니다. 백업은 VM 실행 중에 수행되며 데이터 일관성이 확보됩니다(그림 4 참조).

fig04.gif

그림 4 VSS 백업(더 크게 보려면 이미지를 클릭하십시오.)

그러나 게스트 운영 체제가 통합 구성 요소나 VSS를 지원하지 않는 경우 백업 프로세스를 위해서는 게스트 컴퓨터를 저장된 상태로 전환해야 하며 VM 데이터 파일로부터 특정 시점 복구에 사용할 수 있는 호스트 기반 VSS 스냅숏을 만들어야 합니다. 저장된 상태의 VSS 스냅숏은 데이터의 VSS 복사본을 대상으로 전체 테이프 백업 절차를 수행하며 약간의 VM 가동 중지 시간(일반적으로 5분에서 10분)을 유발합니다.

게스트 기반 백업 실제 환경에서 서버와 응용 프로그램은 별도로 백업되어야 하며 이러한 백업은 가상화된 데이터 센터에서 확실히 지속이 가능합니다. 이러한 상황에서는 VM을 백업할 때 네트워크 기반 백업을 위한 네트워크 용량 요구 사항, 백업 시간 중 시스템의 성능에 미치는 영향과 같은 동일한 고려 사항을 참작해야 합니다. 게스트 기반 백업의 경우 모든 게스트가 사용하는 가상 네트워크에 바인딩되는 전용 실제 NIC를 호스트에서 사용할 수 있습니다.

Windows Server 백업

Windows Server 2008에 포함된 VSS 지원 WSB(Windows Server 백업)를 사용하면 Hyper-V 호스트 및 게스트 기반의 VM 백업을 수행할 수 있습니다. VSS를 완벽하게 지원하므로 실행 중인 VM의 호스트 기반 백업(당연히 둘 중에 이 방식이 더 바람직함)을 수행할 수 있습니다.

그러나 VM에 통합 구성 요소가 설치되지 않은 경우에는 VSS가 사용되지 않습니다. 이 경우에는 두 가지 옵션 중에서 선택할 수 있습니다. 여기에서도 WSB를 사용하여 통합 구성 요소가 설치되지 않은 VM을 백업할 수 있습니다. 이는 VM의 상태가 저장되고, 그 이후 백업이 VM의 가상 디스크와 구성 파일을 가져옴을 의미합니다.

그러나 이 방법은 Exchange와 같은 응용 프로그램에서는 바람직하지 않습니다. 백업이 실행되었음을 응용 프로그램이 인식하지 못하고, 응용 프로그램 로그가 잘리지 않기 때문입니다. 게다가 VM에 가동 중지 시간이 발생합니다. 이 시간은 백업 수행에 소요되는 시간에 따라 달라집니다.

다른 방법은 VM의 OS에 따라 NTBackup 또는 WSB를 사용하여 VM 내에서 실제 컴퓨터인 것처럼 백업을 실행하는 것입니다. 통합 구성 요소가 설치된 지원되는 게스트에 WSB를 사용하는 방법을 살펴보겠습니다.

WSB로 VM 백업

Hyper-V는 WSB에서 사용하도록 VSS 기록기를 자동으로 등록하지는 않습니다. 그림 5에 나와 있는 레지스트리 키와 값을 수동으로 추가해야 WSB가 Hyper-V 백업을 지원합니다. 다음과 같이 명령줄을 사용하여 이러한 항목을 추가할 수 있습니다.

reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v

그림 5 Hyper-V VSS 기록기를 등록하기 위한 키와 값

경로 레지스트리 키 또는 값 종류
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} 키 해당 없음
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier 값 REG_SZ(예: Hyper-V)

WSB는 백업 런타임에 이 키/값을 검색하므로 다시 부팅은 필요 없습니다. 다음 명령은 항목이 설정되었는지를 표시합니다.

reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s

WSB를 설치하는 방법은 다음과 같습니다. 시작 | 서버 관리자를 클릭합니다. 왼쪽 창에서 기능을 클릭하고 오른쪽 창에서 기능 추가를 클릭합니다. 기능 선택 페이지에서 Windows Server 백업 기능을 확장하고 Windows Server 백업 및 명령줄 도구의 확인란을 선택합니다. 이제 다음 단계를 수행하여 백업을 구성합니다.

  1. 시작 | 관리 도구 | Windows Server 백업으로 이동합니다.
  2. 원격 호스트를 백업하는 경우 다른 컴퓨터에 연결을 선택하고 Hyper-V 호스트를 입력합니다.
  3. 한 번 백업 또는 백업 일정을 선택합니다.
  4. 백업 구성(전체 서버 또는 사용자 지정)을 선택합니다. 사용자 지정을 선택하는 경우 VM 구성 데이터, 가상 디스크 및 스냅숏을 포함하여 백업 중인 VM과 관련된 데이터가 포함된 모든 볼륨을 지정해야 합니다.
  5. 백업을 저장할 위치를 선택합니다.
  6. VSS 전체 백업 또는 복사본 백업을 선택합니다. 다른 VM 백업은 수행되지 않는 호스트 기반 백업의 경우 VSS 전체 백업을 선택합니다.
  7. 세부 정보를 확인한 다음 백업을 선택합니다.

고려 사항

  • VHD(가상 하드 디스크), VM 구성 파일 및 스냅숏을 포함하여 VM과 관련된 모든 볼륨을 백업해야 합니다.
  • 백업 일정을 만드는 경우 포맷하여 WSB에만 사용할 전용 로컬 볼륨을 사용해야 합니다. 반면 한 번 백업 작업을 수행하는 경우 전용이 아닌 로컬 볼륨, 이동식 장치 또는 네트워크 공유에 백업을 저장할 수 있습니다.
  • 백업되는 VM 내에 통합 구성 요소가 설치되지 않은 경우 WSB는 백업 데이터 일관성을 보장하기 위해 실행 중인 VM의 상태를 저장합니다.
  • 완료된 후 백업 세트는 이식이 가능하며 모든 Hyper-V 호스트에서 사용할 수 있습니다.

WSB로 VM 복원

WSB에는 개별 파일을 복원하는 기능이 있지만 이 기능은 VSS를 사용하지 않기 때문에 백업이 수행된 시점에 VM이 실행 중이었다면 일관성이 없는 복원 결과를 얻을 수 있습니다. 실행 중인 VM을 복원하려면 전체 볼륨을 복원해야 합니다.

이를 위해서는 시작 | 관리 도구 | Windows Server 백업으로 이동한 다음 작업 창에서 복구를 선택합니다. 복구할 데이터가 있는 서버(WSB 백업 데이터가 있는 위치)를 선택하고 데이터를 복원할 날짜를 선택합니다. 이제 복구 유형을 선택할 수 있습니다.

여기에서 한 가지 결정을 내려야 합니다. 구성, 스냅숏 및 가상 디스크를 포함한 전체 VM이 필요한 경우(예를 들어 호스트 전체적인 문제가 발생한 경우)에는 그림 6에 나와 있는 것처럼 응용 프로그램 복원, Hyper-V를 차례로 선택합니다. 이 경우에는 개별 파일을 복원하는 옵션은 없으며 해당 백업 세트에 포함된 모든 항목을 복원해야 합니다. 이렇게 해도 기존 백업 이후에 변경된 VM 구성 데이터와 Hyper-V는 덮어쓰지 않습니다.

fig06.gif

그림 6 Hyper-V 백업 복원(더 크게 보려면 이미지를 클릭하십시오.)

VHD 자체만 필요하고 VM의 구성 데이터와 스냅숏에는 문제가 없는 경우 파일 및 폴더를 선택하고 필요한 개별 VHD 파일을 선택할 수 있습니다. 이 프로세스에는 VSS 기록기가 사용되지 않으므로 이를 염두에 두고 VM의 상태를 먼저 저장하고 백업해야 합니다.

전체 시스템과 데이터가 손실되어 Windows Server 2008 운영 체제와 그 내부에서 실행되는 모든 VM을 포함하여 Hyper-V 호스트 자체를 복구해야 하는 경우 Windows 복구 환경으로 부팅하고 그곳에서 복원을 수행해야 합니다. 이 작업은 Windows Server 2008 설치 디스크 또는 미리 구성된 디스크 파티션에서 수행할 수 있습니다.

Data Protection Manager

지금까지 안정적인 무료 기본 제공 WSB를 사용하여 Hyper-V 호스트와 게스트를 백업 및 복원하는 과정과 고려 사항을 살펴보았습니다. 그러나 WSB는 엔터프라이즈급 데이터 보호 솔루션은 아닙니다. WSB로 해결되지 않는 기능은 DPM(Data Protection Manager) 2007 SP1을 사용할 수 있습니다. 2008년 말에 출시될 예정인 DPM SP1은 Hyper-V를 지원하며 다음과 같은 몇 가지 매력적인 기능을 제공합니다.

  • 모든 Hyper-V 호스트 및 게스트에 대한 단일 관리 콘솔
  • 최대 15분 간격으로 VSS 기반 스냅숏을 만들고 프로세스에서 변경된 비트만 처리하여 연속적으로 데이터 보호
  • Hyper-V 클러스터 인식 기능을 통해 백업이 클러스터 노드 사이를 이동하는 VM을 추적 가능
  • DPM 서버에서 DPM 서버로의 복제
  • 디스크 및 테이프 미디어 지원(디스크-디스크, 디스크-테이프 또는 디스크-디스크-테이프)
  • Hyper-V 호스트와 게스트를 포함하는 모든 유형의 데이터를 포괄하는 백업 및 복원 기능, 실행 중인 게스트의 에이전트 없는 VSS 백업, 개별 VM 복원 지원, 장애 조치(failover) 클러스터 데이터, SQL Server, Exchange, SharePoint, Hyper-V 및 가상 서버를 위한 동급 최상의 응용 프로그램별 기능
  • 백업 전 및 백업 후 스크립팅

현재 타사 백업 솔루션을 사용하고 있다면 응용 프로그램 업데이트를 확인하십시오. 대부분의 공급업체에서는 Hyper-V 호스트 기반 솔루션 출시를 추진 중입니다.

스크립트를 사용한 백업

WSB에는 스크립팅에 사용하기 위한 Windows PowerShell cmdlet 집합과 명령줄 인터페이스인 WBadmin.exe가 포함되어 있습니다. 이러한 기능을 사용할 때는 앞서 설명한 백업 규칙이 동일하게 적용되며 레지스트리를 통해 Hyper-V VSS 기록기를 수동으로 등록해야 합니다.

그림 7은 몇 가지 WBAdmin 명령을 보여 줍니다. 전체 WBAdmin 설명서를 보려면 go.microsoft.com/fwlink/?LinkId=124380을 참조하십시오. 여기에서 볼 수 있듯이 WBAdmin에는 백업 정책 자체를 구성하기 위한 항목이 없지만 이러한 설정을 관리하기 위한 Windows PowerShell 스냅인이 있습니다. 다음 명령을 사용하면 이 스냅인이 등록되었는지 테스트할 수 있습니다.

Get-PSSnapin -Registered

그림 7 WBAdmin 명령

WBAdmin 명령 설명
ENABLE BACKUP 예약된 매일 백업을 활성화하거나 수정합니다.
DISABLE BACKUP 예약된 매일 백업의 실행을 비활성화합니다.
START BACKUP 백업을 실행합니다.
STOP JOB 현재 실행 중인 백업이나 복구를 중지합니다.
GET VERSIONS 특정 위치에서 복구 가능한 백업의 세부 정보를 나열합니다.
GET ITEMS 백업에 포함된 항목을 나열합니다.
START RECOVERY 복구를 실행합니다.
GET STATUS 현재 실행 중인 작업의 상태를 보고합니다.
GET DISKS 현재 온라인 상태인 디스크를 나열합니다.
START SYSTEMSTATERECOVERY 시스템 상태 복구를 실행합니다.
START SYSTEMSTATEBACKUP 시스템 상태 백업을 실행합니다.
DELETE SYSTEMSTATEBACKUP 시스템 상태 백업을 삭제합니다.

또한 다음 명령을 사용하여 Windows.ServerBackup 스냅인을 로드할 수 있습니다.

Add-PSSnapin windows.serverBackup

스냅인이 로드되면 그림 8에 나온 것과 같은 WSB용 Windows PowerShell cmdlet을 사용할 수 있습니다. 각 cmdlet에 대한 자세한 설명을 보려면 다음 명령을 실행하십시오.

Get-Command -PSSnapin windows.serverBackup | select name | get-help –full

그림 8 Windows Server 백업 cmdlet

cmdlet 설명
Add-WBBackupTarget 백업 대상을 백업 정책에 추가합니다.
Add-WBVolume 볼륨을 백업 정책에 추가합니다.
Get-WBBackupTarget 정책에서 백업 대상을 가져옵니다.
Get-WBDisk 모든 디스크를 가져옵니다.
Get-WBPolicy 현재 백업 정책을 가져옵니다.
Get-WBSchedule 정책에서 백업 일정을 가져옵니다.
Get-WBSummary 백업 기록과 요약을 가져옵니다.
Get-WBVolume 모든 볼륨을 가져옵니다.
New-WBBackupTarget 새 백업 대상을 만듭니다.
New-WBPolicy 빈 정책을 새로 만듭니다.
Remove-WBBackupTarget 정책에서 백업 대상을 제거합니다.
Remove-WBPolicy 백업 정책을 삭제합니다.
Remove-WBVolume 정책에서 볼륨을 제거합니다.
Set-WBPolicy WBPolicy 개체를 저장하여 예약된 백업을 만듭니다.
Set-WBSchedule 백업 정책에 일정을 설정합니다.

Windows Server 2008에는 Hyper-V VSS 작성기를 사용할 수 있고 스크립팅 옵션에 약간의 유연성을 더해주는 다른 유틸리티가 기본 제공됩니다. DiskShadow.exe를 사용하면 섀도 복사본을 만들어 드라이브로 탑재할 수 있으므로 관리자가 WSB를 사용할 때보다 더 선택적으로 백업을 만들 수 있습니다. DiskShadow는 Windows PowerShell 파이프라인 입력을 받지 않으므로 다음과 비슷한 형식으로 스크립트를 통해 명령을 전달해야 합니다.

Delete Shadows Volume C:
Set Context Persistent
Begin Backup 
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow 
Create
End Backup
Expose %MyShadow% X: 
Exit

이 스크립트는 먼저 드라이브 C:의 기존 섀도 복사본을 모두 삭제한 다음 DiskShadow가 실행된 후에 섀도 복사본이 유지되도록 합니다. 그런 다음 트랜잭션 블록을 만듭니다. 즉, 하나의 단계라도 실패하면 전체 프로세스가 실패합니다. 이 블록에서 DiskShadow는 Hyper-V의 작성기가 로드되었는지 확인하고 백업할 드라이브 목록에 드라이브 C:를 추가합니다.

드라이브 C:는 식별을 위한 GUID를 받고, 이 GUID는 "MyShadow"라는 환경 변수에 저장됩니다. 이 과정이 완료되면 섀도 복사본이 생성됩니다.

백업은 환경 변수를 사용하여 드라이브 X:로 노출됩니다. X:의 데이터에 대해 다양한 작업을 수행할 수 있으며 Unexpose X: 명령으로 DiskShadow를 다시 실행하여 드라이브를 제거할 수 있습니다.

DiskShadow를 통해 백업한 Hyper-V VM을 복원하는 과정은 현재로서는 수동 프로세스이므로 VM을 다시 만들어야 하고 스냅숏은 유지되지 않습니다. 여기에는 확실히 몇 가지 단점이 있지만 데이터는 보호됩니다.

요약

DR은 끝이 보이지 않는 험난한 프로세스가 될 수 있습니다. 그러나 서버 가상화를 사용하면 기술과 이 기술로 인한 저렴한 진입점 덕분에 새로운 가능성이 열리게 됩니다. Microsoft는 가상화뿐만 아니라 전체적인 환경을 제공합니다. 서버 가상화 플랫폼과 System Center 제품군은 DR을 포함하여 오늘날 조직이 당면한 날로 복잡해지는 과제에 대한 전체적인 솔루션을 제공합니다.

이 기사를 작성하는 데 도움을 준 James O'Neill에게 감사의 뜻을 전합니다.

Adam Fazio는 2년 전부터 Microsoft Consulting Services에서 업무를 시작했으며 현재는 공공 부문 업무를 당담하고 있습니다. 그는 IT 업계에서 10년 이상 활동하면서 Fortune 100대 기업부터 인터넷 업체에 이르기까지 다양한 인프라 프로젝트와 데이터 센터 운영에 참여했습니다. 현재는 Microsoft에서 글로벌 Virtualization Rapid Deployment 프로그램의 기술 강화 부문 책임자입니다.