백업, 복원 및 재해 복구 이해

  • 아티클

 

적용 대상: Exchange Server 2010 SP2, Exchange Server 2010 SP3

마지막으로 수정된 항목: 2010-11-01

Microsoft Exchange Server 2010에는 고가용성의 중복 사서함 데이터베이스를 쉽고 빠르게 배포할 수 있게 만들어 주는 새로운 고가용성 및 사이트 복구용 통합 플랫폼이 있습니다. 하지만 중복성과 내결함성을 극한으로 높여도 가능한 모든 오류나 재해로부터 보호할 수는 없습니다. 모든 조직에서 Exchange 조직의 중요한 데이터를 충분히 보호해야 합니다. 

데이터 보호 계획의 일부로서 데이터를 보호하는 방법을 이해하고 조직의 요구에 가장 적합한 방법을 결정하는 것이 중요합니다. 데이터 보호 계획은 배포 계획 단계의 여러 가지 결정을 활용하는 복잡한 과정입니다.

목차

지원되는 백업 기술

서버 복구

복구 데이터베이스

데이터베이스 이식성

발신음 이식성

Exchange 고유 데이터 보호

지원되는 백업 기술

Microsoft Exchange Server 2007 및 Exchange Server 2003에는 데이터 백업 및 복구에 사용할 수 있는 옵션으로 ESE(Extensible Storage Engine) 스트리밍 백업 API와 VSS(볼륨 섀도 복사본 서비스) 백업 API 지원의 두 가지가 포함되어 있습니다. Exchange 2010은 더 이상 프로그램 파일 또는 데이터의 백업 및 복원을 위한 ESE 스트리밍 API를 지원하지 않습니다. Exchange 2010은 VSS 기반 백업만 지원합니다.

Exchange 2010에는 Exchange 데이터의 VSS 기반 백업을 만들 수 있는 Windows Server 백업용 플러그 인이 포함되어 있습니다. Windows Server 백업을 사용하여 Exchange 데이터베이스를 백업 및 복원할 수 있습니다. Exchange 2010을 백업 및 복원하려면 Exchange 2010용 VSS 기록기를 지원하는 Windows Server 백업(VSS 플러그 인 사용), Microsoft System Center Data Protection Manager 또는 타사 Exchange 인식 VSS 기반 응용 프로그램 등의 Exchange 인식 응용 프로그램을 사용해야 합니다. Exchange 데이터의 VSS 백업 및 복원을 사용하는 경우 다음 제한에 주의해야 합니다.

  • Exchange 2010과 함께 제공되는 VSS 플러그 인으로는 활성 사서함 데이터베이스 복사본 또는 독립 실행형(복제되지 않은) 사서함 데이터베이스가 포함된 볼륨만 백업할 수 있습니다. 수동 사서함 데이터베이스 복사본이 포함된 볼륨은 백업할 수 없습니다. 수동 사서함 데이터베이스 복사본을 백업하려면 Microsoft System Center Data Protection Manager 또는 타사 Exchange 인식 VSS 기반 응용 프로그램이 필요합니다.

  • 수동 사서함 데이터베이스 복사본은 Microsoft Exchange Replication Service에 있는 별도 VSS 기록기를 사용하여 백업합니다. Microsoft Exchange Replication Service VSS 기록기는 복원을 지원하지 않습니다. Microsoft System Center Data Protection Manager 또는 타사 Exchange 인식 VSS 기반 응용 프로그램을 사용하여 수동 사서함 데이터베이스를 백업할 수도 있지만 수동 사서함 데이터베이스로 직접 VSS 복원을 수행할 수는 없습니다. 하지만 대체 위치로 VSS 복원을 수행하고 수동 복사본에 대한 복제를 일시 중단한 다음 대체 위치에서 파일 시스템에 있는 수동 데이터베이스 복사본 위치로 데이터베이스 및 로그 파일을 복사할 수는 있습니다.

