다음을 통해 공유

Exchange 2007 데이터 백업 및 볼륨 섀도 복사본 서비스

  • 아티클

 

적용 대상: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

마지막으로 수정된 항목: 2012-03-26

Windows Server 2008의 VSS(볼륨 섀도 복사본 서비스)는 응용 프로그램에서 Microsoft Exchange Server 2007을 백업 및 복원하는 데 사용됩니다. VSS는 타사 저장소 관리 프로그램, 비즈니스 프로그램 및 하드웨어 공급자가 협력을 통해 섀도 복사본을 만들고 관리할 수 있도록 하는 인프라를 제공합니다. 이 인프라를 기반으로 하는 솔루션은 섀도(미러링) 복사본을 사용하여 하나 이상의 Exchange 2007 데이터베이스를 백업 및 복원할 수 있습니다.

VSS는 요청자(백업 응용 프로그램), 기록기(Exchange 2007과 같은 Windows의 응용 프로그램) 및 공급자(섀도 복사본을 만드는 시스템 구성 요소, 소프트웨어 구성 요소 또는 하드웨어 구성 요소) 간의 통신을 조정합니다. VSS를 사용하여 Exchange 2007을 백업하려면 백업 프로그램에 Exchange 2007 인식 VSS 요청자가 포함되어 있어야 합니다. Windows Server 2008의 일부분인 Windows Server 백업 프로그램에는 Exchange 인식 요청자가 포함되어 있지 않으므로

그러나 Exchange 2007 SP2(서비스 팩 2)에는 Windows Server 2008에서 Windows Server 백업을 사용하여 Exchange 데이터의 VSS(볼륨 섀도 복사본 서비스) 기반 백업을 만들 수 있는 새로운 플러그 인이 포함되어 있습니다. Windows Server 백업을 사용하여 Exchange 2007 SP2 데이터베이스를 백업 및 복원할 수 있습니다. 유능한 Exchange 관리자가 되려면 백업해야 하는 항목, 백업 저장 위치 및 백업 복원 방법을 완전히 이해하는 것이 중요합니다. Exchange 2007에서 백업해야 하는 항목에 대한 자세한 내용은 Windows Server 백업을 사용하여 Exchange 데이터 백업 및 복원을 참조하십시오.

참고

Windows Server 백업 프로그램에서는 Exchange 2007 Extensible Storage Engine 스트리밍 API를 지원하지 않으므로, 이 프로그램을 사용해 Exchange 2007의 스트리밍 ESE 백업을 수행할 수 없습니다.

Exchange 인식 VSS 백업은 활성 저장소 그룹 및 수동 저장소 그룹에 대해 모두 지원됩니다. Exchange 수동 복사본 백업 솔루션은 VSS 전용 솔루션으로, 복제 서비스의 일부분인 Exchange 복제본 VSS 기록기를 통해 구현됩니다. 스트리밍 백업은 활성 저장소 그룹에서만 지원됩니다. 따라서 스트리밍 백업 API를 사용하여 복제본 데이터베이스를 백업할 수 없습니다. 복제본 데이터베이스를 백업하려면 Exchange 기록기에 대해 VSS 요청자와 함께 VSS 인식 백업 프로그램을 사용해야 합니다.

참고

Exchange 2007 SP2의 Windows Server 백업 플러그 인에서는 복제 서비스에 포함된 Exchange 복제본 VSS 기록기를 사용할 수 없기 때문에, 저장소 그룹의 수동 복사본을 백업하는 데 이 플러그 인을 사용할 수 없습니다.

Exchange 2007에서는 동일한 Exchange 서버에 대해 별도의 두 VSS 백업 작업을 실행할 수 있습니다. 또한 Exchange 2007 기록기를 사용하면 Exchange 데이터를 다른 위치에 복원할 수 있습니다. 여기에는 복구 저장소 그룹도 포함됩니다. Exchange 2007 기록기를 통해 저장소 그룹과 연결되지 않은 폴더로 데이터베이스 파일을 복원할 수도 있습니다. 그런 다음 JET 데이터베이스 엔진을 사용하여 트랜잭션 로그 파일을 데이터베이스로 재생하면 데이터베이스를 일관성 있고 탑재 가능한 상태로 설정할 수 있습니다.

참고

Microsoft Exchange Server 2003에서는 스트리밍 백업 API를 사용하여 서로 다른 두 저장소 그룹에 대해 두 백업을 동시에 실행할 수 있습니다. 그러나 VSS를 사용하여 이러한 작업을 수행할 수는 없습니다. Exchange 2003에서는 첫 번째 저장소 그룹 백업이 끝날 때까지는 VSS를 사용해 두 번째 저장소 그룹을 백업할 수 없습니다. 또한 Exchange 2003 기록기에서는 Exchange 데이터를 원래 경로가 아닌 경로로 복원할 수 없습니다.

Exchange 2007의 규정을 준수하려면 VSS 기반 백업 프로그램은 다음과 같은 기본적인 요구 사항을 충족해야 합니다.

  • Exchange 기록기를 사용하여 파일을 백업해야 합니다.

    Exchange 2007에는 Exchange 저장소에서 기본 제공되는 기록기가 포함되어 있습니다.

  • 백업 프로그램에서 섀도 복사본 백업 세트의 유효성을 검사해야 합니다.

  • 파일을 원래 위치로 복원하는 모든 복원 작업에 대해 Exchange 기록기를 사용해야 합니다.

    원래 위치란 VSS 백업이 수행된 서버와 이름 및 파일 경로가 같은 Exchange 서버를 가리킵니다.

