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