Windows Server 백업을 사용하여 Exchange 데이터를 백업 및 복원하는 자세한 단계는 Windows Server 백업을 사용하여 Exchange 데이터 백업 및 복원을 참조하십시오.

맨 위로 이동

서버 복구

사서함, 클라이언트 액세스, 허브 전송 및 통합 메시징 서버 역할의 구성 설정은 거의 모두 Active Directory에 저장됩니다. 이전 버전 Exchange의 경우와 마찬가지로 Exchange 2010에는 손실된 서버를 복구하기 위한 설치 매개 변수가 포함되어 있습니다. 이 /m:RecoverServer 매개 변수는 Active Directory에 저장된 설정 및 구성 정보를 사용하여 손실된 서버를 다시 빌드하고 만드는 데에 사용됩니다.

손실된 Exchange 2010 서버의 복구를 수행하는 자세한 단계는 Exchange Server 복구를 참조하십시오. 데이터베이스 가용성 그룹의 구성원인 손실된 서버를 복구하는 자세한 단계는 데이터베이스 사용 가능 그룹 구성원 서버 복구를 참조하십시오.

맨 위로 이동

복구 데이터베이스

복구 데이터베이스는 이전 버전 Exchange의 RSG(복구 저장소 그룹)을 대체하는 Exchange 2010 기능입니다. 복구 데이터베이스는 복구 작업 단계에서 복원된 사서함 데이터베이스를 탑재하고 복원된 데이터베이스에서 데이터를 추출하도록 지원하는 특별한 종류의 사서함 데이터베이스입니다. restore-Mailbox cmdlet을 사용하여 복구 데이터베이스에서 데이터를 추출할 수 있습니다. 추출 후에는 데이터를 폴더로 내보내거나 기존의 사서함으로 병합할 수 있습니다. 사용자는 복구 데이터베이스를 통해 현재 데이터에 대한 사용자 액세스를 방해하지 않고 데이터베이스의 백업 또는 복사본에서 데이터를 복구할 수 있습니다.

복구 데이터베이스를 사용하기 전에 반드시 충족해야 하는 몇 가지 요구 사항이 있습니다. 복구 데이터베이스는 Exchange 2010 사서함 데이터베이스에만 사용할 수 있습니다. Exchange 이전 버전의 사서함 데이터베이스는 지원되지 않습니다. 또한 데이터 병합 및 추출에 사용되는 대상 사서함은 복구 데이터베이스에 탑재된 데이터베이스와 동일한 Active Directory 포리스트에 있어야 합니다.

자세한 내용은 복구 데이터베이스를 참조하십시오. 복구 데이터베이스를 만드는 자세한 단계는 복구 데이터베이스 만들기을 참조하십시오. 복구 데이터베이스를 사용하는 자세한 단계는 복구 데이터베이스를 사용하여 데이터 복원을 참조하십시오.

맨 위로 이동

데이터베이스 이식성

데이터베이스 이식성은 Exchange 2010 사서함 데이터베이스를 이동하여 같은 조직의 다른 Exchange 2010 사서함 서버에 탑재하는 기능입니다. 데이터베이스 이식성을 사용하면 복구 프로세스에서 여러 가지 오류를 유발하는 수동 작업 단계가 제외되므로 안정성이 향상됩니다. 또한, 다양한 오류 시나리오에서 전체 복구 횟수가 줄어듭니다.

자세한 내용은 데이터베이스 이식성를 참조하십시오. 데이터베이스 이식성을 사용하는 자세한 단계는 데이터베이스 이식성을 사용하여 사서함 데이터베이스 이동을 참조하십시오.

맨 위로 이동

발신음 이식성