이러한 요구 사항을 따르면 섀도 복사본 백업의 무결성 및 복구 기능을 보장할 수 있습니다. 이러한 요구 사항이 충족되지 않으면 Microsoft CSS(고객 서비스 및 지원 부서)에서는 백업 솔루션이 Exchange VSS 프레임워크에 내에 있지 않는 것으로 간주합니다. 이 경우에는 Microsoft CSS에서 백업 또는 복원 문제를 해결할 수 없습니다. 백업 솔루션 공급업체에 문의하여 백업 프로그램이 이 항목에 나와 있는 요구 사항을 충족하는지를 확인하는 것이 좋습니다. 이러한 요구 사항에 대한 자세한 내용은 이 항목 뒷부분의 "Exchange 2007 VSS 요구 사항"을 참조하십시오.

참고

사용자가 경험하는 백업 또는 복구 문제에 대해서는 기본적으로 타사 백업 프로그램 공급업체에서 지원을 제공합니다. Microsoft CSS에서는 Exchange 데이터베이스 또는 트랜잭션 로그 파일과 관련된 문제를 진단하거나 해결하도록 도울 수 있습니다. 그러나 Microsoft CSS의 지원 범위는 Exchange 환경에서 사용 가능한 데이터베이스 파일 및 트랜잭션 로그 파일 복구하도록 돕는 것으로 제한됩니다.

Microsoft CSS에서 VSS 기반 솔루션을 지원하는 방법에 대한 자세한 내용은 Microsoft 기술 자료 문서 841696, Overview of the Microsoft third-party storage software solutions support policy(영문)를 참조하십시오.

자세한 내용

Exchange 2007 VSS 요구 사항

다음 섹션에서는 Exchange 데이터베이스의 무결성 및 복구 기능을 보장하기 위해 모든 섀도 복사본 백업 프로그램에서 따라야 하는 Exchange 2007 요구 사항에 대해 설명합니다. 이 섹션에는 백업 프로그램이 Exchange 요구 사항을 충족하는지 여부를 확인하는 데 도움이 되는 특정 응용 프로그램 이벤트가 나와 있습니다. 백업 프로그램 및 Exchange 서버에서는 백업 및 복원 프로세스와 연관된 다른 이벤트도 기록할 수 있습니다. Exchange VSS 요구 사항을 준수하는지 확인하려면 백업 및 복원 작업 중에 이벤트가 기록되는지 확인합니다.

현재는 Exchange에서 실행되는 타사 백업 솔루션에 사용할 수 있는 인증 프로그램이 없습니다. VSS의 규정을 준수하면 섀도 복사본 백업의 무결성 및 복구 기능을 보장할 수 있습니다. 그러나 타사 솔루션의 성능이나 안정성이 보장되는 것은 아닙니다.

Exchange 기록기를 사용하여 파일을 백업해야 함

Exchange 데이터베이스 파일, 트랜잭션 로그 파일 및 검사점 파일은 Exchange 기록기를 통해서만 백업해야 합니다. 섀도 복사본 백업 중에 Exchange 기록기를 사용하는 경우 응용 프로그램 로그에 다음 이벤트가 기록됩니다.

이벤트 유형: 정보

이벤트 원본: ESE

이벤트 범주: 섀도 복사본

이벤트 ID: 2005

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: 정보 저장소(2884) 섀도 복사본 인스턴스 5을(를) 시작합니다. 백업 유형 섀도 복사본을 만듭니다.

참고

이 이벤트에서 백업 유형은 수행 중인 백업 종류를 나타냅니다. 예를 들어 백업 유형은 전체, 복사본, 증분 또는 차등입니다.

이벤트 유형: 정보

이벤트 원본: MSExchangeIS

이벤트 범주: Exchange VSS 기록기

이벤트 ID: 9608

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: Exchange VSS 기록기(인스턴스 GUID)에서 스냅숏을 수행할 준비가 되었습니다.

이벤트 유형: 정보

이벤트 원본: MSExchangeIS

이벤트 범주: Exchange VSS 기록기

이벤트 ID: 9610

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: Exchange VSS 기록기(인스턴스 GUID)가 저장소 그룹을 고정했습니다.

이벤트 유형: 정보

이벤트 원본: MSExchangeIS

이벤트 범주: Exchange VSS 기록기

이벤트 ID: 9612

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: Exchange VSS 기록기(인스턴스 GUID)가 저장소 그룹을 고정 취소했습니다.

백업 프로그램에서 섀도 복사본 백업 세트의 무결성을 확인해야 함

백업 프로그램에서 백업이 완료되었음을 Exchange에 알리기 전에 섀도 복사본 백업 세트의 무결성을 확인하는 것이 좋습니다. 그 이유는 다음과 같습니다.

백업이 완료된 후에 Exchange에서는 다음의 두 작업을 수행합니다.

  • Exchange는 마지막 백업 시간을 나타내기 위해 백업된 데이터베이스 헤더를 업데이트합니다.

  • Exchange는 트랜잭션 로그를 자릅니다. 이 시나리오에서는 Exchange가 마지막 백업에서 롤포워드하는 데 더 이상 필요하지 않은 트랜잭션 로그 파일을 제거합니다.  

따라서 Exchange에서 위의 두 작업을 수행할 때까지 백업 프로그램이 무결성 확인을 연기하는 경우에는 마지막으로 확인된 백업을 해당 백업에 필요한 모든 트랜잭션 로그 파일 복사본과 함께 보관해야 합니다. Exchange에 백업이 이미 완료되었다고 보고했더라도 백업 프로그램에서 무결성 확인 작업을 완료할 때까지는 백업을 완전히 신뢰해서는 안 됩니다.

무결성 검사를 수행하는 방법과 보관해야 할 데이터베이스 파일 및 트랜잭션 로그 파일을 확인하는 방법에 대한 자세한 내용은 이 항목 뒷부분의 "VSS 백업을 위한 무결성 확인"을 참조하십시오.

