백업, 복원 및 재해 복구
적용 대상: Exchange Server 2013
데이터 보호 계획의 일부로서 데이터를 보호하는 방법을 이해하고 조직의 요구에 가장 적합한 방법을 결정하는 것이 중요합니다. 데이터 보호 계획은 배포 계획 단계의 여러 가지 결정을 활용하는 복잡한 과정입니다.
일반적으로 다음 시나리오에서 백업이 사용되었습니다.
재해 복구: 하드웨어 또는 소프트웨어 오류가 발생할 경우 DAG의 여러 데이터베이스 복사본을 사용하면 빠른 장애 조치(failover)와 데이터 손실이 거의 또는 전혀 없는 고가용성을 사용할 수 있습니다. 그러면 가동 중지 시간과 그에 따른 생산성 손실을 해소하여 디스크 또는 테이프에 대한 이전의 지정 시간 백업을 복원할 때 필요한 비용을 절약할 수 있습니다. DAG를 여러 사이트로 확장하여 디스크, 서버, 네트워크 및 데이터 센터 오류를 복구할 수 있습니다.
실수로 삭제된 항목의 복구: 지금까지 사용자가 나중에 복구해야 하는 항목을 삭제한 경우 복구해야 하는 데이터가 저장된 백업 미디어를 찾은 다음 원하는 항목을 가져와서 사용자에게 제공하는 작업이 포함되었습니다. Exchange 2013의 복구 가능한 항목 폴더와 폴더에 적용할 수 있는 보존 정책을 사용하면 삭제 및 수정된 데이터를 지정 기간 동안 모두 보관할 수 있으므로 해당 항목을 더 쉽고 빠르게 복구할 수 있습니다. 그러면 최종 사용자가 실수로 삭제한 항목을 직접 복구할 수 있어 Exchange 관리자와 IT 지원 센터의 부담이 줄고 단일 항목 복구와 관련된 복잡성과 관리 비용도 절감됩니다. 자세한 내용은 메시징 정책 및 규정 준수 및데이터 손실 방지를 참조하세요.
장기 데이터 스토리지: 백업도 보관으로 사용되었으며, 일반적으로 테이프는 규정 준수 요구 사항에 따라 오랜 시간 동안 데이터의 특정 시점 스냅샷을 보존하는 데 사용됩니다. Exchange 2013의 새로운 보관, 여러 사서함 검색 및 메시지 보존 기능은 최종 사용자가 액세스할 수 있는 방식으로 데이터를 효과적으로 장기 보존하는 방법을 제공합니다. 이를 통해 테이프에서 복원하는 비경제적 방법이 사라지고 생산성이 높아집니다. 자세한 내용은 Exchange 2013의 현재 위치 보관, 현재 위치 eDiscovery 및 현재 위치 보존 및 소송 보존을 참조하세요.
지정 시간 데이터베이스 스냅샷: 사서함 데이터의 과거 지정 시간 복사본이 조직의 요구 사항인 경우 Exchange는 DAG 환경에서 지연된 데이터베이스 복사본을 만드는 기능을 제공합니다. 이 기능은 논리적으로 손상된 복제본을 DAG의 여러 데이터베이스 복사본에 저장하게 되어 이전 시점으로 돌아가야 하는 드문 경우에 유용합니다. 관리자가 사서함 또는 사용자 데이터를 실수로 삭제한 경우에도 이 기능이 유용할 수 있습니다. 지연된 복사본은 오랜 시간을 들여 백업 서버에서 Exchange 서버로 복사하는 과정이 생략되므로 지연된 복사본에서 복구하면 백업에서 복원하는 경우보다 작업 시간을 절약할 수 있습니다. 그리고 가동 중지 시간을 줄여 총 소유 비용을 대폭 절감할 수 있습니다.
이러한 각 시나리오를 효율적이면서 비용 효과적인 방식으로 충족하는 고유한 Exchange 2013 기능이 있으므로 작업 환경에서 전형적인 백업을 사용하는 경우를 줄이거나 없앨 수 있습니다.
Unified Contact Store Recovery
Exchange 고유 데이터 보호
Microsoft의 Exchange Server 2013에 대한 기본 아키텍처는 Exchange 고유 데이터 보호라고 하는 개념을 활용합니다. Exchange 고유 데이터 보호는 사용자가 여전히 해당 기능을 사용하고 백업을 만들 수 있더라도 백업을 사용하지 않고 사서함 데이터를 보호할 수 있는 기본 제공 Exchange 기능을 활용합니다. Exchange 2013에서는 올바르게 배포 및 구성했을 때 전형적인 데이터 백업을 수행할 필요를 없애주는 고유한 데이터 보호를 제공할 수 있도록 몇 가지 새 기능이 포함되고 핵심적인 사항이 변경되었습니다. 재해 발생 시 가동 중지 시간과 데이터 손실을 최소화하기 위해 Exchange 2013에 기본 제공되는 고가용성 기능을 사용하면 메시징 시스템의 총 소유 비용을 줄일 수도 있습니다. 이러한 기능을 법적 보존 등의 다른 기본 제공 기능과 결합하여 사용함으로써 기존의 지정 시간 백업 사용을 줄이거나 없애고 관련 비용을 절감할 수 있습니다.
Exchange 2013에서는 기존의 특정 시점 백업이 필요하지 않은 장점을 확인하는 것 외에 현재 백업 인프라의 비용을 평가해 보는 것이 좋습니다. 기존 백업 인프라를 사용하여 재해를 복구할 때 최종 사용자에 대한 서비스 중지 및 데이터 손실 비용을 고려해 보십시오. 또한 하드웨어, 설치 및 라이선스 비용, 백업 유지 관리 및 데이터 복구와 관련된 관리 비용도 여기에 추가되어야 합니다. 조직의 요구 사항에 따라 사서함 데이터베이스 복사본이 3개 이상 있는 순수 Exchange 2013 환경이 백업을 사용하는 것보다 더 낮은 총 소유 비용을 제공할 가능성이 높습니다.
기존 백업을 대체하기 위해 Exchange 2013에서 제공되는 기능을 사용하기 전에 몇 가지 문제에 대해 고려해야 합니다. 또한 조직 특유의 고려 사항이 있을 수 있습니다. 모두 나열할 수는 없지만 우선 다음 문제에 대해 생각해 보십시오.
배포해야 할 데이터베이스의 복사본 수를 결정해야 합니다. RAID(Redundant Array of Independent Disk)나 기존의 VSS 기반 백업과 같은 기존 형태의 데이터베이스 보호를 제거하기 전에 가능하면 사서함 데이터베이스의 (지연되지 않은) 복사본을 세 개 이상 배포하는 것이 좋습니다.
복구 시간 목표 및 복구 지점 목표 목표를 명확하게 정의해야 하며, 기존 백업 대신 결합된 기본 제공 기능 집합을 사용하여 이러한 목표를 달성할 수 있도록 해야 합니다.
시스템이 보호하도록 설계된 다양한 오류 시나리오를 처리해야 하는 각 데이터베이스의 복사본 수를 결정해야 합니다.
DAG나 그 구성원 중 일부를 사용하지 않으면 기존 백업 솔루션을 지원하기에 충분한 비용이 확보되는지 확인해야 합니다. 그리고 그럴 경우 해당 솔루션이 복구 시간 목표나 복구 지점 목표 SLA(서비스 수준 계약)를 향상하는지 확인해야 합니다.
복사본을 호스트하는 DAG 구성원에 복사본 또는 복사본의 무결성에 영향을 주는 오류가 발생한 경우 지정 시간 복사본이 손실을 감수할 수 있는지 확인해야 합니다.
Exchange 2013을 사용하면 권장되는 최대 사서함 데이터베이스 크기가 2테라바이트인 훨씬 더 큰 사서함을 배포할 수 있습니다(2개 이상의 고가용성 사서함 데이터베이스 복사본을 사용하는 경우). 대부분의 조직에서 배포할 가능성이 큰 사서함에 따라 데이터베이스 복사본 또는 지연된 데이터베이스 복사본을 활성화할 때 많은 수의 로그 파일을 재생해야 하는 경우 복구 지점 목표를 결정해야 합니다.
활성 데이터베이스 복사본이 수동 데이터베이스 복사본으로 복제되는 논리적 오류를 발견하고 방지하는 방법을 확인해야 합니다. 여기에는 이 상황에 맞는 복구 계획 및 이 시나리오가 과거에 얼마나 자주 발생했는지를 확인하는 것이 포함됩니다. 조직에서 논리적인 손상이 자주 발생하는 경우에는 논리적인 손상이 발생할 경우 발견하고 대응하기에 충분한 재생 지연 여유를 두면서도 다른 데이터베이스 복사본으로 손상이 복제되기 전에 처리할 수 있도록 하나 이상의 지연된 복사본을 사용하여 이 시나리오를 고려하는 것이 좋습니다.
전체 또는 증분 백업을 성공적으로 완료할 때 수행하는 기능 중 한 가지는 더 이상 데이터베이스 복구에 필요하지 않은 트랜잭션 로그 파일을 자르는 것입니다. 백업이 수행되지 않으면 로그 자르기도 발생하지 않습니다. 로그 파일이 너무 많이 쌓이지 않게 하려면 복제된 데이터베이스에 순환 로깅을 사용합니다. 순환 로깅과 연속 복제를 결합하면 ESE(Extensible Storage Engine) 순환 로깅과는 다른 새로운 CRCL(연속 복제 순환 로깅) 유형을 사용할 수 있습니다. ESE 순환 로깅은 Microsoft Exchange 정보 저장소 서비스에 의해 수행되고 관리되지만 CRCL은 Microsoft Exchange Replication Service에 의해 수행되고 관리됩니다. ESE 순환 로깅을 사용하도록 설정하면 추가 로그 파일을 생성하지 않고 필요한 경우 현재 로그 파일을 덮어씁니다. 그러나 연속 복제 환경에서는 로그 전달 및 재생을 위해 로그 파일이 필요합니다. 따라서 CRCL을 사용하도록 설정하면 현재 로그 파일을 덮어쓰지 않으며 로그 전달 및 재생 프로세스를 위해 닫힌 로그 파일이 생성됩니다.
특히 Microsoft Exchange Replication Service는 로그 연속성이 유지 관리되도록, 그리고 로그가 복제에 필요한 경우 로그가 삭제되지 않도록 CRCL을 관리합니다. Microsoft Exchange Replication Service와 Microsoft Exchange 정보 저장소 서비스는 삭제할 수 있는 로그 파일에 대해 RPC(원격 프로시저 호출)를 사용하여 통신을 수행합니다.
고가용성의 (지연되지 않은) 사서함 데이터베이스 복사본에서 자르기가 발생하려면 다음에 대한 대답이 "그렇다"여야 합니다.
- 로그 파일이 백업되었거나 CRCL을 사용하도록 설정되어 있습니다.
- 로그 파일이 검사점 아래에 있습니다.
- 지연되지 않은 다른 데이터베이스 복사본이 삭제에 동의합니다.
- 로그 파일이 모든 지연된 데이터베이스 복사본에서 검사되었습니다.
지연된 데이터베이스 복사본에서 자르기가 발생하려면 다음에 대한 대답이 "그렇다"여야 합니다.
- 로그 파일이 검사점 아래에 있습니다.
- 로그 파일이 ReplayLagTime과 TruncationLagTime을 더한 것보다 오래되었습니다.
- 데이터베이스의 활성 복사본에서 로그 파일이 삭제되었습니다.
지원되는 백업 기술
Exchange 2013에서는 Exchange 인식 VSS 기반 백업만 지원합니다. Exchange 2013에는 Exchange 데이터의 VSS 기반 백업을 만들고 복원할 수 있는 Windows Server 백업용 플러그 인이 포함되어 있습니다. Exchange 2013을 백업하고 복원하려면 Windows Server 백업(VSS 플러그 인 사용), Microsoft System Center 2012 - Data Protection Manager 또는 타사 Exchange 인식 VSS 기반 응용 프로그램 등의 Exchange 2013용 VSS 기록기를 지원하는 Exchange 인식 응용 프로그램을 사용해야 합니다.
Exchange 백업을 사용하여 Windows Server 데이터를 백업 및 복원하는 방법에 대한 자세한 단계는 Windows Server 백업을 사용하여 Exchange 데이터 백업 및 복원을 참조하십시오.
Exchange 2013 VSS 기록기
Exchange 2013에서는 Exchange 2010 및 Exchange 2007에서 사용되는 VSS 기록기 아키텍처에서 상당히 변경된 아키텍처가 도입되었습니다. 이러한 이전 버전의 Exchange에는 VSS 기록기가 두 개 포함되어 있는데 Microsoft Exchange Information Store 서비스(store.exe) 안에 하나가 있고 Microsoft Exchange Replication Service(msexchangerepl.exe) 안에 하나가 있습니다. Exchange에서는 Microsoft Exchange Information Store 서비스에 이전에 있던 VSS 기록기 기능이 Microsoft Exchange Replication Service로 이동되었습니다. Microsoft Exchange Writer라는 새 작성기가 이제 Exchange 인식 VSS 기반 응용 프로그램에서 활성 및 수동 데이터베이스 복사본을 백업하고 백업된 데이터베이스 복사본을 복원하는 데 사용됩니다. 새 작성기가 Microsoft Exchange Replication Service에서 실행되지만 작성기가 보급되려면 Microsoft Exchange 정보 저장소 서비스가 실행되고 있어야 합니다. 따라서 Exchange 데이터베이스를 백업하거나 복원하려면 두 서비스가 모두 필요합니다.
Exchange Server 복구
사서함 및 클라이언트 액세스 서버의 거의 모든 구성 설정은 Active Directory에 저장됩니다. 이전 버전 Exchange의 경우와 마찬가지로 Exchange 2013에는 손실된 서버를 복구하기 위한 설치 매개 변수가 포함되어 있습니다. 이 매개 변수 /m:RecoverServer는 Active Directory에 저장된 설정 및 구성 정보를 사용하여 손실된 서버를 다시 빌드하고 다시 만드는 데 사용됩니다. 그렇지만 로컬 web.config 및 기타 구성 파일의 변경 내용처럼 복원되지 않는 몇 가지 설정이 있습니다. 또한 사용자 지정 레지스트리 항목도 복원되지 않습니다. 믿을 수 있는 변경 관리 프로세스를 사용하여 이러한 변경 내용을 추적하고 다시 만드는 것이 좋습니다.
손실된 Exchange 2013 서버의 복구를 수행하는 방법에 대한 자세한 단계는 Exchange Server 복구를 참조하십시오. DAG(데이터베이스 가용성 그룹)의 구성원인 손실된 서버를 복구하는 방법에 대한 자세한 단계는 데이터베이스 가용성 그룹 구성원 서버 복구를 참조하세요.
통합 연락처 저장소 복구
Microsoft Lync Server 2013이 Exchange 2013 환경에서 사용되는 경우 사용자의 Lync 연락처 정보가 사용자 사서함의 특수 연락처 폴더에 저장됩니다. 이를 UCS(통합 연락처 저장소)라고 합니다. UCS에서 마이그레이션된 사서함을 복원하는 경우 대상 사용자의 인스턴트 메시징 연락처 목록이 영향을 받을 수 있습니다. 사용자가 마지막 백업 후 마이그레이션된 경우 사서함을 복원하면 사용자의 연락처 목록이 완전히 손실됩니다. 이보다 심각하지 않은 경우에는 마지막 백업 이후 사용자가 수정한 연락처 목록의 내용이 손실됩니다. 이 잠재적인 데이터 손실을 완화하려면 사서함을 복원하기 전에 사용자가 인스턴트 메시징 서버로 다시 마이그레이션되었는지 확인하십시오.
복구 데이터베이스
복구 데이터베이스는 복구 작업 단계에서 복원된 사서함 데이터베이스를 탑재하고 복원된 데이터베이스에서 데이터를 추출하도록 지원하는 특별한 종류의 사서함 데이터베이스입니다. New-MailboxRestoreRequest cmdlet을 사용하여 복구 데이터베이스에서 데이터를 추출할 수 있습니다. 추출 후에는 데이터를 폴더로 내보내거나 기존의 사서함으로 병합할 수 있습니다. 사용자는 복구 데이터베이스를 통해 현재 데이터에 대한 사용자 액세스를 방해하지 않고 데이터베이스의 백업 또는 복사본에서 데이터를 복구할 수 있습니다.
이전 버전의 Exchange에서 제공된 사서함 데이터베이스에 복구 데이터베이스를 사용하는 것은 지원되지 않습니다. 또한 데이터 병합 및 추출에 사용되는 대상 사서함은 복구 데이터베이스에 탑재된 데이터베이스와 동일한 Active Directory 포리스트에 있어야 합니다.
자세한 내용은 복구 데이터베이스를 참조하십시오. 복구 데이터베이스를 만드는 방법에 대한 자세한 단계는 복구 데이터베이스 만들기를 참조하십시오. 복구 데이터베이스를 사용하는 방법에 대한 자세한 단계는 복구 데이터베이스를 사용하여 데이터 복원을 참조하십시오.
데이터베이스 이식성
데이터베이스 이식성은 Exchange 2013 사서함 데이터베이스를 이동하여 같은 조직의 다른 Exchange 2013 사서함 서버에 탑재하는 기능입니다. 데이터베이스 이식성을 사용하면 복구 프로세스에서 여러 가지 오류를 유발하는 수동 작업 단계가 제외되므로 안정성이 향상됩니다. 또한, 다양한 오류 시나리오에서 전체 복구 횟수가 줄어듭니다.
자세한 내용은 데이터베이스 이식성을 참조하세요. 데이터베이스 이식성을 사용하는 자세한 단계는 데이터베이스 이식성을 사용하여 사서함 데이터베이스 이동을 참조하세요.
발신음 이식성
발신음 이식성은 사서함 데이터베이스, 서버 또는 전체 사이트에 영향을 미치는 오류에 대해 제한적인 업무 지속 솔루션을 제공하는 기능입니다. 발신음 이식성을 사용하면 사용자의 원래 사서함을 복원 또는 복구하는 동안 전자 메일을 주고 받을 수 있는 임시 사서함이 제공됩니다. 임시 사서함은 조직 내에서 같은 Exchange 2013 사서함 서버나 다른 Exchange 2013 사서함 서버에 위치할 수 있습니다. 따라서 더 이상 사용되지 않는 서버에 있던 사용자의 사서함을 대체 서버에서 호스트할 수 있습니다. Microsoft Outlook 같은 Autodiscover가 지원되는 클라이언트에서는 사용자의 데스크톱 프로필을 수동으로 업데이트하지 않아도 자동으로 새 서버로 리디렉션됩니다. 사용자의 원래 사서함 데이터를 복원한 후, 관리자는 복구된 사서함을 발신음 사서함과 병합하여 단일 최신 사서함으로 만들 수 있습니다.
발신음 이식성을 사용하는 프로세스를 발신음 복구라고 합니다. 발신음 복구는 사서함 서버에 빈 데이터베이스를 만들어 오류가 발생한 데이터베이스를 대체하는 작업입니다. 사용자는 발신음 데이터베이스라고 하는 이 빈 데이터베이스를 통해 오류가 발생한 데이터베이스를 복구하는 동안에도 전자 메일을 보내고 받을 수 있습니다. 오류가 발생한 데이터베이스를 복구하고 나면 발신음 데이터베이스와 복구된 데이터베이스가 전환되고 발신음 데이터베이스의 데이터가 복구된 데이터베이스에 병합됩니다.
자세한 내용은 발신음 이식성을 참조하세요. 발신음 복구를 수행하는 자세한 단계는 발신음 복구 수행을 참조하세요.