발신음 이식성은 사서함 데이터베이스, 서버 또는 전체 사이트에 영향을 미치는 오류에 대해 제한적인 업무 지속 솔루션을 제공하는 기능입니다. 발신음 이식성을 사용하면 사용자의 원래 사서함을 복원 또는 복구하는 동안 전자 메일을 주고 받을 수 있는 임시 사서함이 제공됩니다. 임시 사서함은 조직 내에서 같은 Exchange 2010 사서함 서버나 다른 Exchange 2010 사서함 서버에 만들 수 있습니다. 따라서 더 이상 사용되지 않는 서버에 있던 사용자의 사서함을 대체 서버에서 호스트할 수 있습니다. Microsoft Outlook 2010 또는 Office Outlook 2007과 같이 자동 검색을 지원하는 클라이언트는 사용자의 데스크톱 프로필을 수동으로 업데이트하지 않아도 자동으로 새 서버로 리디렉션됩니다. 사용자의 원래 사서함 데이터를 복원한 후, 관리자는 복구된 사서함을 발신음 사서함과 병합하여 단일 최신 사서함으로 만들 수 있습니다.

발신음 이식성을 사용하는 프로세스를 발신음 복구라고 합니다. 발신음 복구는 사서함 서버에 빈 데이터베이스를 만들어 오류가 발생한 데이터베이스를 대체하는 작업입니다. 사용자는 발신음 데이터베이스라고 하는 이 빈 데이터베이스를 통해 오류가 발생한 데이터베이스를 복구하는 동안에도 전자 메일을 보내고 받을 수 있습니다. 오류가 발생한 데이터베이스를 복구하고 나면 발신음 데이터베이스와 복구된 데이터베이스가 전환되고 발신음 데이터베이스의 데이터가 복구된 데이터베이스에 병합됩니다.

자세한 내용은 발신음 이식성를 참조하십시오. 발신음 복구를 수행하는 자세한 단계는 발신음 복구 수행을 참조하십시오.

맨 위로 이동

Exchange 고유 데이터 보호

Exchange 2010을 올바르게 배포하고 구성할 경우, 기존 방식의 데이터 백업이 필요하지 않은 고유 데이터 보호를 제공하는 몇 가지 새로운 기능과 중요한 변경 사항을 사용할 수 있습니다. Exchange 2010에 구현된 고가용성 기능을 사용하면 재해 발생 시의 가동 중지 시간과 데이터 손실이 최소화되며 메시징 시스템의 총 소유 비용이 줄어듭니다. 조직은 이러한 기능을 법적 보존 등의 다른 기본 제공 기능과 결합하여 사용함으로써 기존의 지정 시간 백업에 대한 의존도를 줄이거나 없애고 관련 비용을 절감할 수 있습니다.

Exchange 2010에서는 기존의 특정 시점 백업이 필요하지 않은 장점을 확인하는 것과 함께, 현재 백업 인프라의 비용을 평가해 보는 것이 좋습니다. 기존 백업 인프라를 사용하여 재해를 복구할 때 최종 사용자에 대한 서비스 중지 및 데이터 손실 비용을 고려해 보십시오. 또한 하드웨어, 설치 및 라이선스 비용, 백업 유지 관리 및 데이터 복구와 관련된 관리 비용도 여기에 추가되어야 합니다. 조직의 요구 사항에 따라, 세 개 이상의 사서함 데이터베이스 복사본이 있는 순수 Exchange 2010 환경에 대한 총 소유 비용은 기존 백업을 사용하는 환경보다 적을 가능성이 아주 높습니다.