원래 위치로 복원하는 모든 복원 작업에 Exchange 기록기를 사용해야 함

Exchange 관련 파일을 원래 위치로 복원하는 모든 복원 작업에는 Exchange 기록기만을 사용해야 합니다. 원래 위치란 VSS 백업이 수행된 Exchange 서버와 이름 및 파일 경로가 같은 Exchange 서버입니다.

Exchange 기록기는 섀도 복사본 복원 작업 중에 응용 프로그램 로그에 다음 이벤트를 기록합니다.

이벤트 유형: 정보

이벤트 원본: MSExchangeIS

이벤트 범주: Exchange VSS 기록기

이벤트 ID: 9620

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: Exchange VSS 기록기(인스턴스 GUID)에서 복원 전 이벤트를 처리했습니다.

이벤트 유형: 정보

이벤트 원본: MSExchangeIS

이벤트 범주: Exchange VSS 기록기

이벤트 ID: 9618

사용자: 해당 없음

컴퓨터: 서버 이름.contoso.com

일반: Exchange VSS 기록기(인스턴스 GUID)에서 복원 후 이벤트를 처리했습니다.

VSS 백업을 위한 무결성 확인

Exchange 스트리밍 백업 API를 사용하여 데이터베이스를 백업할 때는 데이터베이스의 각 페이지를 차례로 읽으며 백업 프로세스 중에 각 페이지의 체크섬 무결성이 확인됩니다. 트랜잭션 로그 파일의 체크섬 무결성 역시 트랜잭션 로그 파일이 백업되기 전에 확인됩니다.

그러나 VSS 백업 중에는 Exchange에서 각 데이터베이스 파일을 읽고 체크섬 무결성을 확인할 수 없습니다. 따라서 백업 프로그램에서 데이터베이스 및 트랜잭션 로그 파일 무결성을 확인해야 합니다. Eseutil 명령을 실행하면 이러한 확인 작업을 수행할 수 있습니다.

VSS 백업의 체크섬 확인을 수행하지 않으면 데이터베이스에 손상된 페이지가 검색되지 않고 남아 있을 수 있습니다. 그러면 사용 가능한 모든 백업에 손상된 페이지가 포함될 수 있습니다. 이 경우 유일한 문제 해결 방법은 데이터베이스를 복구하는 것입니다. 데이터베이스를 복구하면 가동 중지 시간이 길어지고 일부 데이터가 손실될 수 있습니다. 즉, 손상된 각 데이터베이스 페이지의 데이터가 손실됩니다.

그러나 마지막 VSS 백업에 포함된 페이지가 모두 정상임을 확인하면 데이터베이스에서 손상된 페이지를 제거할 수 있습니다. 이렇게 하려면 확인된 백업을 복원한 다음 정상적인 백업이 수행된 후에 만든 트랜잭션 로그를 사용하여 백업을 롤포워드합니다. 이 작업에 필요한 가동 중지 시간은 일반적으로 데이터베이스 복구 작업에 필요한 시간보다 훨씬 짧습니다. 또한 이러한 종류의 복구 작업을 수행할 때는 데이터가 손실되지 않습니다. 따라서 백업의 모든 파일에 대해 체크섬 확인을 수행할 때까지는 VSS 백업이 완료되었다고 간주해서는 안 됩니다.

백업 무결성을 확인할 때는 다음의 두 가지 규칙을 사용하는 것이 좋습니다.

  • 무결성을 확인한 데이터베이스 파일 복사본은 항상 보관해야 합니다. 무결성을 확인한 백업이란 백업 세트의 데이터베이스 파일에 대해 페이지 체크섬 확인을 완료한 백업입니다.

  • 무결성을 확인한 최신 데이터베이스 파일을 복구하는 데 필요한 모든 트랜잭션 로그 파일을 백업해야 합니다. 또한 트랜잭션 로그 파일의 체크섬 수준 무결성을 확인해야 합니다.

필요한 트랜잭션 로그에는 최소한 마지막으로 확인한 백업에 포함된 각 데이터베이스 파일 헤더의 Log Required 필드에 나와 있는 로그 파일을 포함하는 범위가 포함됩니다. 이러한 로그 파일을 사용할 수 없는 경우에는 데이터베이스를 복원 후에 탑재할 수 없습니다.

중요

이러한 요구 사항은 최신 백업이 아닌 마지막으로 무결성을 확인한 백업에 적용됩니다. 최신 백업은 체크섬 확인을 통과할 때까지는 유효한 백업으로 간주되지 않습니다.

원하는 경우에는 데이터베이스를 복원 후 완전히 롤포워드하는 데 필요한 추가 트랜잭션 로그 파일도 보관할 수 있습니다. 여기에는 최하위 Log Required 파일에서 Exchange 서버로부터 제거된 가장 최근에 만든 트랜잭션 로그까지 끊기지 않은 시퀀스에 있는 모든 트랜잭션 로그 파일이 포함됩니다. 이러한 파일의 예제와 설명은 아래에 나와 있습니다.

Log Required 범위에 포함되어 있지 않은 트랜잭션 로그 파일도 원하는 경우에는 보관할 수 있습니다. 단, 이는 백업된 데이터베이스를 복원 및 탑재하기 위해 이러한 로그 파일을 반드시 보관해야 하는 상황이 아닌 경우에만 해당됩니다. 그러나 필요한 로그 파일 중 일부를 보관하지 않은 상태로 백업에서 복원하면, 백업을 수행한 후 데이터베이스에 대해 변경한 모든 내용이 손실됩니다.

백업된 데이터베이스를 복원 및 탑재하는 데 필요한 트랜잭션 로그 파일과 데이터베이스를 롤포워드하는 데 필요한 모든 후속 트랜잭션 로그 파일은 반드시 보관하는 것이 좋습니다.

필요한 트랜잭션 로그 파일 확인

Exchange 데이터베이스가 온라인 상태일 때 백업하는 경우 최소한 하나의 트랜잭션 로그 파일이 항상 함께 백업됩니다. 이 동작은 스트리밍 백업 API를 사용하든 VSS 백업 API를 사용하든 관계없이 수행됩니다.

온라인 백업을 복원한 후에는 트랜잭션 로그의 정보를 데이터베이스에 적용해야 합니다. 이 작업을 트랜잭션 로그 파일 재생이라고 합니다. 각 데이터베이스 헤더의 Log Required 필드에는 데이터베이스로 재생해야 하는 트랜잭션 로그 파일 범위의 시퀀스(세대) 번호가 기록됩니다.

Log Required 필드에 0-0이 표시되면 트랜잭션 로그 데이터를 추가로 재생하지 않고도 데이터베이스를 탑재할 수 있습니다. Log Required 값이 0-0이 되는 유일한 시기는 데이터베이스가 완전한 종료 상태로 들어간 이후입니다. 데이터베이스가 실행 중인 동안에는 Log Required 필드에 아직 데이터베이스에 적용되지 않은 트랜잭션 로그 범위가 항상 기록됩니다. 이 범위는 계속해서 업데이트됩니다.

온라인 상태에서 백업되는 데이터베이스는 항상 0이 아닌 Log Required 범위를 가집니다. 따라서 데이터베이스와 함께 해당하는 트랜잭션 로그 파일을 백업해야 합니다. 데이터베이스를 복원한 후에 로그 파일을 사용할 수 없으면 데이터베이스를 탑재할 수 없게 됩니다. 필요한 로그 파일을 얻을 수 없는 경우에는 데이터베이스 복구 작업을 수행해야 합니다. 그러나 데이터베이스 복구 작업이 제대로 수행된다는 보장이 없으며, 손실 범위가 누락된 로그 파일의 데이터로 한정된다고 해도 데이터베이스 복구 작업에는 항상 일정 수준의 데이터 손실이 따릅니다.

Exchange 기록기에 포함된 Exchange 스트리밍 백업 API 또는 VSS 백업 API를 사용하는 경우 데이터베이스를 탑재하는 데 필요한 로그 파일은 데이터베이스와 함께 자동으로 백업됩니다. Log Required 필드에 지정된 로그 파일만 재생하는 경우에는 백업이 완료된 시점까지 데이터베이스가 복원됩니다. 해당 시점을 초과하여 데이터베이스를 롤포워드하려는 경우에는 백업이 완료된 후에 생성된 로그 파일도 재생해야 합니다.

특정 백업으로부터 데이터베이스를 완전히 롤포워드하려면 Log Required 범위의 최하위 로그에서 데이터베이스 저장소 그룹에서 가장 최근에 생성된 로그 파일까지 끊기지 않은 시퀀스에 있는 모든 로그 파일을 보관해야 합니다. 이 로그 시리즈에서 로그가 하나라도 누락되거나 손상되면 누락되거나 손상된 파일 앞의 마지막 정상 로그 파일 시점까지만 롤포워드할 수 있습니다.

따라서 백업에서 복구할 때 데이터가 손실되지 않도록 하려면 마지막으로 확인된 정상 데이터베이스 백업에서 시작하여 모든 트랜잭션 로그 파일의 정상 복사본을 보관해야 합니다.

트랜잭션 로그 자르기

Exchange 서버에서 트랜잭션 로그 파일을 제거하지 않으면 사용 가능한 디스크 공간이 가득 찰 때까지 로그 파일이 누적됩니다. 따라서 스트리밍 백업 API와 VSS 백업 API는 모두 일반 백업 또는 증분 백업이 완료된 후에 트랜잭션 로그 파일 잘라내기를 지원합니다. 백업 프로그램에서 백업 작업이 완료되었음을 Exchange에 알리고 나면 최신 백업을 복구하는 데 필요한 것보다 오래된 로그 파일은 서버에서 자동으로 삭제됩니다.

스트리밍 API를 사용하는 경우 백업 프로세스 중에 데이터베이스의 체크섬 확인이 수행됩니다. 백업 작업이 완료될 때까지 전체 데이터베이스 및 필요한 로그 파일의 실제 무결성이 검사됩니다. VSS API를 사용하는 경우에는 실제 백업 프로세스의 일부분으로 체크섬 확인을 수행할 수 없으며 백업 프로그램 공급업체에서 백업 프로세스와는 독립적으로 데이터베이스의 실제 무결성을 확인해야 합니다. 이러한 확인 작업은 백업 작업 전이나 프로그램에서 백업 작업이 완료되었음을 Exchange에 알린 후에 Eseutil 명령을 사용하여 수행할 수 있습니다.

  • 백업이 완료되기 전에 체크섬 확인을 수행하여 백업 세트에서 문제가 발견되면 백업이 실패했음을 Exchange에 알립니다. 그러면 Exchange에서 서버의 트랜잭션 로그 파일 자르기를 중지합니다.

  • 백업 완료 알림이 있을 때까지 체크섬 확인을 연기하는 경우에는 Exchange에서 서버의 오래된 로그 파일을 삭제합니다. 이러한 로그 파일 중 일부는 이전의 정상 백업에서 롤포워드하는 데 필요할 수 있습니다. 아직 이러한 로그 파일 복사본을 만들지 않은 경우에는 완전히 롤포워드하지 못할 수도 있습니다.

백업 프로그램이 Exchange에 백업이 완료되었음을 알리기 전에 VSS 백업에 대해 체크섬 확인을 수행하는 것이 좋습니다. 백업이 완료될 때까지 체크섬 확인을 연기하는 경우, Exchange를 완전히 롤포워드해야 한다면 백업 프로그램은 잘린 모든 트랜잭션 로그 파일의 복사본을 보관해야 합니다.