백업은 보통 다음과 같은 시나리오에서 사용되며 효율적이고 경제적인 방식으로 이러한 각 요구를 충족하는 Exchange 2010 기능이 있습니다.

  • 재해 복구   하드웨어 또는 소프트웨어 오류가 발생한 경우 DAG(데이터베이스 가용성 그룹)에 있는 여러 데이터베이스 복사본을 사용하여 데이터 손실 없이 빠르게 장애 조치(failover)를 수행하는 방법으로 고가용성을 확보할 수 있습니다. 그러면 최종 사용자의 가동 중지 시간과 그에 따른 생산성 손실을 해소하여 디스크 또는 테이프에 대한 이전의 지정 시간 백업을 복원할 때 필요한 비용을 절약할 수 있습니다. DAG를 여러 사이트로 확장하여 데이터 센터 오류를 복구할 수 있습니다.

  • 실수로 삭제한 항목 복구   지금까지 사용자가 삭제한 항목을 나중에 복구해야 하는 상황이 되면 복구할 데이터가 저장된 백업 미디어를 찾은 다음 원하는 항목을 찾아 사용자에게 제공해야 했습니다. Exchange 2010의 복구 가능한 항목 폴더와 폴더에 적용할 수 있는 보존 정책을 사용하면 삭제 및 수정된 데이터를 지정 기간 동안 모두 보관할 수 있으므로 해당 항목을 더 쉽고 빠르게 복구할 수 있습니다. 그러면 최종 사용자가 실수로 삭제한 항목을 직접 복구할 수 있어 Exchange 관리자와 IT 지원 센터의 부담이 줄고 단일 항목 복구와 관련된 복잡성과 관리 비용도 절감됩니다. 자세한 내용은 메시징 정책 및 규정 준수, 복구 가능한 항목 이해 및 보존 태그 및 보존 정책 이해을 참조하십시오.

  • 장기 데이터 저장소   백업이 보존 목적으로 사용되기도 하며, 일반적으로 규정 준수 요구 사항에 따라 장기적으로 지정 시간의 데이터 스냅샷을 보관하는 일에는 테이프를 사용합니다. Exchange 2010의 새로운 보관, 여러 사서함 검색 및 메시지 보존 기능은 최종 사용자가 액세스할 수 있는 방식으로 데이터를 효과적으로 장기 보존하는 방법을 제공합니다. 이 방법을 사용하면 값비싼 테이프 복원을 사용할 필요가 없어지며 오래된 데이터에 대한 Microsoft Outlook 및 Outlook Web App 액세스와 같이 풍부한 클라이언트를 사용하여 최종 사용자의 생산성을 높일 수 있습니다. 자세한 내용은 개인 보관 파일 이해, 여러 사서함 검색 이해 및 보존 태그 및 보존 정책 이해를 참조하십시오.

  • 지정 시간 데이터베이스 스냅숏   조직에 지난 지정 시간의 사서함 데이터 복사본이 필요한 경우에는 Exchange에서 제공하는 기능을 사용하여 DAG 환경에 지연된 복사본을 만들 수 있습니다. 이 기능은 DAG의 여러 데이터베이스에서 복제되는 논리적인 손상이 생겨 이전 시간으로 돌아가야 하는 경우에 유용합니다. 관리자가 사서함 또는 사용자 데이터를 실수로 삭제한 경우에도 이 기능이 유용할 수 있습니다. 지연된 복사본은 오랜 시간을 들여 백업 서버에서 Exchange 서버로 복사하는 과정이 생략되므로 지연된 복사본에서 복구하면 백업에서 복원하는 경우보다 작업 시간을 절약할 수 있습니다. 그리고 최종 사용자의 가동 중지 시간을 줄여 총 소유 비용을 대폭 절감할 수 있습니다.

백업 없이 로그 자르기

전체 또는 증분 백업을 성공적으로 완료할 때 수행하는 기능 중 한 가지는 더 이상 데이터베이스 복구에 필요하지 않은 트랜잭션 로그 파일을 자르는 것입니다. 백업을 수행하지 않으면 로그도 자르지 않습니다. 로그 파일이 너무 많이 쌓이지 않게 하려면 복제된 데이터베이스에 순환 로깅을 사용합니다. 순환 로깅과 연속 복제를 결합하면 ESE 순환 로깅과는 다른 새로운 CRCL(연속 복제 순환 로깅) 유형을 사용할 수 있습니다. ESE 순환 로깅은 Microsoft Exchange 정보 저장소 서비스에서 수행 및 관리하지만 CRCL은 Microsoft Exchange Replication Service에서 수행 및 관리합니다. 이 기능을 사용하면 ESE 순환 로깅이 추가 로그 파일을 생성하지 않고 필요할 때 현재 로그 파일을 덮어씁니다. 그러나 연속 복제 환경에서는 로그 전달 및 재생을 위해 로그 파일이 필요합니다. 따라서 CRCL을 사용하도록 설정하면 현재 로그 파일이 덮어쓰여지지 않으며 로그 전달 및 재생 프로세스를 위한 닫힌 로그 파일이 생성됩니다. 특히 Microsoft Exchange Replication Service는 로그 연속성이 유지 관리되고 로그가 복제에 필요한 경우 로그 삭제기가 로그를 삭제하지 않도록 CRCL을 관리합니다.