대부분의 경우 VSS 백업을 롤포워드하는 데 필요한 모든 트랜잭션 로그 파일은 이전 백업과 함께 저장된 로그 파일 집합에서 사용할 수 있으며, 현재 백업과 함께 저장되는 로그 파일도 사용할 수 있습니다. 그러나 백업 솔루션을 선택할 때 로그 파일 사용 가능 여부를 확인해야 합니다.

확인되지 않은 백업 복원

백업에 대해 체크섬 확인이 수행되기 전에 백업에서 데이터베이스를 복원해야 하는 경우가 있습니다. 이러한 경우에는 이전에 확인된 백업에서 데이터베이스를 복원한 다음 해당 백업을 롤포워드하는 것이 좋습니다. 확인되지 않은 백업을 사용하는 것보다는 이 방법이 효율적입니다.

그러나 이전 백업에서 수행할 수 있는 것보다 빨리 데이터를 복원해야 하는 서비스 수준 계약의 적용을 받는 경우도 있습니다. 이 경우에는 확인되지 않은 백업에서 복원하는 것이 보다 효율적일 수 있습니다. 단, 이렇게 하려면 이전 백업에서 완전히 롤포워드하는 데 필요한 모든 로그 파일과 함께 이전에 확인된 백업을 보관해 두었어야 합니다. 그러면 확인되지 않은 백업이 손상된 경우 확인된 정상 백업에서 롤포워드할 수 있습니다.

스냅숏 일관성 확인

VSS 요청자는 스냅숏 일관성을 확인해야 합니다. 또한 Exchange 팀의 지원을 받아야 하는 백업 솔루션에 대해서도 스냅숏 일관성을 확인해야 합니다. Exchange 2007에서는 스냅숏 일관성 검사를 위한 다음의 두 가지 방법을 지원합니다.

  • CHKSGFILES API

  • Eseutil 명령줄 도구

CHKSGFILES API를 사용하여 스냅숏 일관성을 확인하는 방법에 대한 자세한 내용은 Validating Backup Integrity By Using CHKSGFILES(영문)를 참조하십시오.

Eseutil 명령줄 도구를 사용하여 스냅숏 일관성을 확인하는 방법에 대한 자세한 내용은 Validating Backup Integrity By Using Eseutil(영문)을 참조하십시오.

볼륨 섀도 복사본 서비스 문제 해결

기본적으로 VSS는 Windows Server 2008과 함께 설치되며 수동 시작 유형으로 설정됩니다. 백업 프로그램(요청자)이 VSS 기록기를 하나 이상 사용할 수 있으면 서비스가 시작됩니다.

Exchange 2007 VSS 백업과 관련하여 발생할 수 있는 문제를 해결할 때 다음 항목을 사용할 수 있습니다.

  • 이벤트 로그 정보

  • VSSADMIN 명령

  • 진단 로깅

  • Exchange Extra 도구

  • BETest 도구

이벤트 로그 정보

다음 단계에서는 VSS와 기록되는 해당 이벤트를 함께 사용하는 경우 수행되는 Exchange 2007 백업 프로세스에 대해 설명합니다. 백업 작업 중에 기록되는 이벤트를 검사하면 오류가 발생하는 구성 요소를 확인하는 데 도움이 됩니다.

1단계: 데이터베이스 준비

  1. 백업 프로그램(에이전트)이 예약된 작업을 실행합니다.

  2. 백업 프로그램의 VSS 요청자가 VSS로 요청을 전송하여 스냅숏 백업을 수행하도록 선택한 Exchange 저장소 그룹을 준비합니다.

  3. VSS는 Exchange VSS 기록기에 스냅숏 백업을 준비하라는 신호를 보냅니다.

다음 표에는 시작되는 모든 백업 인스턴스에 대해 응용 프로그램 로그에 기록되는 일련의 이벤트 목록이 나와 있습니다.

이벤트 ID 이벤트 유형 이벤트 원본 일반

9604

정보

MSExchangeIS

Exchange VSS 기록기가 백업 또는 복원을 준비하기 위해 메타데이터 문서를 수집했습니다.

9818

정보

MSExchangeIS

"EcPrepareSGForBackup"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

데이터:

0000: 54 68 69 72 64 20 53 74 세 번째

0008: 6f 72 61 67 65 20 47 72 저장소 그룹.

9811

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 56)가 저장소 그룹 '세 번째 저장소 그룹'의 전체 또는 복사 백업에 필요한 데이터베이스 엔진을 준비했습니다. 다음 1 데이터베이스가 탑재된 후 백업됩니다.

세 번째 저장소 그룹

데이터:

0000: 46 75 6c 6c 00 전체.

9606

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27)에서 백업을 수행할 준비가 되었습니다.

9818

정보

MSExchangeIS

"CVssIExchWriter::OnPrepareSnapshot"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

9608

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)에서 스냅숏을 수행할 준비가 되었습니다.

2005

정보

ESE

정보 저장소(2256) 섀도 복사본 인스턴스 56을(를) 시작합니다. 전체 섀도 복사본을 만듭니다.

2단계: 데이터베이스 스냅숏

Exchange 기록기에서 백업 준비가 완료되었음을 VSS에 보고하면 다음 작업이 수행됩니다.

  1. Exchange 기록기가 해당하는 Exchange 데이터베이스를 고정합니다. 이 시나리오에서 Exchange는 다음 작업을 수행합니다.

    • Exchange는 특정 저장소 그룹에 대해 관리 작업을 금지합니다.

    • Exchange는 저장소 그룹에 대한 볼륨 종속성을 검사합니다.

    • Exchange는 해당하는 데이터베이스 파일 및 트랜잭션 로그 파일에 대한 모든 쓰기 작업을 일시 중단합니다.

      참고

      Exchange는 데이터베이스 파일 및 트랜잭션 로그 파일에 대한 읽기 액세스를 계속 허용합니다.

  2. Exchange에서는 Exchange 데이터베이스 파일 및 트랜잭션 로그 파일 고정 작업을 시작함과 동시에 데이터베이스 스냅숏 복사본을 만드는 데 걸리는 시간을 추적하는 작업자 스레드도 시작합니다. 복사 프로세스는 10초를 초과하여 수행될 수 없습니다.

전체 스냅숏 복사 프로세스는 70초를 초과할 수 없습니다. 여기에는 "2단계: 데이터베이스 스냅숏" 프로세스에서 수행되는 모든 작업이 포함됩니다. 전체 프로세스가 70초를 초과하면 작업자 스레드의 시간 제한이 초과됩니다. 시간 제한이 초과되면 Exchange에서 백업 작업을 중지하고 Exchange 저장소 그룹 고정을 취소합니다. 그런 다음 Exchange에서 일반 작업을 계속합니다.

다음 표에는 스냅숏 작업 중에 응용 프로그램 로그에 기록되는 일련의 이벤트 목록이 나와 있습니다.

이벤트 ID 이벤트 유형 이벤트 원본 일반

2001

정보

MSExchangeIS

MSExchangeIS(2256) 세 번째 저장소 그룹: 섀도 복사본 인스턴스 56 고정을 시작했습니다.

9818

정보

MSExchangeIS

"CVssIExchWriter::OnFreeze"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

9610

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 저장소 그룹을 고정했습니다.

9818

정보

MSExchangeIS

"CVssIExchWriter::OnThaw"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

2003

정보

ESE

정보 저장소(2256) 섀도 복사본 인스턴스 56 고정을 끝냈습니다.

9612

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 저장소 그룹을 고정 취소했습니다.

9818

정보

MSExchangeIS

"CVssIExchWriter::OnPostSnapshot"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

3단계: 섀도 복사본 확인

백업 프로그램의 VSS 요청자가 섀도 복사본의 상태를 확인합니다. 그런 다음 프로그램에서 백업 성공 여부를 Exchange에 알립니다. 이 작업은 백업 작업 완료를 알리는 것입니다. backupInProgress 플래그를 다시 설정하는 데 OnBackupComplete() 메서드가 사용됩니다.

다음 표에는 백업 완료 중에 응용 프로그램 로그에 기록되는 일련의 이벤트 목록이 나와 있습니다.

이벤트 ID 이벤트 유형 이벤트 원본 일반

9818

정보

MSExchangeIS

"CVssIExchWriter::OnBackupComplete"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

9818

정보

MSExchangeIS

"EcSGBackupComplete"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

데이터:

0000: 54 68 69 72 64 20 53 74 세 번째 저장소 그룹.

9780

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 저장소 그룹 '세 번째 저장소 그룹'의 전체 또는 증분 백업을 완료했습니다.

2006

정보

ESE

정보 저장소(2256) 섀도 복사본 인스턴스 56을(를) 완료했습니다.

9616

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)에서 백업 완료 이벤트를 처리했습니다.

백업 작업을 끝내면 Exchange 기록기가 OnBackupShutdown() 메서드를 호출합니다. 이 메서드를 사용하여 백업 작업을 마친 후에 백업 프로그램을 끝낼 때 필요한 작업을 수행합니다.

오류가 발생하는 경우 OnBackupShutdown() 메서드는 Exchange 기록기 상태를 실패로 설정합니다.

다음 표에는 BackupShutdown 이벤트 중에 응용 프로그램 로그에 기록되는 일련의 이벤트 목록이 나와 있습니다.

이벤트 ID 이벤트 유형 이벤트 원본 일반

9818

정보

MSExchangeIS

"CVssIExchWriter::OnBackupShutdown"에 대해 Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)가 호출되었습니다.

9648

정보

MSExchangeIS

Exchange VSS 기록기(인스턴스 097f686a-7ffb-4903-935f-1b1b1a0d3a27:56)에서 백업 종료 이벤트를 처리했습니다.

백업 오류가 발생하면 다음의 두 함수가 호출됩니다.

  • CVssIExchWriter::OnAbort()

    이 메서드는 섀도 복사본 작업이 중간에 종료되었음을 나타냅니다. Exchange 기록기는 이 메서드를 사용하여 Exchange 기록기를 정리하고 JET 데이터베이스에 정보 저장소를 고정 취소(해제)하도록 지시합니다. 또한 Exchange 기록기는 이 메서드를 사용하여 스냅숏이 중지되었음을 JET 데이터베이스에 알립니다.

  • CVssIExchWriter::EcBackupCleanup()

    백업이 실패한 경우 Exchange에서는 이 메서드를 사용하여 백업 실패 후 정리 작업을 수행합니다. Exchange에서는 스냅숏에 오류가 발생했음을 JET 데이터베이스에 알리는 데 이 메서드를 사용합니다. 또한 Exchange에서는 이 메서드를 사용하여 스냅숏에 오류가 발생했음을 정보 저장소에 알립니다.

4단계: 트랜잭션 로그 자르기

백업이 완료되면 Exchange에서는 다음 작업을 수행합니다.

  • Exchange는 트랜잭션 로그 파일을 자릅니다.

    참고

    Exchange 백업을 수행하지 않고 대신 Exchange 데이터베이스 파일이 포함된 볼륨의 스냅숏 백업을 만드는 경우에는 백업이 Exchange 백업과 같은 방식으로 처리됩니다. 그러나 이 경우 백업은 복사본 백업으로 간주되며 트랜잭션 로그는 잘리지 않습니다.

  • Exchange는 해당하는 Log Required 필드 정보를 사용하여 데이터베이스 헤더를 업데이트합니다.

  • Exchange는 백업 진행 중 상태를 지웁니다.

  • Exchange는 해당하는 데이터베이스에 대해 마지막 백업 시간을 기록합니다.