순환 로깅을 사용하거나 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 사서함 데이터베이스 속성 구성을 참조하십시오.

Exchange 고유 데이터 보호를 구현하기 위한 고려 사항

기존 백업을 대체하기 위해 Exchange 2010에서 제공되는 기능을 사용하기 전에 몇 가지 기술적인 근거와 문제에 대해 고려해야 합니다. 다음 목록은 이러한 고려 사항 중 일부를 소개합니다. 특수 고려 사항이나 조직 고유의 고려 사항이 있을 수도 있습니다. 다음과 같은 문제를 고려합니다.

  • 배포할 데이터베이스 복사본은 몇 개입니까? RAID나 기존의 VSS 기반 백업과 같은 기존 형태의 데이터베이스 보호를 제거하기 전에 가능하면 사서함 데이터베이스 복사본을 세 개 이상 배포하는 것이 좋습니다.

  • 복구 시간 목표와 복구 지점 목표를 명확하게 정의하고 기존의 백업과 기본 제공 기능을 결합하여 목표를 달성할 수 있게 만들어야 합니다.

  • 시스템에서 보호해야 하는 다양한 오류 시나리오에서 각 데이터베이스에 필요한 복사본의 수를 결정해야 합니다.

  • DAG나 그 구성원 중 일부를 사용하지 않으면 기존 백업 솔루션을 지원하기에 충분한 비용이 나옵니까? 그럴 경우, 그 솔루션이 복구 시간 목표나 복구 지점 목표 SLA(서비스 수준 계약)를 향상시킵니까?

  • 복사본을 호스트하는 DAG 구성원에 복사본 또는 복사본의 무결성에 영향을 주는 오류가 발생한 경우 지정 시간 복사본이 손실을 감수할 수 있습니까?

  • Exchange 2010을 사용하면 더 큰 사서함을 배포할 수 있게 되며 권장 최대 사서함 데이터베이스 크기가 Exchange 2007의 200GB(기가바이트)에서 2테라바이트로 늘어납니다(세 개 이상의 사서함 데이터베이스 복사본을 사용하는 경우). 대부분의 조직에서 배포하는 정도의 큰 사서함을 기반으로 데이터베이스 복사본 또는 지연된 데이터베이스 복사본을 활성화할 경우 더 많은 로그 파일을 재생하기에 적합한 복구 지점 목표는 무엇입니까?

  • 활성 데이터베이스 복사본이 수동 데이터베이스 복사본으로 복제되는 논리적 손상을 발견하고 방지하는 방법은 무엇입니까? 이 상황에서 사용할 복구 계획은 무엇입니까? 지금까지 이러한 시나리오가 얼마나 자주 발생했습니까? 조직에서 논리적인 손상이 자주 발생하는 경우에는 논리적인 손상이 발생할 경우 발견하고 대응하기에 충분한 재생 지연 여유를 두면서도 다른 데이터베이스 복사본으로 손상이 복제되기 전에 처리할 수 있도록 하나 이상의 지연된 복사본을 사용하여 이 시나리오를 고려하는 것이 좋습니다.

맨 위로 이동

 © 2010 Microsoft Corporation. 모든 권리 보유.