VSSADMIN 명령

VSS 관리 명령줄 도구(VSSADMIN)를 사용하여 VSS에 등록된 기록기 및 공급자에 대한 정보를 얻을 수 있습니다.

VSS 기록기에 대한 정보를 얻으려면 다음 단계를 수행합니다.

  1. Exchange 서버에서 시작, 실행을 차례로 클릭하고 cmd를 입력한 다음 확인을 클릭합니다.

  2. 명령 프롬프트에서 vssadmin list writers를 입력한 다음 Enter 키를 누릅니다.

    반환되는 결과를 확인하여 Exchange 기록기 결과를 찾습니다. Exchange 기록기가 안정적인 상태여야 합니다. Exchange 기록기가 안정적인 상태이면 다음과 같은 결과가 반환됩니다.

    기록기 이름: 'Microsoft Exchange 기록기'

    기록기 ID: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}

    기록기 인스턴스 ID: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}

    상태: [1] 안정적

    마지막 오류: 오류 없음

    상태 값이 안정적 이외의 다른 값이면 Microsoft Exchange 정보 저장소 서비스를 다시 시작합니다. Exchange 기록기 상태가 실패인 경우에는 다음과 같은 결과가 반환됩니다.

    기록기 이름: 'Microsoft Exchange 기록기'

    기록기 ID: {76fe1ac4-15f7-4bcd987e-8e1acb462fb7}

    기록기 인스턴스 ID: {977637c2-fcdd-463e-b1f8-a9a5d603a2e8}

    상태: [14] 실패

    마지막 오류: 다시 시도 가능한 오류

  3. 등록된 VSS 공급자에 대한 정보를 얻으려면 명령 프롬프트에 vssadmin list providers를 입력합니다. 그러면 다음과 같은 결과가 표시됩니다.

    공급자 이름: 'Microsoft 소프트웨어 섀도 복사본 공급자 1.0'

    공급자 종류: System

    공급자 ID: {b5946137-7b9f-4925-af80-51abd60b20d5}

    버전: 1.0.0.7

    기본적으로는 Microsoft 소프트웨어 섀도 복사본 공급자만 나열됩니다. 그러나 타사 백업 프로그램이 설치되어 있는 경우에는 다른 공급자도 나열될 수 있습니다.

참고

사용 가능한 명령에 대한 자세한 내용을 보려면 명령 프롬프트에 vssadmin /?를 입력합니다.

진단 로깅

Exchange 기록기 때문에 문제가 발생하는 것 같다면 Exchange 기록기에 대해 진단 로깅을 사용하도록 설정합니다. 이렇게 하려면 다음 단계를 수행합니다.

  1. Exchange 관리 셸을 시작합니다.

  2. 다음 명령을 실행합니다.

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level expert

  3. Exchange 기록기의 로깅 수준을 확인하려면 다음 명령을 실행합니다.

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"}

  4. 진단 로깅 수준을 기본 수준으로 복원하려면 다음 명령을 실행합니다.

    get-eventloglevel | where-object {$_.identity -like "*Exchange Writer*"} | set-eventloglevel -level Lowest

Exchange 2007 Extra 도구

Exchange 2007에 포함된 Troubleshooting Assistant(Extra) 도구를 사용하여 Exchange 기록기를 추적할 수 있습니다. 이렇게 하려면 다음 단계를 수행합니다.

  1. Exchange 서버에서 시작, 실행을 차례로 클릭하고 extra를 입력한 다음 확인을 클릭합니다.

  2. 이전에 프로그램을 실행한 적이 없는 경우에는 Microsoft 사용자 환경 개선 프로그램에 참가 또는 지금은 프로그램에 참여하지 않음을 클릭합니다.

  3. 작업 창에서 작업 선택을 클릭합니다.

  4. 작업 선택 문제 해결 화면에서 추적 제어를 클릭합니다.

  5. 다음 메시지가 표시되면 확인을 클릭합니다.

    이 서버에는 추적을 해석하는 데 필요한 모듈이 없습니다. 자격이 있는 Exchange 지원 엔지니어의 직접 감독 하에 이 문제를 해결하는 경우에만 계속하십시오.

  6. 추적 파일 위치 선택 상자에 표시되는 경로를 확인합니다.

  7. 수동 추적 태그 설정을 클릭합니다.

  8. 추적할 구성 요소 목록에서 저장소를 클릭하되 저장소 확인란을 클릭하여 선택하지는 않습니다.

  9. 추적 태그 목록에서 tagVSS 확인란을 클릭하여 선택합니다.

  10. 추적 시작을 클릭합니다.

BETest 도구

BETest 도구를 사용하여 타사 VSS 요청자로 인해 문제가 발생하는지 여부를 확인할 수 있습니다.

BETest 도구는 Exchange VSS 기록기를 테스트하는 데 사용할 수 있는 테스트 요청자로, Microsoft VSS API를 사용하여 Exchange 기록기와 통신하고 기록기를 테스트합니다. BETest 도구는 일반적인 VSS 요청자가 수행하는 많은 작업을 수행할 수 있습니다. BETest 도구를 사용하여 Exchange 저장소 그룹의 VSS 백업을 수행할 수 있습니다. BETest는 Exchange 2007 서버에 있는 활성 데이터베이스 또는 복제본 데이터베이스의 VSS 스냅숏을 수행할 수 있습니다.

이 도구를 얻으려면 VSS SDK 버전 7.2를 다운로드하여 설치합니다. 이 SDK를 얻으려면 Volume Shadow Copy Service SDK 7.2(영문)를 참조하십시오.

BETest i386 버전은 기본적으로 다음 경로에 설치됩니다.

C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\i386

참고

BETest AMD64 버전도 사용 가능합니다. BETest를 실행하기 전에 해당하는 운영 체제 버전이 포함된 디렉터리로 이동합니다.

BETest를 사용하려면 다음 단계를 수행합니다.

  1. 명령 프롬프트를 열고 운영 체제의 해당하는 디렉터리로 이동합니다. 예를 들어 C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 디렉터리로 이동합니다.

  2. 사용 가능한 VSS 기록기를 확인합니다. 이렇게 하려면 betest.exe >AvailableWriters.txt를 입력합니다.

  3. BETest에 사용할 Components.txt 파일을 만듭니다. 이렇게 하려면 다음 단계를 수행합니다.

    1. 메모장 등의 텍스트 편집기를 사용하여 AvailableWriters.txt 파일을 엽니다.

    2. Microsoft Exchange Writer 섹션을 찾습니다. 메모장에서 F3 키를 누르고 찾을 내용 상자에 Microsoft Exchange Writer를 입력한 다음 다음 찾기를 클릭합니다.

    3. WriterName = Microsoft Exchange Writer 섹션에 나와 있는 정보를 사용하여 Components.txt 파일을 채웁니다. 이 파일의 형식은 다음과 같습니다.

      "<WriterIdGUID>": "<component-logical-path>" {"target" # "new target", ...}, ..."<component-logical-path>" : "<subcomponent-logical-path>,...";

      이 파일에서 <component-logical-path>는 LogicalPath 항목 또는 구성 요소 GUID가 포함된 LogicalPath 항목을 나타내거나, LogicalPath 값이 없는 경우 구성 요소 GUID만을 나타냅니다. 구성 요소 GUID는 특정 저장소 그룹을 나타냅니다. 예를 들어 <component-logical-path> 항목은 "Microsoft Exchange Server\Microsoft Information Store\서버 이름\000dd565-c4e8-4f58-a8b1-2e29eee4f5c0"일 수 있습니다.

      다음은 샘플 Components.txt 파일입니다.

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\서버 이름\999dd565-c4e8-4f58-a8b1-2e29eee4f5c0 ";

      이 예제에서 첫 번째 GUID는 Exchange 기록기의 GUID입니다. 이 GUID는 수정할 수 없습니다. 두 번째 GUID는 특정 저장소 그룹에 속합니다. 명령을 실행할 저장소 그룹을 지정하려면 해당하는 저장소 그룹의 GUID를 지정하면 됩니다. 특정 저장소 그룹의 GUID를 얻으려면 Get-StorageGroup '<StorageGroupName>' | fl GUID cmdlet를 실행합니다.

      Exchange에서는 활성 저장소 그룹에 대한 스트리밍 백업만 지원합니다. 따라서 수동 저장소 그룹을 백업하려면 VSS 백업을 사용해야 합니다. Exchange CCR(클러스터 연속 복제) 클러스터가 있거나 LCR(로컬 연속 복제) 사용이 가능한 서버에서 복제본 복사본을 백업하려는 경우에는 Components.txt 파일이 다음 예제 중 하나와 같아야 합니다.

      CCR 수동 복사본의 경우

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<클러스터된 사서함 서버 이름>\<저장소 그룹 GUID>";

      LCR 수동 복사본의 경우

      "{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\<서버 이름>\<저장소 그룹 GUID>";

  4. Components.txt 파일을 만든 후에는 다음 명령을 실행하여 저장소 그룹을 백업합니다.

    BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt

    참고

    이 명령을 실행하면 C:\Betest 디렉터리에 백업이 만들어집니다. 이 명령은 /E 옵션 없이 실행할 수도 있습니다.

  5. 명령을 실행할 때 오류 메시지가 표시되면 Exchange 기록기에 문제가 있는 것입니다. 문제를 해결하려면 4단계에서 명령을 실행할 때 만들어진 Output.txt 파일의 내용을 확인하십시오.

모범 사례

다음 목록에는 VSS 백업 문제 해결을 위한 몇 가지 권장 모범 사례가 나와 있습니다.

  • 최신 Windows 서비스 팩 및 최신 VSS 업데이트를 설치했는지 확인합니다.

  • 백업 작업을 시작할 때 발생하는 -2403 오류 문제를 해결하려 한다고 가정해 봅니다. 이 경우 VSS는 수동 시작 유형을 사용합니다. 백업 작업이 중단되어도 VSS는 중지되지 않으며 백업 작업이 계속 실행 중인 것으로 간주할 수 있습니다. 이러한 경우 새 백업 작업을 시작하려고 하면 -2403 오류가 발생합니다. 이 문제를 해결하려면 VSS를 수동으로 중지한 다음 백업 작업을 시작합니다.

  • BETest 프로그램을 사용하여 문제를 해결하는 경우에는 며칠 동안 프로그램을 사용하여 여러 BETest 백업을 캡처합니다. 또한 BETest 프로그램을 실행할 때는 타사 백업 관련 서비스를 중지하고 일시적으로 사용하지 않도록 설정해야 합니다.

  • VSS 기록기에서 시간 제한 문제가 발생하는 경우에는 서버에 성능 문제가 있을 수 있습니다. 이러한 경우에는 성능 로그를 수집하여 성능 문제가 있는지 확인합니다.

  • VSS 기록기가 다시 시도 가능 상태인 경우 VSS 기록기에 심각하지 않은 오류가 발생한 것입니다. 이 상태는 시간이 지나면 자동으로 변경됩니다. 그러나 서버를 다시 시작하여 다시 시도 가능 상태 문제를 해결할 수 있습니다.

VSS 참조

다음과 같은 VSS 관련 참조를 사용할 수 있습니다.