문서 버전 4.00(MS Exchange Server 버전 5.5용으로 업데이트됨)

작성자: Kali Buhariwalla, Microsoft PSS(고객 지원 서비스)
Joseph Pagano, MCS(Microsoft Consulting Services), 뉴저지

개요

요점: 재난 복구 계획을 세우고, 테스트, 인증 및 구축하는 것은 메시징 시스템 관리에 있어 필수 요소입니다.

상세 정보: 높음 작업: 계획, 지원

소개

Microsoft Exchange가 강력하고 안정된 기업 메시징 플랫폼이기는 하지만, 컴퓨터 고장이나 전원 오류 또는 그 밖의 재난이 생길 소지는 항상 있게 마련입니다. 따라서 가동 중지 시간과 데이터 손실을 최소화하면서 Exchange를 복구하기 위한 계획을 세워 두어야 합니다. 미리 계획을 세워서 준비하는 것이 중요합니다. 재난이 발생하고 나서야 계획을 세우고 있어서는 안되며, 이미 시도된 바 있는 신뢰할만한 절차와 기술을 재난 발생시 신속하게 적용할 수 있어야 합니다.

이 문서는 기존의 온라인 및 하드카피 문서를 보완하며, 사용자 자신의 재난 복구 계획을 세우고, 테스트하고, 구축하는 작업을 돕기 위한 가이드입니다. 타사의 백업 유틸리티는 다루지 않습니다.

일반 사항

Microsoft Exchange는 업무상 아주 중요한 응용 프로그램으로, 이전의 공유 파일 메시징 시스템보다 서버당 사용자 및 데이터 세트를 더 많이 처리할 수 있습니다. Exchange 구성이 증가하면서, 기업에 있어 각 서버의 중요성이 더욱 커지고 있으며 사용자는 365일 하루 24시간 내내 시스템 가용성을 기대하게 되었습니다. 그럼에도 불구하고 많은 조직들은 충분치 않은 유지 관리나 재난 복구 기능에 의존하고 있습니다.

Exchange는 인증을 위해 Windows NT 보안을 사용하므로 Exchange 백업 계획에는 반드시 Windows NT 백업 및 복구 기능을 적용해야 합니다. Windows NT의 NTBACKUP.EXE는 파일 기반 백업 서비스를 제공하며 Windows NT 레지스트리를 백업합니다. Exchange Server 4.0 이후 버전과 함께 제공되는 NTBACKUP.EXE의 향상된 버전을 사용하여 메시징 시스템을 중단하지 않고도 Exchange 정보 저장소와 디렉터리를 라이브 백업할 수 있습니다.

Exchange Server는 오프라인 상태로 바꾸지 않아도 백업이 가능하도록 만들어졌습니다. 사실, 서버를 다시 온라인 상태로 되돌릴 때는 재인증 절차가 필요하기 때문에 온라인 상태를 유지해야 시스템 트래픽이 줄어듭니다. 온라인 백업 동안 전체 정보 저장소, 디렉터리, MTA 및 시스템 수행자는 계속해서 서비스를 제공받을 수 있습니다. WINAT.EXE GUI 스케줄러를 사용하면 이 과정을 자동화하고 백업 일정을 세울 수 있습니다(Microsoft Windows NT 4.0 리소스 키트 참조). 이 문서의 2부 뒷부분에 나오는 "온라인 백업용 배치 파일 예제" 절에는 Exchange 서비스를 종료하고 재시작하거나 그외 다른 여러 용도로 사용할 수 있는 몇 가지 배치 파일 예제가 수록되어 있습니다.

그러나 디렉터리 동기화(DX)나 Microsoft 메일 메시지 전송 에이전트(PCMTA) 등의 다른 Windows NT용 Exchange 서비스가 액세스하는 디렉터리 파일을 백업할 때는 Exchange가 실행되고 있지 않아야 합니다.

백업할 항목

백업 절차에서는 두 가지 데이터 형식을 처리해야 합니다.

• 사용자 데이터—정보 저장소(PUB.EDB 및 PRIV.EDB), .PST, .OST, .PAB 및 트랜잭션 로그
• 구성 데이터—Exchange 디렉터리(DIR.EDB), Windows NT 레지스트리 및 다양한 Exchange Server 설치 경로와 Exchange Performance Optimizer 프로그램을 실행한 후 만들어진 경로 아래의 하위 디렉터리

아래 표는 데이터베이스 파일에 대한 기본 위치를 보여줍니다. 서버 개체의 데이터베이스 경로 페이지에서, 표에 기본값으로 나타난 경로(\exchsrvr)가 아닌 다른 경로를 선택하면 설치 중에 모든 데이터베이스 파일 경로를 다시 구성할 수 있습니다. Exchange Performance Optimizer를 사용하여 정보 저장소와 디렉터리 파일과는 별개의 물리 디스크에 트랜잭션 로그를 저장할 수도 있습니다.

키 관리(KM) 프로그램을 설치할 때 만들어지는 KM 서버 데이터와 KM 서버 시작 디스크는 온라인 백업 프로그램에 의한 자동 백업이 이루어지지 않기 때문에 수동으로 백업해야 합니다. Exchange 5.5 KM 서버 데이터는 exchsrvr\kmsdata에 있으며 Exchange 4.0과 5.0 버전에서는 \Security 디렉터리에 위치합니다.

Exchange 데이터베이스 파일 위치

이 데이터 외에도 다음 사항을 정기적으로 백업해야 합니다.

• Windows NT 레지스트리—Exchange 서비스 계정을 포함하는 보안 계정 관리자(SAM) 데이터베이스와 Exchange 서비스에 속하는 구성 정보
• Exchsrvr 하위 디렉터리의 데이터—예를 들어, 디렉터리 추적 데이터를 포함하는 TRACKING.LOG 디렉터리 및 보관된 인터넷 메시지 등이 포함되어 있을 수 있는 IMCDATA

개인 메시지 저장소(.PST)

파일 서버(홈 디렉터리)에 저장된 .PST가 백업 루틴에 포함되는지 확인합니다. 손실되거나 손상된 .PST의 복구는 .PST를 복원하여 기존 사용자 프로필에 추가하는 것만큼이나 간단합니다. 손상된 .PST는 SCANPST 프로그램을 실행하여 복구할 수 있습니다. 간혹 사용자들이 정기적으로 백업되지 않는 로컬 드라이브에 .PST를 저장하거나 .PST를 암호로 보호하고는 그 암호를 잊어버리는 경우가 있습니다. 이럴 때는 데이터를 영원히 잃어버리게 됩니다. 사용자에게 이 점을 주지시켜야 합니다.

오프라인 메시지 저장소(.OST)

로컬 .OST에 대한 변경 사항이 아직 서버 기반 저장소에 복제되지 않았을 때 .OST 데이터는 위험에 처하게 됩니다. 복제가 완료된 후 사용자 컴퓨터가 손상된 경우, 새로운 .OST가 대체 컴퓨터에 만들어지고 동기화에 의해 모든 서버 기반 정보가 .OST 파일로 보내질 수 있습니다. 손상된 .OST 파일은 SCANPST 프로그램을 실행하여 복구할 수 있습니다.

개인 주소록(.PAB)

개인 주소록은 로컬 또는 서버 디렉터리에 저장할 수 있습니다. 대부분의 서버는 정기적으로 백업되므로 서버 디렉터리에 저장하는 것이 보다 안전합니다. 자신의 .PAB를 로컬 컴퓨터에 저장하는 사용자는 스스로 이를 백업해야 합니다. .PAB가 손실되면 복구하는데 많은 작업 시간과 노력이 들어갑니다.

Outlook—보관 및 자동 보관

Outlook을 사용하면 .PST 파일을 자동으로 보관하는 기능을 백업 전략에 통합할 수 있습니다.

책상 위에 서류가 쌓이면 가끔은 이를 정리해야 합니다. 즉, 정기적으로 사용하지는 않지만 계속 가지고 있어야 할 서류는 보관하고, 다른 폴더로 옮기거나, 오래된 서류는 폐기하는 식으로 서류를 정리해야 합니다.

Outlook에서 정리하려면 파일 메뉴에서 보관을 누르거나, 항목이 삭제되거나 이동된 후의 기간을 지정할 수 있는 자동 보관(AutoArchive)을 사용하여 오래된 항목을 저장소 파일로 직접 옮겨야 합니다. Outlook에서 첨부된 Excel 스프레드시트나 Word 문서와 같은 파일이 메일 폴더에 저장되어 있는 경우 이 파일들도 보관이 가능합니다.

자동 보관은 두 단계의 과정으로 이루어집니다. 도구 메뉴에서 옵션을 누르고 자동 보관 탭을 선택합니다. 각 폴더에 대해 자동 보관 등록 정보를 설정하여 특정 폴더, 폴더 그룹 또는 모든 폴더 등과 같이 캡처할 항목과 시기를 결정합니다. Outlook을 시작할 때마다 자동 보관은 각 폴더의 등록 정보를 확인하여 등록 정보에 나타난 대로 각 폴더를 보관 또는 삭제합니다.

자동 보관은 기본적으로 일정(6개월), 작업(6개월), 업무 일지(6개월), 보낸 편지함(2개월) 및 지운 편지함(2개월) 등의 일부 Outlook 폴더는 신중히 처리합니다. 그러나 받은 편지함, 메모 및 주소록은 확인하지 않습니다.

새 보관 파일에서 기존의 폴더 구조를 유지하며 보관이 이루어집니다. 사용자가 하위 폴더를 보관하면 프로세스는 보관 파일에 상위 폴더를 다시 만들지만 해당 폴더 내의 항목은 보관하지 않습니다. 보관 폴더 구조에서는 사서함 구조만을 다시 만듭니다. 빈 폴더라 하더라도 폴더는 보관 후에 그대로 남아 있습니다.

개인 폴더로 항목을 옮기는 보관과는 달리 내보내기는 원본 항목을 현재 폴더에 그대로 놓아둔 상태로 여러 파일 형식으로 복사합니다.

보관된 Outlook 데이터도 반드시 백업 전략에 포함시켜야 합니다.

백업 유형 검토

온라인 대 오프라인

온라인 백업—이 백업을 수행하려면 정보 저장소나 디렉터리 서비스와 같은 적절한 서비스가 실행되고 있어야 합니다. 이 백업은 Exchange 기반 서버의 메시징을 중단시키지 않습니다. 백업에 Windows NT 레지스트리를 포함시키면 안되며 정보 저장소가 실행되고 있지 않는 경우에도 디렉터리 서비스를 백업할 수 있습니다.

오프라인 백업—모든 Exchange 서비스가 중지되어야 하며 이 백업은 파일 단위로 이루어집니다. Windows NT 레지스트리를 포함해서 선택한 드라이브의 모든 파일을 캡처하려면 NTBACKUP을 실행하기만 하면 됩니다.

온라인 백업 유형

일반(전체)

전체 정보 저장소 및 디렉터리 데이터베이스를 백업합니다. 트랜잭션 로그는 백업된 다음 제거되어 증분 및 차등 백업에 컨텍스트를 제공합니다(아래 참조).

복사

복사 백업은 로그 파일을 삭제하거나 증분 및 차등 백업용 컨텍스트를 변경하지 않습니다. 이 백업은 다른 백업 루틴을 발생시키거나 영향을 주지 않고 데이터베이스를 빠르게 복사합니다. 이는 테스트를 위해 시스템 상태를 다시 만들려는 경우 편리한 백업 방식입니다.

증분

이 백업은 정보 저장소나 디렉터리의 일부만 백업하며 마지막 전체 또는 증분 백업 중 가장 최근의 백업 이후에 변경된 사항만을 기록합니다. 증분 백업은 .LOG 파일을 테이프에(만) 기록한 다음 디스크에서 제거하여 다음 백업 작업에 대한 컨텍스트를 설정합니다. 일반적으로 증분 복원에서는 마지막 전체 백업 테이프와 시스템이 중단된 시점까지의 증분 백업 테이프들이 필요합니다. 전체 백업이 일요일 저녁에 수행되었고 증분 백업을 주중에 매일 수행하는 경우를 예로 들어 보겠습니다. 금요일 아침에 시스템이 중단된 경우, 전체 복원을 수행하여 일요일 저녁까지의 시스템을 복원한 다음 각각의 증분 복원을 수행하여 목요일까지의 시스템을 복원합니다. 마지막 증분 테이프가 복원될 때까지는 서비스를 시작하지 않아야 합니다.

순환 로깅 기능이 해제되어 있으면 증분 백업을 사용할 수 없습니다. 이에 대한 자세한 내용은 아래의 로그 파일과 순환 로깅 절에 나와 있습니다.

차등

대부분의 관리자가 차등 백업과 증분 백업을 혼합해서 한꺼번에 수행하지 않는다고 선택한 경우에도, 차등 백업은 마지막 전체(일반) 또는 증분 백업 이후 정보 저장소 및/또는 디렉터리의 변경 사항을 백업합니다. 차등 백업은 .LOG 파일만을 캡처하며 이들 파일을 디스크에서 제거하지는 않습니다. 트랜잭션 로그와 데이터베이스 복원이 필요한 경우, 마지막 전체 및 차등 백업에 대한 두 개의 테이프만 있으면 됩니다. 마지막 전체 백업 이후로 트랜잭션 로그를 변경하지 않았다면 복원 프로세스는 마지막 전체 백업부터 현재 EDB.LOG 파일까지의 모든 로그를 뒤로 재생하여 모든 트랜잭션을 최신 정보로 복원하기 때문에 마지막 전체 백업 테이프만 있으면 됩니다. 이와 같이 복원할 때는 Erase Existing Data를 선택하지 마십시오. 최신 로그 파일이 지워지게 됩니다.

순환 로깅 기능이 해제되어 있으면 차등 백업을 사용할 수 없습니다. 이에 대한 자세한 내용은 아래의 로그 파일과 순환 로깅 절에 나와 있습니다.

로그 파일과 순환 로깅

로깅 설명

Exchange Server는 여러 데이터베이스 파일(저장소)을 최종 사용자가 알 수 있는 구조로 관리합니다. 예를 들어, 정보 저장소는 개인(PRIV.EDB) 및 공용(PUB.EDB)의 두 데이터베이스로 이루어지며, 둘 다 정보 저장소 서비스에서 관리합니다. Exchange 디렉터리는 DIR.EDB에 저장됩니다. Exchange Server 서비스는 이들 각각의 데이터베이스에 대해 트랜잭션 로그 파일을 사용합니다.

Exchange 데이터베이스 기술은 로그 파일이 데이터를 받아들이고, 추적하고, 관리하도록 구현합니다. 성능과 복원성을 개선하려면 우선 모든 메시지 트랜잭션이 로그 파일과 메모리에 기록된 다음, 해당 데이터베이스 파일로 기록되어야 합니다. 로그 파일이 순차적으로 기록되고(검색 시간이 없어짐) Exchange Server가 메시지 트랜잭션을 즉시 로그 파일에 기록하기 때문에 클라이언트 성능이 향상됩니다. 그러나 로그 파일은 항상 파일 끝에 추가되며 Exchange 데이터베이스 파일(PUB.EDB, PRIV.EDB 및 DIR.EDB)은 임의의 순서로 기록되므로 성능에 영향을 미치는 검색 시간이 발생하게 됩니다.

하드웨어 오류로 정보 저장소나 디렉터리 데이터베이스 파일이 손상된 경우, 백업된 로그를 변경하지 않은 한 로그 파일을 사용하여 메시지 트랜잭션 데이터를 복원할 수 있으므로 복원성이 좋아집니다. 로그 파일은 보통 정보 저장소와 디렉터리 데이터베이스 파일과는 별개의 물리 디스크 드라이브에 보관되므로, 데이터베이스 파일에 영향을 주는 고장이 발생하더라도 로그 파일에는 영향을 미치지 않게 됩니다. 백업되지는 않았지만 트랜잭션 로그에 데이터를 기록했다면 뒤로 "재생"하여 데이터베이스 파일을 복원할 수 있습니다.

디렉터리와 정보 저장소 서비스에서는 트랜잭션 로그, 이전 로그, 검사점 파일, 예약된 로그, 패치 파일을 사용합니다.

트랜잭션 로그

트랜잭션 로그는 각각의 .EDB 파일과는 별개의 물리 드라이브에 보관될 수 있습니다. 기본값으로 정보 저장소 로그는 \exchsrvr\mdbdata에 보관되며 디렉터리 서비스 로그는 \exchsrvr\dsadata에 보관됩니다. 각각의 하위 디렉터리에는 해당 서비스에 대한 현재의 트랜잭션 로그인 EDB.LOG 파일이 들어 있습니다. 정보 저장소 하위 디렉터리와 디렉터리 서비스 하위 디렉터리는 별개의 EDB.LOG 파일을 관리합니다.

로그 파일은 항상 5MB여야 하며 크기가 다른 파일은 손상되었을 가능성이 큽니다. 트랜잭션은 우선 EDB.LOG 파일에 기록한 다음 데이터베이스에 기록하기 때문에, 데이터베이스 크기는 메모리에도 상주하는 트랜잭션 로그 파일의 커밋되지 않은 트랜잭션과 실제 .EDB 데이터베이스 파일이 합쳐진 크기입니다. EDB.LOG 파일이 트랜잭션 데이터로 채워진 후에는 이름이 바뀌고 새로운 EDB.LOG 파일이 만들어집니다.

이전 로그

EDB.LOG의 이름이 바뀌면 이름이 바뀐 로그 파일은 EDB.LOG 파일과 동일한 하위 디렉터리에 저장됩니다. 로그 파일의 이름은 16진수를 사용하여 EDB00014.LOG, EDB00015.LOG와 같이 순차적으로 정해집니다. 이전에 커밋된 로그 파일은 온라인 일반(전체) 백업 동안이나 NTBACKUP.EXE를 사용한 온라인 증분 백업 동안에 제거됩니다. 이전 로그 파일은 제거되지 않습니다. 5MB의 트랜잭션이 기록될 때마다 새 로그가 만들어지지만 꼭 커밋될 필요는 없습니다. 특정 시점에서, 커밋되지 않은 여러 개의 이전 로그가 있을 수 있는데 이러한 로그는 제거되지 않습니다. 순환 로깅 기능이 설정되면 이전 로그의 내용은 유지되지 않으며 백업 작업을 통해 제거되지 않습니다. 사실 순환 로깅 기능이 설정된 경우에는 증분 및 차등 온라인 백업이 허용되지 않습니다.

서비스가 정상적으로 종료되면 로그 파일의 트랜잭션이 해당 .EDB 파일로 커밋됩니다. 예를 들어, 정보 저장소 서비스가 정상 종료(오류 없이 서비스가 종료)되면 로그 파일에는 있지만 PRIV.EDB나 PUB.EDB 파일에는 없는 트랜잭션이 .EDB 파일로 커밋됩니다. 로그 파일은 서비스가 실행되는 동안 수동으로 제거해서는 안됩니다. 일반적으로 로그는 백업 프로세스 도중 제거하는 것이 가장 좋습니다.

검사점 파일과 검사점

검사점 파일은 트랜잭션 로그의 데이터를 .EDB 파일로 복구(재생)하는 데 사용됩니다. 검사점은 커밋된 트랜잭션을 나타내는 EDB.CHK 파일에서의 위치 표식입니다. 정보 저장소와 디렉터리 서비스는 별개의 EDB.CHK 파일을 관리합니다. 데이터가 트랜잭션 로그에서 .EDB 파일로 기록될 때마다, EDB.CHK 파일은 트랜잭션이 해당 .EDB 파일로 성공적으로 커밋되었음을 나타내는 정보와 함께 업데이트됩니다. 복구 도중 Exchange는 EDB.CHK 파일을 읽거나 트랜잭션 로그 파일을 직접 읽어서(이 경우 EDB.CHK는 필요하지 않음) 어떤 트랜잭션이 아직 커밋되지 않았는지 결정합니다. 정보 저장소와 디렉터리 서비스는 시작 과정에서 자신의 EDB.CHK 파일을 읽고 트랜잭션 로그를 사용하여 커밋되지 않은 트랜잭션을 .EDB 파일로 재생합니다. 예를 들어, Exchange 서버가 중단되고 트랜잭션이 트랜잭션 로그에 기록되었지만 데이터베이스에는 기록되지 않은 경우, Exchange는 시작할 때 로그에서 데이터베이스 파일로 트랜잭션을 자동으로 기록함으로써 복구를 시도합니다.

예약된 로그

디렉터리와 정보 저장소 서비스는 개별적으로 RES1.LOG와 RES2.LOG의 두 예약 파일을 MDBDATA와 DSADATA에서 관리합니다. EDB.LOG 파일의 이름을 바꾸고 새 파일을 만들 때 서비스할 디스크 공간이 부족해지는 경우에 예약 로그 파일을 사용합니다. 이는 긴급한 경우에만 사용하는 일종의 안전 장치입니다. 이러한 상황이 발생하면 데이터베이스 엔진은 해당 서비스로 오류를 보내며, 아직 트랜잭션 로그에 기록되지 않은 메모리에 있는 트랜잭션을 RES1.LOG(필요한 경우 RES2.LOG도)에 플러시합니다. 그런 다음 서비스가 종료되고 Windows NT 이벤트 로그에 이벤트를 기록합니다. RES 트랜잭션 로그 파일의 크기는 다른 트랜잭션 로그 파일과 마찬가지로 항상 5MB입니다.

패치 파일

온라인 Exchange 백업을 수행하는 동안에도 .EDB 파일에 대해 트랜잭션이 입력될 수 있습니다. 아직 백업되지 않은 .EDB 파일 일부에 대해 트랜잭션이 발생한 경우 단순히 처리되기만 합니다. 이미 백업된 .EDB 파일 일부에 대해 하나의 트랜잭션이 발생하면 .PAT(패치) 파일에 기록됩니다. 각각의 데이터베이스에 대해 별개의 .PAT 파일(RIV.PAT, PUB.PAT 및 DIR.PAT)이 사용되며, 이 파일들은 백업 프로세스 도중에만 보여집니다.

다음은 온라인 백업 시퀀스에서 .PAT 파일이 사용되는 방법입니다.

• 현재 데이터베이스에 대해 .PAT 파일이 만들어집니다.
• 현재 .EDB 파일에 대한 백업이 시작됩니다.
• 이미 백업된 .EDB 파일의 일부로 기록되어야 하는 트랜잭션은 .EDB와 .PAT 파일로 기록됩니다.
• .PAT 파일이 백업 테이프로 기록됩니다.
• .PAT 파일이 \MDBDATA 또는 \DSADATA에서 삭제됩니다.

TEMP.EDB

이 파일은 진행중인 트랜잭션을 저장하며 온라인 압축 과정에서 임시 저장소로 사용됩니다.

백업에서 로그 파일을 삭제하는 방법

순환 로깅 기능이 해제된 경우 로그 파일은 온라인 일반(전체) 또는 증분 백업이 수행될 때까지 트랜잭션 로그 디스크 드라이브에 쌓입니다.

다음은 온라인 백업 시퀀스에서 제거가 이루어지는 방법입니다.

• 백업 프로세스는 지정된 데이터베이스 파일을 백업합니다.
• 필요하면 백업 도중 이미 처리된 .EDB의 일부로 기록된 트랜잭션을 관리하기 위해 패치 파일이 만들어집니다.
• 백업 프로세스 도중 만들어진 로그 파일이 테이프로 복사됩니다.
• 패치 파일이 테이프로 기록됩니다.
• 백업 작업을 시작할 시점의 검사점보다 오래된 로그 파일은 제거됩니다. 트랜잭션이 이미 .EDB 파일로 커밋되고 .EDB 파일이 테이프로 기록되었으므로 이 작업은 필요치 않습니다.

데이터베이스 순환 로깅

순환 로깅(기본적으로 사용 가능)은 트랜잭션 로그 기술을 사용하지만 이전 트랜잭션 로그 파일은 관리하지 않습니다. 대신 몇 개의 로그 파일 창을 관리하고, 트랜잭션 로그 파일의 트랜잭션이 데이터베이스로 커밋된 후 기존 로그 파일을 제거하고 이전 트랜잭션을 삭제합니다. 이렇게 하면 디스크 공간을 관리하는 데 도움이 되며 트랜잭션 로그가 작성되는 것을 방지할 수 있지만, 차등 백업이나 증분 백업에서 이전 트랜잭션 로그 파일을 필요로 하기 때문에 사용자는 이들 백업을 사용할 수 없습니다. 실제로, 순환 로깅은 일부 트랜잭션 로그 파일을 제거하므로 트랜잭션 로그 파일을 통해 앞으로 재생하는 것으로는 오류가 있었던 시점까지 복원하지 못할 수가 있습니다. 이러한 경우에는 한 두개의 트랜잭션이 손실될 수 있습니다. 이런 이유로 모든 Exchange 서버에서 순환 로깅 기능을 해제하는 것이 좋습니다. 백업된 후에는 하드 디스크에서 로그 파일을 제거하므로 정기적인 온라인 백업을 통해 디스크 공간을 쉽게 관리할 수 있습니다.

순환 로깅 기능이 설정되면 여러 개의 EDBXXXXX.LOG 파일이 \MDBDATA나 \DSADATA 하위 디렉터리에 나타날 수도 있습니다. 이는 Exchange가 겹쳐서 나타나는 순환 창을 설정하기 전에 여러 개의 로그 파일을 사용하므로 정상적인 현상입니다. 예를 들어, EDB00010.LOG, EDB00011.LOG, EDB00012.LOG 및 EDB00013.LOG 로그 파일 이름의 숫자가 증가되어 EDB00011.LOG, EDB00012.LOG, EDB00013.LOG 및 EDB00014.LOG로 됩니다. 이 경우 숫자는 16진수입니다.

Exchange는 순환 로깅을 위한 로그 파일 창을 4개로 유지하려 하지만, 서버의 입출력 로드가 크면 그 이상을 사용합니다. 위에서 만들어진 로그 파일 중 처음 네 개는 정보 저장소나 디렉터리 서비스와 같은 해당 서비스가 중지되었다가 다시 시작될 때까지 제거되지 않습니다.

순환 로깅의 설정 여부를 판별하는 방법

데이터베이스의 순환 로깅 설정을 검토하려면:

1. Exchange 서버 관리자 프로그램을 실행합니다.
2. Site, Configuration 및 Servers 개체를 누르고 원하는 서버를 선택합니다.
3. File, Properites 메뉴를 누릅니다.
4. Advanced 탭을 누릅니다. 정보 저장소와 디렉터리에 대해 별도로 순환 로깅을 설정할 수 있습니다

Exchange 관리자 프로그램에서 순환 로깅 설정을 변경할 수 있습니다. 그러나 변경한 경우에는 Exchange가 해당 서비스를 중지하고 다시 시작합니다.

복구 예—트랜잭션 로그

상태 순환 로깅 기능이 설정되어 있지 않고 트랜잭션 로그가 데이터베이스 파일과는 별개의 디스크에 저장되어 있으며, 이틀 전에 마지막 전체(일반) 백업을 하였습니다. 하드웨어 오류(하드 디스크 불량)로 인해 정보 저장소 데이터베이스가 손상되었지만 트랜잭션 로그 드라이브는 손상되지 않았습니다.

질문—완전히 복원할 수 있습니까, 아니면 2일간의 프로덕션 데이터를 잃어버리게 됩니까?

답—데이터는 손실되지 않습니다. 트랜잭션 로그가 완벽하므로 이 로그에는 전체 백업 이후의 모든 트랜잭션이 포함되어 있으며 복원 하드웨어 플랫폼은 전체 복원을 수행합니다. 기존 로그 파일을 제거하려고 시도하지 마십시오. 즉, 기존 데이터 모두 지우기를 선택하지 마십시오. 전체 복원은 전체 백업을 수행하여 백업된 로그 파일과 데이터베이스 파일을 작성합니다. 현재 트랜잰션 로그 드라이브의 첫 번째 로그 파일까지 복원됩니다. 예를 들어, 전체 백업은 EDB00012.LOG에서 EDB00014.LOG까지 복사했습니다. 트랜잭션 로그 드라이브의 로그 파일은 EDB00015.LOG부터입니다. 전체 복원은 EDB00012.LOG에서 EDB00014.LOG까지의 로그 파일과 백업 세트의 일부인 정보 저장소 데이터베이스 파일을 복사합니다. 정보 저장소가 시작되면 EDB00012.LOG에서 마지막 로그 파일(EDB00019.LOG)까지의 트랜잭션을 다시 재생한 다음 가장 최근의 로그 파일인 EDB.LOG를 다시 재생합니다. 그런 다음 서비스가 시작되고 데이터베이스는 최신 정보를 갖게 됩니다. 로그 파일은 로그 파일이 다시 재생될 시퀀스의 일부임을 나타내는 서명을 가지고 있습니다.

키 관리 서버 백업

KM 데이터 파일(버전 4.0과 5.0의 경우 C:\SECURITY\MGRENT, 버전 5.5의 경우 \EXCHSRVR\KMSDATA)을 다른 데이터와 별도로 백업하여 이 백업 테이프를 일일 백업보다 더 안전하게 보관하는 것이 좋습니다. 이들 파일의 모든 실제 키는 64비트 CAST 암호화되었으므로 아주 안전하지만 조심해서 취급해야 합니다. 여기에는 모든 사용자의 개인 암호 키가 포함되어 있으며 Exchange에서 인식 가능한 NTBACKUP 프로그램은 이를 백업하지 않습니다.

테이프 카트리지의 문제는 오프라인 백업 매체라는 점입니다. 테이프를 입수한 사람이 파일을 서버로 복원하여 암호 키를 크랙하려고 시도할 수 있는데, 그 사람이 온라인으로 로그온한 상태이거나 기타 다른 이유 때문에 이를 발견하지 못할 수가 있습니다.

대부분의 침입자들에게 있어 64비트 키를 크랙하는 것은 기술적으로 불가능합니다. 전문가들의 계산에 따르면 12년 이상의 시간과 300,000달러 상당의 암호 해독 하드웨어가 필요하며 PC 기술을 사용할 때는 그 이상이 필요합니다. 키 길이, 예상되는 해독 시간 및 기타 문제에 대한 사항은 http://www.bsa.org/를 참조하십시오. 아직까지 안심할만한 수준이기는 하지만, 기술은 매년 발전하고 있으며 악의를 가진 침입자에게 아주 영리한 지능과 풍분한 자원이 있을 수도 있다는 점을 명심해야 합니다. KM 데이터베이스를 정보 시스템에서 가장 안전한 자산 중 하나로 취급하십시오.

KM 서버 데이터 백업

1. 키 관리 서버 서비스를 중단합니다.

   데이터를 백업합니다.

   • Exchange 4.0과 5.0의 경우 SECURITY\MGRENT 디렉터리를 백업합니다.
   • Exchange 5.5의 경우 EXCHSRVR\KMSDATA 디렉터리를 백업합니다.
2. KM 서버 시동 디스크를 백업합니다.
3. KM 서버 서비스를 시작합니다.

Windows NT 백업 유틸리티를 사용하여 고급 보안 파일과 하위 디렉터리를 정기적으로 백업합니다. 보안 파일이 손상되었거나 보안 로그온 암호를 잊어버린 사용자는 보관된 모든 메시지를 포함하여 암호화된 메시지를 열 수 없습니다. 관리자가 키를 복구할 수도 있지만 이는 고급 보안 데이터가 최신 상태인 경우에만 가능합니다. 이러한 복구 절차에 대한 내용은 Microsoft Exchange Server 설명서에서 "고급 보안 키 복구" 항목을 참고하십시오.

데이터베이스 아키텍처에 대한 상세 정보

트랜잭션 로그가 있는 신뢰할 수 있는 데이터 저장소

Microsoft SQL Server와 같은 관계형 데이터베이스에서 아이디어를 빌려, Exchange Server 정보 저장소와 디렉터리 서비스는 별개의 트랜잭션 로그 파일을 사용하여 성능과 데이터 무결성을 향상시킵니다. 모든 변경 사항은 즉시 순차 트랜잭션 로그에 기록된 다음 실제 원본 데이터베이스 파일로 커밋됩니다. 전원이 꺼지거나 예기치 못하게 서버가 종료된 경우 데이터는 마지막 전체 트랜잭션까지 복원 가능한 상태로 그대로 남아 있습니다. 이 아키텍처는 데이터가 일관되지 않거나 손상된 상태로 남아 있지 않도록 해줍니다.

데이터베이스 트랜잭션 무결성에 대한 ACID 테스트(원자성, 일관성, 격리 및 지속성)가 개발된 1970년대 이후로 데이터베이스 트랜잭션 무결성의 근본 원리는 널리 알려져 왔습니다. 정보 저장소의 원본인 데이터베이스는 이들 속성을 모두 지원합니다.

• 원자성—트랜잭션 결과가 모두 커밋되거나 모두 롤백됩니다. Exchange Server에서 원자성 작업은 트랜잭션 로그를 사용하여 수행됩니다. 위에서 설명한 바와 같이 주 데이터베이스 파일로 아직 커밋되지 않은 로그의 트랜잭션은 롤포워드되어 커밋되거나, 불완전한 경우 롤백됩니다. 이 프로세스는 시스템이 다시 시작할 때 즉시 자동으로 이루어집니다.
• 일관성—공유 자원(예: 데이터베이스)은 항상 유효한 하나의 상태에서 다른 상태로 바뀝니다. Exchange Server 정보 저장소의 모든 작업은 원자성의 성격을 가지며 데이터가 항상 일관된 상태에 있도록 보증해줍니다. 트랜잭션이 주 데이터베이스 파일로 완전히 커밋되었음을 나타내기 위해 트랜잭션 로그를 업데이트하는 것은 원자성 작업입니다.
• 격리성—트랜잭션은 순차적일 수 있습니다. 여러 개의 동시 트랜잭션을 처리하는 시스템에서, 특정 트랜잭션의 결과는 시스템에서 이 트랜잭션만 실행했을 때와 동일합니다. 이는 당연히 여러 사용자가 데이터에 동시에 안전하게 액세스할 수 있음을 의미합니다. 동시 사용자 작업이 데이터베이스를 잘못되게 만드는 식의 방해를 일으키지는 않습니다. 격리 등록 정보는 Exchange Server 정보 저장소의 원본 데이터베이스에서 수행됩니다.
• 지속성—트랜잭션 결과는 영구적이며 이후의 시스템과 매체가 고장나더라도 그대로 남아 있게 됩니다. 물리 드라이브 손상 등으로 인해 Exchange Server 트랜잭션 로그 파일 일부가 손상되거나 읽을 수 없게 된 경우 이 트랜잭션은 단순히 롤백됩니다. 트랜잭션 로그의 물리 형식은 저장 매체가 손상된 경우라 할지라도 그 영향을 줄여주도록 세심하게 설계되었습니다. 이는 순차 기록, 5MB 단위의 새 로그 파일 작성, 그리고 핑퐁 로깅과 같은 하위 수준 기술을 통해 이루어지는데, 부분적으로 손상된 로그 파일 내에서도 트랜잭션의 지속성이 극대화되도록 해줍니다.

데이터는 먼저 로그에 기록된 다음 주 데이터베이스 파일로 커밋되기 때문에 트랜잭션 로그로 인해 많은 오버헤드가 발생하는 것처럼 보이지만, 실제로는 여러 가지 이유로 인해 적당한 트랜잭션 로그를 사용함으로써 전체적인 시스템 처리율이 개선됩니다. 트랜잭션 로그 파일이 별도의 디스크에 보관될 때 이 파일들은 임의 액세스가 아니라 순차적으로 기록됩니다. 디스크 드라이브 헤드는 임의로 검색할 필요가 없으므로, 현재의 고속 하드 드라이브 하위 시스템에서조차 주 데이터베이스 파일에 임의 액세스하여 기록하는 것보다 더 빠른, 크기 순서로 되어 있습니다. 로깅된 트랜잭션은 주 데이터베이스 파일로 "천천히" 커밋되는데 이는 매우 효율적으로 수행될 수 있습니다. 그 이유는 서버가 유휴 사이클을 가질 때 비동기적으로 수행되며, Windows NT Server의 NTFS 및 FAT 디스크 캐시 시스템이 물리 헤드 검색을 최소화하는 엘리베이터 탐색과 같은 고전적인 기술을 사용하여 가장 효율적인 방식으로 기록하도록 자동으로 명령하기 때문입니다. Exchange Server 복구 기술은 트랜잭션 로그가 데이터의 변경된 부분만 기록하기 때문에 큰 레코드의 경우에도 작은 레코드에서와 마찬가지로 잘 작동합니다.

트랜잭션 롤백을 사용한 빠른 자동 복구

비정상적인 서버 종료 후 Exchange Server 정보 저장소나 디렉터리 서비스가 시작되면 불완전한 트랜잭션이 있는지 확인하기 위해 트랜잭션 로그 파일을 검사합니다. 불완전한 트랜잭션이 있으면 종료 이전의 상태로 자동 롤백됩니다. 이러한 자동 복구 작업은 로그에서 가장 최근의 트랜잭션만 검사되므로 상대적으로 빠르게 이루어집니다.

이러한 복구 능력의 차이는 Microsoft SQL Server나 Oracle 등의 프로덕션 DBMS 서버와 Microsoft Access나 Lotus Approach 등의 최종 사용자 데이터베이스 사이의 차이점과 유사합니다.

자동 참조 무결성을 갖는 단일 인스턴스 저장소

단일 인스턴스 저장소는 사용자 메일을 중앙 서버에 저장하려는 고객에게는 반드시 필요한 요구 사항입니다. 한 서버에 있는 100명의 사용자가 동일한 메시지를 받은 경우 하나의 메시지 인스턴스만 서버에 저장됩니다. 이 경우 메시지에 대한 포인터는 각 사용자의 사서함에 위치합니다. 단일 인스턴스 저장소는 공간을 절약하고 서버 성능을 향상시켜줍니다.

Exchange Server의 정보 저장소 설계에는 기본 제공되는 단일 인스턴스 저장소가 있습니다. 이 저장소는 항상 유효하며 특별한 구성이나 관리는 필요치 않습니다. 메시지나 사용자 사서함이 삭제될 때 메시지는 연결이 끊기거나 손실될 수 없습니다. 한 파일 내에 모든 내용이 저장되며 참조 무결성은 데이터베이스 엔진에서 내부적으로 처리되므로, 파일들 사이에서 포인터가 동기화를 벗어나지 않게 됩니다. Exchange Server는 효율적이고 신뢰성 있는 서버상의 메시지 저장소가 될 수 있도록 최적화됩니다.

사용자별로 저장소가 제한되는 단일 인스턴스 저장소

조사에 따르면 메일 시스템 중단이 발생하는 가장 흔한 이유 중 하나는 사용자 저장소를 제한할 수 없다는 점이며, 이로 인해 서버가 가득 차게 되서 작업이 중단하는 것입니다. 이를 방지하기 위해 Exchange Server는 관리자가 사용자에서 시스템까지 어떤 수준에서도 디스크 할당량을 설정할 수 있도록 허용합니다. 사용자는 경고 뿐 아니라 자신의 사서함을 정리할 때까지 메일을 보낼 수 없도록 하는 "강력한" 제한을 받게 됩니다. 이렇게 함으로써 사용자가 중요한 전자 메일을 못받게 되는 일이 없어지며, 다른 사용자들이 "경고를 받은" 사용자에게 메일을 보낼 때 그 메일이 배달되지 못하는 문제가 발생하지 않게 됩니다.

365일 하루 24시간 작업할 수 있도록 테이프로의 라이브 온라인 백업

Exchange Server에는 온라인으로 직접 테이프에 백업하기 위해 기본 제공되는 지원 요소가 있습니다. 서버를 종료하지 않아도 되며 사용자도 로그오프할 필요가 없습니다. 또한 Exchange Server 백업이 Windows NT Server 백업과 통합되어 있으므로 한 위치에서 두 종류의 서버를 모두 백업할 수 있습니다. ¼인치 카트리지부터 고용량의 DAT 시스템에 이르기까지 다양한 테이프 장치로 직접 전체, 증분 또는 차등 백업을 수행할 수 있습니다.

데이터 복구 시나리오

아래에서는 단일 항목, 전체 서버, 그리고 .PST, .OST 및 .PAB의 세 가지 복구 시나리오에 대해 설명합니다.

단일 항목 복구

단일 항목이란 개인 사서함, 공용 폴더, 메시지 또는 개인 폴더를 의미합니다. 이러한 복구에는 아래와 같은 다양한 방법들이 이용됩니다.

• 전체 개인 정보 저장소를 복원하여 단일 사서함 복구
• Exchange 5.5 삭제된 항목 보존(Deleted Items Retention) 기능을 사용한 단일 항목 복구
• 타사의 백업 프로그램을 사용한 단일 항목 복구

단일 사서함 복구

Exchange 4.0과 5.0에서 이 절차를 사용하여 삭제된 전체 사서함이나 개인 항목을 복구합니다. Exchange 5.5의 삭제된 항목 보존 기능을 사용하면 메시지, 폴더 또는 공용 폴더에 대해 이 절차를 수행할 필요가 없습니다. 그러나 삭제한 사서함을 복구하기 위해서는 반드시 이 절차를 따라야 합니다.

주의 프로덕션 서버에서는 이 절차를 수행하지 마십시오. 프로덕션 Exchange 사이트의 일부가 아닌 서버에 데이터를 복원해야 합니다. 전용 복구 서버는 프로덕션 사이트와 동일한 사이트 및 조직 이름을 사용하여 설치되지만 복구 Exchange Server를 설치할 때 Create A New Site 옵션을 선택해야 합니다.

요구 사항

• 전체 개인 정보 저장소 데이터베이스를 복원할 수 있을 만큼의 충분한 용량을 갖는 전용 서버
• 정보 저장소 개인 데이터베이스의 백업
• Exchange 클라이언트와 Exchange Server 설치 코드
• Windows NT 및 Windows NT 서비스 팩 설치 코드

이 절차를 수행하여 사서함을 복구할 수도 있습니다. 중앙에서 지원하는 조직의 경우 지점 사무실에서 우편을 통해 내부 "복구 센터"로 테이프를 보낼 수 있는데, 이렇게 하면 서버 이름에 상관없이 조직의 서버에 대한 단일 사서함 복구가 가능합니다.

전체 정보 저장소를 복원한 후에는 특정 사서함에서 데이터를 가져와야 합니다. Windows NT Server가 실행될 서버를 준비하고, 손실된 사서함이 있었던 사이트 및 조직의 이름과 동일한 이름을 사용하여 Exchange를 설치합니다. 백업 테이프로부터 정보 저장소를 복원하고 Exchange 관리자 권한으로 로그온하고 원하는 사서함에 Windows NT 관리자 ID 액세스 권한을 할당합니다. 데이터를 .PST 파일로 복원하고 .PST를 사용자 프로필에 첨부합니다.

복구 서버 준비

1. 프로덕션 복구 서버가 아닌 서버를 준비합니다. 일부 시스템에서는 복구 서버를 항상 실행하여 언제나 사용할 수 있도록 유지합니다. 이 컴퓨터를 Windows NT PDC, BDC 또는 구성원 서버로 설치할 수 있으며 적절한 Windows NT 서비스 팩이 설치되어 있어야 합니다. 백업 테이프로부터 전체 정보 저장소를 복원할 만한 디스크 공간이 있는지, 프로덕션 서버의 드라이브와 호환되는 테이프 드라이브가 장착되어 있는지, 그리고 테이프 드라이브가 테스트를 마쳐 작동이 되고 있는지 확인합니다.
2. 새 사이트를 만듭니다(사이트를 조인하지 마십시오). 다음은 Exchange를 설치할 차례입니다. 이 때 사이트를 조인하지 마십시오. 복구 서버는 사용자의 프로덕션 사이트에 조인되지 않은 독립형 컴퓨터이어야 합니다.
3. Windows NT에 관리자로 로그온한 후, 사서함을 복구하는 서버에서 사용된 사이트 및 조직 이름과 동일한 이름을 사용하여 전체 Exchange 설치를 수행합니다. 사이트를 조인하지 마십시오. 단일 사서함 복원 시에는 디렉터리가 아니라 정보 저장소만 복원하므로 복원 컴퓨터의 서버 이름은 문제가 되지 않습니다. 위치별로 전용 복구 서버가 있으면 Exchange를 설치한 상태로 놓아둘 수 있지만, 여러 사이트가 복구 서버를 공유하는 경우에는 필요한 사이트와 조직을 기준으로 설치할 수 있도록 Exchange 설치 코드 복사본을 하드 디스크에 보관해야 합니다. 이 Exchange 설치 경로는 복구될 프로덕션 Exchange 설치 경로와 일치하지 않아도 됩니다.
4. 정보 저장소가 마지막으로 백업되었을 때 프로덕션 컴퓨터에 있었던 Exchange 서비스 팩을 설치합니다. 백업을 수행할 때 프로덕션 서버에 서비스 팩 1이 있었고 그 이후로 서비스 팩 2를 설치했다면, 정보 저장소를 복원하기 전에 복구 서버에 서비스 팩 1을 설치합니다.
5. 복구 서버에 Exchange 클라이언트를 설치합니다.

테이프에서 정보 저장소 복원

이 절차에서는 일반 온라인 백업 테이프를 사용하여 복원합니다. 오프라인 테이프를 사용할 수도 있지만 이 경우에는 몇 가지 단계가 추가로 필요합니다. 이에 대해서는 이 절차 다음에 설명합니다.

1. 드라이브에 백업 테이프를 넣습니다.
2. 복구 도메인에 관리자로 로그온합니다.
3. 관리 도구 그룹에서 백업을 실행합니다.
4. 풀다운 메뉴에서 조작, Microsoft Exchange를 누릅니다.
5. 테잎 아이콘을 누르고 테이프 이름을 두 번 누릅니다. "읽어들이는 중"이라고 표시된 카탈로그 상태 상자가 나타납니다.
6. 테잎 창 오른쪽에 있는 "ORG\SITE\SERVER"\information store를 누릅니다.
7. 백업 초기 화면의 위쪽에 있는 복원 단추를 누릅니다.
8. 복원 정보 화면에서 대상 서버 필드(HOTSPARE)에 대상 서버 이름을 입력합니다.
9. 기존 데이터 모두 지우기, 개인, 공용, 복원 후 확인 및 복원 이후에 서비스 시작을 선택합니다. 확인 단추를 누릅니다.
10. 복원 메시지 "Microsoft Exchange 구성 요소를 복원하려고 합니다. 대상 서버의 Microsoft Exchange 서비스를 중지합니다."가 나타나면 확인을 누릅니다.
11. 상태 확인 화면에서 확인을 누릅니다.
12. 제어판을 누른 다음 서비스를 눌러 Exchange 서비스가 실행 중인지 확인합니다.

사용 가능한 오프라인 백업

Exchange 정보 저장소에 대한 오프라인 백업이 있으면 다음 단계를 따르십시오.

1. 모든 Exchange 정보 저장소 서비스를 중지합니다.
2. 다음 레지스트리 위치에서 정보 저장소 서비스에 대한 데이터베이스와 로그 위치를 확인합니다.

   정보 저장소 서비스 로그 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\DB 로그 경로

   개인 정보 저장소 데이터베이스 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate\DB 경로

   공용 정보 저장소 데이터베이스 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic\DB 경로

3. 모든 드라이브의 EXCHSRVR\MDBDATA 디렉터리에서 전체 파일을 이동합니다.
4. PRIV.EDB 파일을 개인 정보 저장소 데이터베이스 경로로 복사합니다.
5. PUB.EDB 파일을 공용 정보 저장소 데이터베이스 경로로 복사합니다.
6. 정보 저장소 로그 파일을 정보 저장소 서비스 로그 경로로 복사합니다.
7. Exchange 디렉터리 서비스가 시작되는지 확인합니다.
8. 명령 프롬프트에서 EXCHSRVR\BIN 디렉터리로 이동하고 다음 명령을 실행합니다.

   isinteg –patch

9. 정보 저장소 서비스를 시작합니다.

사용자 사서함 복구

1. Windows NT 관리자 ID로 복구 서버에 로그온합니다.
2. Exchange 관리자 프로그램을 실행합니다. DS/IS consistency adjuster를 실행합니다. 서버 이름을 강조 표시합니다. File 메뉴에서 Properties 명령을 눌러 Server 개체의 등록 정보를 불러옵니다. Advanced 탭을 누릅니다.

   버전 4.0 또는 5.0의 Exchange 관리자 프로그램을 실행하는 경우 All Inconsistencies를 누른 다음 Adjust 단추를 누릅니다.

   버전 5.5 Exchange 관리자 프로그램을 실행하는 경우 Advanced 페이지에서 Consistency Adjuster 단추를 눌러 DS/IS consistency adjuster 대화 상자를 불러옵니다. 개인 및 공용 정보 저장소에 대한 옵션을 모두 선택하고 All inconsistencies를 누른 다음 OK를 누릅니다.

3. Recipients 컨테이너를 선택하고 원하는 사용자 사서함 이름을 두 번 누릅니다.
4. General 탭에서 Primary Windows NT Account 단추를 누릅니다.
5. Primary Windows NT Account 대화 상자에서 Select An Existing Windows NT Account를 누른 다음 OK를 누릅니다
6. Add User Or Group 화면에서 Administrator와 Add 단추를 누른 다음 OK를 누릅니다
7. User Property 화면에서 <OK를 누릅니다.
8. Windows NT 제어판에서 편지 및 팩스를 실행합니다.
9. 원하는 사용자에 대한 프로필을 구성합니다.
10. 프로필에 개인 폴더 파일을 추가합니다.
11. Exchange 클라이언트를 실행합니다.
12. 왼쪽 창에서 Mailbox - <사용자 이름>을 선택합니다.
13. 오른쪽 창에 있는 목록에서 첫 번째 폴더나 항목을 선택합니다.
14. 풀다운 메뉴에서 Edit와 Select All을 누릅니다.
15. 풀다운 메뉴에서 File을 누른 다음 Copy를 누릅니다.
16. Copy 화면에서 Personal Folder를 누른 다음 OK를 누릅니다. 모든 데이터가 이 .PST 파일로 복사됩니다.
17. .PST를 대상 위치로 복사합니다. 필요하면 테이프 백업과 복원을 사용할 수 있습니다.
18. 이 .PST를 프로덕션 서버의 사용자 프로필에 추가하거나 .PST를 설명과 함께 최종 사용자에게 보냅니다. 이 파일을 테이프로 보내야 할 수도 있습니다. 네트워크에 액세스할 수 있으면 복구된 .PST를 원하는 서버로 복사할 수 있습니다.
19. Outlook 사용자를 위해 전체 사서함을 복구하려는 경우에는 Outlook에 로그온해서 파일 메뉴의 가져오기와 내보내기 명령을 사용하여 전체 사서함을 .PST 파일로 내보내는 것이 더 쉽습니다.
20. 사용자가 Outlook 클라이언트 대신 Schedule+ 클라이언트를 실행하여 작업 일정을 잡는 경우 사용자의 Schedule+ 데이터를 복구해야 합니다. Schedule+에 사용자로 로그온하고 로컬 일정(.SCD) 파일을 만들기 위한 옵션을 선택한 다음 .SCD 파일을 사용자에게 보냅니다.

그림 1 Microsoft Exchange 단일 사서함 복구

단일 사서함 복구 서버의 이름과 Exchange를 실행하는 프로덕션 서버의 이름이 같을 필요는 없으므로 이 서버를 프로덕션 서버와 온라인으로 유지할 수 있습니다. 그러나 온라인으로 유지하는 경우, 프로덕션 서버에서 디렉터리 서비스 복제를 수행하게 해서는 안됩니다.

그림 2 Microsoft Exchange 단일 사서함 복구—예제 토폴로지

이는 단일 사서함 복구를 위한 예비용 서버를 관리하는 예입니다. 예비용 서버 "Sabc"는 프로덕션 사이트의 사이트 및 조직 이름을 사용하여 설치되었더라도 프로덕션 사이트에 조인되지는 않았습니다.

Exchange 5.5에서 단일 항목 복구

Exchange Server 5.5의 새로운 삭제된 항목 보존(항목 복구) 기능은 사용자가 개인 및 공용 정보 저장소에서 개인 폴더와 메시지를 복구할 수 있는 휴지통을 제공합니다. 휴지통은 전체 사서함을 삭제 취소하는 데는 사용할 수 없으며, 이를 위해서는 앞에서 설명한 절차를 따라야 합니다.

삭제된 항목 보존(Deleted Items Retention) 기능은 어떤 방식으로 작용합니까? 삭제된 항목 보존 기능은 개체가 삭제될 때 값이 변하는 새로운 특성을 각 개체에 부여함으로써, 정보 저장소가 클라이언트에서 볼 수 없도록 개체를 숨기게 만듭니다. 정보 저장소는 지정된 기간만큼 보관한 후 항목을 영구히 삭제합니다. 관리자는 저장소가 백업될 때까지 영구히 삭제되지 않도록 값을 설정할 수 있습니다.

삭제된 항목 보존 기능의 구성

삭제된 항목 보존 기능은 클라이언트에서 복구가 수행되는 경우에도 Exchange 관리자 프로그램으로부터 구성됩니다. 아래 그림에 표시된 것처럼 개인 정보 저장소나 사서함 수준에서 설정값을 구성할 수 있습니다. 개인 정보 저장소 수준은 서버의 모든 사서함에 적용되며 사서함 수준을 사용하여 정보 저장소 설정값을 무시할 수 있습니다.

그림 3 개인 정보 저장소에서 항목 복구 설정

그림 4 개인 사서함의 항목 복구 설정

Outlook 클라이언트에서 항목 복원

클라이언트는 Outlook 8.03이나 이후 버전에서 사용 가능한 확장명을 사용하여 실제 복구를 수행합니다.

사용자 사서함에서 삭제된 항목을 복원하려면 Outlook 클라이언트에서 지운 편지함 폴더를 누르고 도구 메뉴에서 지운 편지함 복원을 선택합니다. 다음 그림과 같은 지운 편지함 복원 대화 상자가 나타납니다.

그림 5 지운 편지함 복원 대화 상자

이제 사용자는 복구할 메시지나 폴더를 선택할 수 있습니다. 항목이 지운 편지함 폴더에 놓이고 사용자는 이 항목을 다른 위치로 옮길 수 있습니다.

삭제된 항목을 복구할 때 전체 정보 저장소를 복원하는 것보다 이 방법을 사용하는 것이 훨씬 쉬운 편리합니다.

참고 삭제된 항목이 정보 저장소에 남아 있음으로써 정보 저장소 크기가 커지게 되지만, 사용자의 저장소 할당량을 계산할 때는 이 크기를 포함해서 계산하지 않습니다.

타사의 백업 프로그램을 사용한 단일 항목 복구

일부 타사 공급업체는 개인 사서함, 폴더 및 공용 폴더를 백업하고 복원하는 Exchange 백업 솔루션을 제공합니다. 이러한 백업 프로그램을 사용하는 경우, 전체 정보 저장소를 복원하는 것이 아니라 손상되거나 삭제된 사서함이나 공용 폴더만 테이프에서 선택하여 복원할 수 있습니다. 이렇게 하면 시간을 많이 줄일 수 있지만 이러한 백업 솔루션에는 몇 가지 큰 제한이 있습니다. 이 솔루션은 개인 사서함이나 공용 폴더를 백업하는데, 서버의 전체 사서함이나 공용 폴더를 백업하는 것이 정보 저장소를 백업하는 것보다 더 시간이 오래 걸립니다. 각 사서함이나 공용 폴더의 데이터가 개별적으로 백업되며 모든 단일 인스턴스 저장소가 손실되어 정보 저장소보다 훨씬 데이터가 많아지기 때문입니다.

Exchange 5.5 데이터베이스 크기는 하드웨어에 의해서만 제한되므로 전체 Exchange Server에서 이러한 백업 프로그램을 매일 사용하는 것은 바람직하지 않습니다. 디렉터리 서비스와 정보 저장소의 경우에는 Exchange에서 인식 가능한 일반적인 백업 프로그램을 사용하고, 중요한 사서함과 공용 폴더에 대해서만 이러한 백업 프로그램을 사용하는 것이 좋습니다.

이러한 백업 소프트웨어를 사용하려는 경우에는 설명서에 나와 있는 기능과 제한 사항에 대한 내용을 읽어 보십시오. 예를 들어, 일부 제품은 Exchange 양식을 백업하거나 복원하지 않으며 .RTF 메시지를 일반 텍스트로 변환하는 제품도 있습니다.

전체 서버 복원

Exchange Server를 다른 물리 컴퓨터로 복원하는 것은 Windows NT를 다시 설치하여 새 레지스트리를 만들고 복이전 컴퓨터에 대해 새 Windows NT SID(보안 식별자)를 작성해야 하는 특별한 경우입니다. 새 SID는 Windows NT 레지스트리를 다른 서버로 복원할 때만 필요합니다. 예를 들어, 컴퓨터의 하드 디스크를 교체하고 Windows NT를 다시 설치하는 경우에는 새 SID를 만들 필요가 없습니다. 아래 설명된 절차는 Exchange 서버를 더 강력한 서버로 바꿀 때에도 유용합니다.

Exchange 서버 데이터베이스(정보 저장소 및 디렉터리 서비스)를 전체 복원해야 하는 경우 사용자 환경에 따라 Windows NT SAM 데이터베이스를 복원해야 할 수도 있습니다. 설치할 때 Exchange는 초기의 소프트웨어 설치 도중 로그온했던 Windows NT 계정과 Windows NT 서비스 계정을 자동으로 추가합니다. 이 두 계정 모두 설치 도중 특별한 권한을 부여받지만, Exchange 디렉터리 저장소를 복원할 때는 설치 도중 원래 사용되었던 Windows NT 계정 SID만 필요합니다. 이 SID는 액세스할 수 있는 Exchange 디렉터리 저장소에 대한 Windows NT 환경 내에 있어야 합니다. 어떠한 이유에서든 사용 가능한 원래 도메인의 도메인 컨트롤러가 없으면 Windows NT PDC SAM을 복원해야 합니다.

요구 사항

• 정보 저장소 및 디렉터리의 전체 백업
• 프로덕션 서버와 동일한 하드웨어 용량을 갖는 교체 PC
• 원래 Windows NT SAM에 대한 액세스
• 프로덕션 서버 구성 시트
• Exchange 설치 코드
• Windows NT Server 및 Windows NT 서비스 팩 설치 코드
• Exchange 프로덕션 서버 구성 시트

단일 사서함 복구보다는 복잡하지만, 전체 서버 복구는 Windows NT 보안 및 구성 정보 뿐 아니라 Exchange 구성 및 메시지 데이터가 복구되도록 원래 프로덕션 Exchange 기반 서버를 복원합니다. 복구 서버가 제자리에 놓인 후 사용자는 현재 암호를 사용하여 자신의 사서함에 로그온할 수 있습니다.

단일 사서함 복원의 경우에는 정보 저장소만 복원하지만 전체 서버 복구의 경우에는 정보 저장소 및 디렉터리 서비스 둘 다를 복원합니다. Exchange는 사서함 데이터에 대한 액세스를 위해 Windows NT 보안에 의존하며 Exchange 디렉터리에 있는 개체 등록 정보의 Windows NT 계정 SID 정보를 사용합니다.

디렉터리 서비스 복원을 성공적으로 수행하기 위해서는 다음과 같은 두 가지 중요한 조건이 필요합니다.

• 디렉터리 서비스는 프로덕션 서버와 동일한 사이트, 조직 및 서버 이름을 갖는 Windows NT 기반 서버에 복원되어야 합니다.
• 복구 서버는 Exchange Server가 원래 설치되었던 도메인으로부터 액세스할 수 있어야 합니다.

전체 서버의 재난 복구에는 세 가지 컴퓨터가 사용됩니다. 둘은 프로덕션 서버(PDC와 BDC)이고, 나머지 하나는 복구용으로 다른 프로덕션 작업에서 사용될 수도 있지만 보통은 프로덕션 서버가 아니며 반드시 필요한 것도 아닙니다. Exchange가 디렉터리 개체에 대한 인증을 제공하기 위해 Windows NT SAM(Security Accounts Manager) 데이터베이스를 사용하는 방식 때문에 프로세스에는 PDC/BDC/복구 서버 구성이 필요합니다. Exchange 서버의 전체 복원(정보 저장소 및 디렉터리 서비스)을 위해서는 처음에 Exchange 기반 서버가 설치되었던 도메인으로부터 SAM에 액세스할 수 있어야 합니다.

예: 금지되는 작업

예를 들어, 사이트에 PDC로 작동하는 하나의 Exchange 기반 서버와 하나의 오프라인 복구 서버가 있다고 가정해 보겠습니다. Exchange 정보 저장소와 디렉터리는 매일 야간에 백업됩니다. Exchange 서버가 손상된 경우, 단일 사서함 복원의 경우처럼 Exchange와 함께 핫 백업 PDC가 처음부터 만들어질 수 있으며 정보 저장소가 복원될 수 있습니다. Exchange 디렉터리가 복원되면 모든 디렉터리 개체의 보안 등록 정보는 계정에 대한 Windows NT SAM과 일치해야 하지만, 이 경우에는 PDC를 만들 때 새로운 SAM이 만들어지므로 일치하지 않습니다. 관리자는 Exchange 관리자 프로그램에 로그온할 수 없고 Exchange 서비스가 시작될 수 없으며 복원된 데이터를 액세스할 수 없습니다. 디렉터리를 제외하고 정보 저장소를 복원하면 관리자만이 사서함 데이터에 액세스할 수 있으며 이는 전체 서버 복구가 아닙니다. 원래의 Exchange 디렉터리 정보는 프로덕션 서버에서 사라집니다.

예: 필요한 작업

또 다른 예로, 전용 PDC가 있고 프로덕션 Exchange 서버가 BDC로 작동하며 복구 서버가 있다고 가정해 보겠습니다. 프로덕션 서버가 손상되었습니다. 이 경우 복구 서버에서 Windows NT Server 도메인 컨트롤러를 만들어 손상된 Exchange 서버와 동일한 컴퓨터 이름을 지정합니다. 이 컨트롤러를 BDC나 구성원 컨트롤러로서 도메인에 연결하면 프로덕션 Exchange 서버가 상주한 도메인에서 SAM의 복사본을 얻을 수 있습니다. 이를 위해 서버 관리자를 사용하여 원래 컴퓨터 이름(BDC 정의)을 PDC에서 삭제한 다음 BDC 설치 도중 그 이름을 다시 추가합니다. 각 컴퓨터가 도메인에 추가될 때 컴퓨터 이름이 고유한 SID를 갖게 되고 복이전 컴퓨터는 새로운 SID를 요구하므로 이 절차는 반드시 수행해야 합니다. 그런 다음 동일한 사이트 및 조직 이름을 사용하여 Exchange를 설치합니다. Exchange는 컴퓨터 이름을 사용해서 Exchange 서버 이름을 만들기 때문에 기본값으로 동일한 서버 이름이 사용됩니다.

참고 서버를 복구하고 기존 사이트를 조인하는 방법을 알려면 Microsoft Exchange Server 문서를 참조하십시오. 이 경우 새 서버나 복구된 서버에 Exchange Server를 설치하되 기존 조직으로 이를 복제하지는 마십시오. 대신 서버에 원래의 조직 및 사이트 이름을 부여하고 Setup /R을 실행합니다.

이제 마지막 Exchange 프로덕션 서버로부터 정보 저장소와 디렉터리를 복원할 수 있습니다. 원래 서버가 아직 사용 가능하다면 DSADATA 및 MDBDATA 디렉터리에 있는 모든 트랜잭션 로그를 저장합니다. 이렇게 하면 마지막 백업 이후로 데이터베이스에 적용된 트랜잭션을 통해 디렉터리 및 정보 저장소를 앞으로 재생할 수 있습니다. 이들 로그를 사용할 수 없으면 마지막 백업 당시의 데이터베이스 상태로만 복구할 수 있습니다.

예: 백업 테이프에서 서버 복구

다음은 프로덕션 서버에 있는 정보 저장소 및 디렉터리 서비스의 백업 테이프를 사용한 서버 복구의 예입니다. 정보 저장소와 디렉터리의 전체 온라인 백업의 경우 백업 유형은 일반으로 구분됩니다. 소프트웨어 설치 도중에 사이트를 조인하지 마십시오. 대신 Create New Site를 선택하십시오. 새 사이트를 만든다고 선택한 경우에도 다시 시작할 때 Exchange 디렉터리 데이터베이스의 테이프 백업은 사이트 식별자를 서버에 복원함으로써 사이트의 다른 서버와 자동으로 동기화되도록 만듭니다.

복이전 컴퓨터 준비

복이전 컴퓨터는 다음 사항을 만족해야 합니다.

• Windows NT가 설치되어 있어야 합니다.
• 손상된 Exchange 서버와 컴퓨터 이름이 같아야 합니다.
• 손상된 서버와 동일한 역할을 하도록 만듭니다. 즉, 그 서버가 BDC였으면 복구 서버를 BDC로서 프로덕션 도메인에 추가합니다. 이는 복이전 컴퓨터에 대한 새 SID를 만들기 위해 PDC에서 컴퓨터 이름을 삭제한 다음 다시 추가해야 함을 의미합니다.
• 프로덕션 서버와 동일한 Windows NT 서비스 팩이 설치되어 있어야 합니다.
• 백업 테이프로부터 전체 정보 저장소와 디렉터리를 복원할 수 있는 충분한 디스크 공간이 있어야 합니다.
• 프로덕션 서버에 설치된 테이프 드라이브와 호환되는 테이프 드라이브가 있어야 합니다.

복원을 빨리 수행하려면 Windows NT 설치 코드와 서비스 팩의 복사본을 복이전 컴퓨터 하드 디스크에 보관합니다. 프로토콜 주소, 파티션 정보, 프로토콜, 옵션, 튜닝 등을 포함한 적절한 설정이 기록되어 있는 프로덕션 Windows NT Server 구성 시트를 보관합니다.

복구 서버 준비 프로세스

1. Windows NT에 도메인 관리자로 로그온합니다.
2. Exchange Server 설치 프로그램을 실행합니다. Exchange Server 4.0을 사용하지 않는 경우 Setup /R을 사용하여 기존 Exchange 서버를 새 하드웨어로 복구할 수 있습니다.
3. 서버 이름이 원래 프로덕션 컴퓨터 이름과 같은지 확인합니다.
4. Create New Site를 선택합니다. Join Existing Site는 선택하지 마십시오.
5. 같은 조직 및 사이트 이름을 사용합니다.
6. 원래 프로덕션 서버에서 사용되었던 서비스 계정과 동일한 계정을 선택합니다.
7. 원래 프로덕션 서버에 설치되었던 커넥터와 동일한 커넥터를 설치합니다.
8. Exchange Performance Optimizer를 실행하여 프로덕션 서버에 사용되었던 구성과 동일한 구성으로 Exchange를 최적화합니다. 프로덕션 서버 구성 문서를 참조하십시오.
9. 마지막 백업을 수행했을 때 원래 프로덕션 서버에 설치되어 있던 Exchange 서비스 팩과 동일한 서비스 팩을 설치합니다. Exchange 서버 4.0을 사용하지 않는 경우 Update /R을 사용합니다.
10. Microsoft Mail(MS Mail) 커넥터가 원래 서버에 설치되어 있었던 경우 새 서버에서도 이와 동일하게 구성합니다. X.400 및 기타 다른 사이트 커넥터는 구성 정보를 Exchange 디렉터리에 저장하지만 MS Mail 커넥터는 그 디렉터리 및 Windows NT 레지스트리에 저장합니다. 이 레지스트리 항목을 다시 만들려면 Exchange 디렉터리를 복원하기 전에 MS Mail 커넥터를 구성해야 합니다. 원래 서버에 타사의 커넥터가 설치되어 있었던 경우에는 이러한 커넥터도 구성해야 합니다. 프로덕션 서버 문서를 참조하십시오.
11. 원래 서버에 키 관리 서버가 설치되어 있었다면 이를 새 서버에 설치합니다.
12. 복구 서버에 Exchange 클라이언트나 Outlook을 설치합니다.

아래의 절차에 따라 Exchange 데이터를 복원합니다.

복원 실행

사용 가능한 온라인 백업

이 프로세스에서는 사용자가 Exchange Server와 함께 제공된 Exchange에서 인식 가능한 NTBACKUP.EXE 프로그램을 사용하고 있다고 가정합니다. 다른 백업 프로그램을 사용하는 경우에는 해당 문서를 참조하십시오.

Exchange 서버의 온라인 백업을 가지고 있다면 다음 단계를 따르십시오.

1. 복원 테이프를 넣습니다.
2. 관리 도구 그룹에서 백업 아이콘을 누릅니다.
3. 테잎 아이콘을 두 번 누릅니다.
4. "테잎 전체 백업"을 두 번 누릅니다. 카탈로그 상태 화면 "카탈로그 상태-테잎에서 세트 목록 읽어들이는 중"가 나타납니다.
5. 오른쪽 창에서 디렉터리 및 정보 저장소를 선택합니다.
6. 백업 창 위쪽에 있는 복원 단추를 누릅니다. 복원 정보 대화 상자가 나타납니다.
7. 마지막 백업 후에 원래 프로덕션 서버가 변경되었고 서버의 트랜잭션 로그를 가지고 있으면, 이 단계 뒤의 절차는 생략하십시오.

   참고 공용 정보 저장소가 별도의 서버에 있는 경우에는 Microsoft 고객 지원 서비스에 문의하십시오. 다음 단계에서는 공용 저장소를 지울 것을 요구합니다. 공용 정보 저장소가 별도의 컴퓨터에 있으면 이를 수행하지 마십시오.

8. 복원 정보 화면에서 대상 서버의 이름을 입력합니다. 기존 데이터 모두 지우기를 선택합니다. 개인, 공용, 복원 이후에 서비스 시작 및 복원 후 확인 옵션이 모두 선택되어 있는지 확인합니다. 확인을 누릅니다.
9. 복원 정보 대화 상자에서 확인을 눌러 복원 상태 대화 상자를 표시합니다.
10. 복원이 끝나면 복원 상태 대화 상자에서 확인을 누릅니다.
11. 백업 프로그램을 닫습니다.

Exchange 디렉터리 서비스와 정보 저장소가 마지막 백업 상태로 복원됩니다.

마지막 백업 후에 원래의 프로덕션 서버가 변경되었고 서버의 트랜잭션 로그를 가지고 있는 경우 다음 단계를 따르십시오.

1. 새 서버에서 각 드라이브의 MDBDATA 및 DSADATA 디렉터리에 있는 모든 파일을 다른 위치로 옮깁니다.
2. 원래 서버의 DSADATA 및 MDBDATA 디렉터리에서 트랜잭션 로그 파일을 새 서버의 대응하는 로그 위치로 복사합니다. 로그 파일을 복사할 위치를 잘 모르면 다음 레지스트리 항목을 확인하십시오.

   디렉터리 서비스 로그 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\데이터베이스 로그 파일 경로

   정보 저장소 서비스 로그 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\ParametersSystem\DB 로그 경로

3. 백업 프로그램을 실행하여 디렉터리 서비스와 정보 저장소 데이터를 복원합니다. 위 절차의 1 - 6단계를 따릅니다.
4. Restore Information 화면에서 Erase All Existing Data는 선택하지 마십시오. Verify After Restore와 Start Services After Restore를 선택합니다. OK를 누릅니다. 디렉터리 서비스와 정보 저장소가 별도의 백업 작업을 통해 백업된 경우 둘 다 복원될 때까지는 서비스를 시작하지 마십시오. Erase All Existing Data를 선택하지 마십시오. 그렇지 않으면 원래 서버로부터 복사된 모든 트랜잭션 로그가 지워집니다.
5. Restore Information 대화 상자에서 OK를 눌러 Restore Status 대화 상자를 표시합니다.
6. 복원이 완료되면 Restore Status 대화 상자에서 OK를 누릅니다.
7. 백업 프로그램을 닫습니다.

사용 가능한 오프라인 백업

Exchange 디렉터리와 정보 저장소에 대한 오프라인 백업을 가지고 있다면 다음 단계를 따르십시오.

1. 모든 Exchange 서비스를 중지합니다.
2. 다음 레지스트리 위치에서 디렉터리 서비스와 정보 저장소 서비스에 대한 데이터베이스 및 로그의 위치를 확인합니다.

   디렉터리 서비스 로그 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\데이터베이스 로그 파일 경로

   디렉터리 서비스 데이터베이스 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeDS\Parameters\DSA 데이터베이스 파일

   정보 저장소 서비스 로그 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\DB 로그 경로

   개인 정보 저장소 데이터베이스 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPrivate\DB 경로

   공용 정보 저장소 데이터베이스 경로
   HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\ParametersPublic\DB 경로

3. DIR.EDB 파일(DSADATA 디렉터리에 있어야 함)을 디렉터리 서비스 데이터베이스 경로로 복사합니다.
4. 디렉터리 서비스 로그 파일을 디렉터리 서비스 로그 경로로 복사합니다.
5. PRIV.EDB 파일을 개인 정보 저장소 데이터베이스 경로로 복사합니다.
6. PUB.EDB 파일을 공용 정보 저장소 데이터베이스 경로로 복사합니다.
7. 정보 저장소 로그 파일을 정보 저장소 서비스 로그 경로로 복사합니다.
8. Exchange 디렉터리 서비스를 시작합니다.
9. 명령 프롬프트에서 EXCHSRVR\BIN 디렉터리로 이동하고 다음을 실행합니다.

   isinteg –patch

10. 정보 저장소 서비스를 시작합니다.

키 관리(KM) 서버 데이터 복원

키 관리 서버가 원래 서버에 설치되어 있었던 경우 다음 단계를 따라 키 관리 서버의 데이터를 새 컴퓨터로 복원합니다.

1. KM 서버 서비스가 설치되지 않았으면 이를 설치합니다.
2. KM 서버 서비스를 중지합니다.
3. KM 서버 데이터를 복원합니다.

   Exchange Server 4.0이나 5.0을 사용하는 경우 \SECURITY\MGRENT 디렉터리를 복원합니다.

   Exchange Server 5.5를 사용하는 경우 EXCHSRVR\KMSDATA 디렉터리를 복원합니다.

4. KM 서버 시동 디스크를 복원합니다.
5. KM 서버 서비스를 시작합니다.

Windows NT 계정 연결을 위한 사서함 검토

1. 사이트에서 Recipients 컨테이너를 선택합니다.
2. 아무 사용자나 두 번 누릅니다.
3. Primary Windows NT Account 필드를 보고 Windows NT 계정이 사서함과 일치하는지 확인합니다.
4. 여러 사용자에 대해 이 절차를 반복합니다.

클라이언트 워크스테이션에서 사용자 로그온 테스트

1. Exchange 클라이언트를 실행합니다.
2. 사용자 암호가 작동되는지 확인합니다.
3. 사용자 메일, 일정 등이 사용 가능한지 확인합니다.
4. 사용자가 같은 서버 뿐 아니라 다른 서버 및 다른 사이트의 사서함으로 메일을 보낼 수 있는지 확인합니다.
5. 여러 워크스테이션에서 이를 반복합니다.

Microsoft Exchange 사용자 정의 복원

프로덕션 서버 구성 시트의 정보를 사용하여 커넥터 및 그외 다른 서비스를 다시 만듭니다. Microsoft Windows NT 레지스트리에도 저장되어 있는 순환 로깅과 고급 진단 설정을 확인합니다.

하드웨어 플랫폼

대부분의 Exchange 데이터베이스는 하드웨어 플랫폼에 독립적입니다. Intel 서버에서 만든 PRIV.EDB, PUB.EDB 또는 DIR.EDB 파일을 Alpha 서버에서 사용할 수 있으며, 그 반대도 가능합니다. 그러나 디렉터리(DIR.EDB)에는 전자 메일 생성기와 추가 기능 등의 플랫폼 고유의 구성 요소에 대한 정보가 포함되어 있습니다. 이 정보는 Exchange 관리자 프로그램을 통해 <사이트>\Configuration\Add-ins 및 <사이트>\Configuration\Addressing\E-mail Addressing Generators에 들어 있습니다.

Exchange 5.0 및 이후 버전은 서버가 설치된 플랫폼에 상관없이 지원되는 모든 플랫폼에 대해 추가 기능과 전자 메일 생성기를 자동으로 설치합니다. 이로 인해 하드웨어 플랫폼 간의 이동이 편리해집니다. Exchange 4.0은 설치될 플랫폼에 대한 구성 요소만 설치하므로 Exchange 4.0을 실행하는 경우 다른 하드웨어 플랫폼에 새 서버를 설치하려면 추가 단계가 필요할 수도 있습니다. 도움이 필요하시면 Microsoft 고객 지원 서비스에 문의하십시오.

주요 정보 저장소 문서 및 참고 사항

참고 아래의 기술 자료는 기본 절차에 대해 간략하게 설명합니다. 상황에 따라 단계가 달라질 수도 있습니다. 정보 저장소 복구로 인해 데이터를 저장할 수도 있지만 잃어버릴 수도 있으며 Microsoft 고객 지원 서비스의 도움을 받는 것이 좋습니다. 이 서비스에서는 지속적으로 정보를 수집해서 정리해 놓기 때문에 사용자가 다른 방식을 사용하려 할 때 수고를 덜어줍니다. 최신 정보는 http://support.microsoft.com/support/를 참조하십시오.

Q147244, 제목: XADM: 정보 저장소를 시작할 때의 문제점 해결

수정일: 1998년 2월 3일

이 문서의 내용은 Microsoft Exchange Server 버전 4.0, 5.0 및 5.5에 적용됩니다.

요약

Exchange Server 4.0 정보 저장소는 손상되거나 시작되지 않을 수 있습니다. 이는 실행 중인 Exchange Server의 갑작스런 정전 또는 디스크에 정보를 잘못 기록한 고장난 하드웨어 등에 의해 발생할 수 있습니다. 이 문서에서는 복구 단계에 대해 개략적으로 설명합니다.

이 문서에 설명된 단계는 순환 로깅 설정이 해제되어 있고 정규 백업 절차를 제대로 수행하고 있는 경우 가장 성공적으로 적용됩니다. 순환 로깅이 설정(기본값)되어 있는 경우 1, 2 및 6-9 단계가 유효합니다. 트랜잭션 로그 파일에 포함된 데이터가 데이터베이스에 커밋된 후 순환 로깅이 트랜잭션 로그 파일에 자동으로 기록합니다. 백업을 사용할 수 없는 경우 1, 2, 8 및 9 단계가 유효합니다. 백업 및 복원 절차에 대한 정보와 전략에 대해서는 TechNet의 관련 문서나 Microsoft Exchange Server 문서를 참조하십시오.

추가 정보

최대한 많은 데이터를 보호하기 위해, 반드시 순서를 지켜 다음 단계를 수행하십시오.

1. .EDB, MSExchangeIS, MSExchangePriv 및 MSExchangePub 메시지에 대한 Windows NT 이벤트 뷰어 응용 프로그램 로그를 확인합니다. 이 오류 메시지는 정보 저장소 문제에 대해 명확한 이유를 제시하는 것일 수 있습니다. 가장 흔한 이유는 다음 두 가지입니다. 응용 프로그램 로그에 필요한 디스크 공간이 모자라므로 isinteg -patch를 실행해야 합니다.

   자세한 내용은 다음을 참조하십시오.

   Q128325, Title: XSRV IS: Reclaiming Disk Space for the Information Store

   Q149238, Title: XSRV IS: Information Store Fails to Start with -1011 Error

2. 모든 Exchange 서비스를 종료하고 Exchange 서버를 다시 부트합니다. 정보 저장소가 다시 시작되면 자동으로 데이터베이스를 일관된 상태로 복구하고 반환하려 시도합니다.
3. 정보 저장소의 전체 오프라인 백업을 수행합니다(모든 Exchange 서버가 중지됨). 이 백업에는 모든 .EDB 및 .LOG 파일이 포함되어야 합니다. 다른 물리 드라이브에 저장될 수도 있습니다. 이 파일들을 찾으려면 다음 하위 키 아래의 HKEY_LOCAL_MACHINE 하위 트리에서 레지스트리를 찾아보십시오.

   \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem

   DB 로그 경로 매개 변수도 찾아보십시오. 이는 계속 진행하기 전에 Exchange Server의 현재 상태를 파악하기 위한 예방 조치입니다. 8단계 또는 9단계에서 이를 수행합니다.

4. 마지막 전체 온라인 백업을 복원합니다. 복원 이후에 서비스 시작 확인란을 선택하지 마십시오. 그런 다음 정보 저장소에 대해 마지막 전체 온라인 백업부터 손상이 일어난 전날까지의 증분 온라인 백업을 복원합니다. 증분 백업이 복원되고 있을 때만 복원 이후에 서비스 시작 확인란을 선택합니다.

   기존 데이터를 모두 지우라는 확인란을 선택하면 안됩니다.

   정보 저장소가 시작되면 기존의 모든 데이터베이스 로그를 롤포워드하고 데이터를 복원된 정보 저장소에 놓습니다. 이렇게 하면 정보 저장소가 손상이 발생한 시점으로 돌아갑니다.

   이 작업이 끝났을 때 아직 손실된 데이터는 없습니다. 그러나 5단계부터 많은 양의 데이터가 손실됩니다.

5. 4단계에서 정보 저장소가 아직도 시작되지 않을 경우 이벤트 뷰어 응용 프로그램 로그로 가서 소스 .EDB에 대해 로깅된 메시지를 검토합니다. 4단계의 복원 도중 다시 재생되는 각 로그 파일마다 메시지가 하나씩 있을 것입니다. 이들 .EDB 메시지 중 하나가 특정 로그 파일을 다시 재생하는 문제가 있음을 보고하면 MDBDATA 디렉터리로 가서 손상된 로그 파일과 그보다 숫자가 큰 모든 로그 파일을 제거하고 나서 정보 저장소를 다시 시작해 보십시오. 예를 들어, 응용 프로그램 로그에서 EDB00012.LOG가 처리될 수 없거나 손상되었음을 보고하고 MDBDATA 디렉터리의 로그 파일이 EDB000001.LOG부터 EDB000025.LOG까지 있는 경우, EDB000012.LOG에서 EDB0000025.LOG까지의 파일을 제거하고 정보 저장소를 다시 시작해 보십시오. 정보 저장소가 다시 시작되면 사용자가 제거한 로그 파일에 저장되어 있던 데이터만 잃게 됩니다.
6. 5단계가 실패하면 정보 저장소의 마지막 전체 온라인 백업을 복원합니다. 복원 이후에 서비스 시작 및 Erase All Existing Data를 선택합니다. 이렇게 하면 정보 저장소가 마지막 온라인 백업 시점으로 복원됩니다. 이제 Exchange 관리자 프로그램에서 Server Object 등록 정보 페이지의 Advanced 탭에서 DS/IS consistency adjuster를 실행합니다.
7. 6단계가 실패하면 가장 최근의 전체 오프라인 백업이나 전체 온라인 백업으로 다시 시도합니다.
8. 6단계가 작동되지 않으면, 문제가 시작될 때(3단계) 모든 .EDB와 .LOG 파일을 MDBDATA 디렉터리로부터 삭제하고 데이터베이스 백업에서 PRIV.EDB 및 PUB.EDB의 복사본을 복원합니다. 그런 다음 Exchsrvr\bin 디렉터리로 가서 edbutil /d /r /ispriv를 실행한 후 edbutil /d /r /ispub를 실행합니다. Exchange 5.5에서는 ESEUTIL을 사용합니다. 이렇게 하면 개인 및 공용 정보 저장소를 조각 모음하고, 데이터베이스 오류가 있으면 이를 수정하려 시도합니다. EDBUTIL.EXE가 성공하면 정보 저장소를 다시 시작해 보십시오. 정보 저장소가 시작되면 개인 및 공용 정보 저장소 모두에 대해 isinteg -fix를 실행하여 EDBUTIL의 결과로 인해 발생했을 수 있는 불일치를 제거합니다. edbutil /d /r(또는 ESEUTIL)을 실행하면 데이터가 삭제될 수 있습니다. 이 방법은 마지막 수단으로만 사용해야 하며, 이 방법을 사용할 때는 Microsoft 고객 지원 서비스를 받으십시오.
9. EDBUTIL과 ISINTEG에 대한 자세한 정보는 Microsoft Exchange Server 문서를 참조하거나 기술 자료 Q143233, Title: XSRV Adm: Command Line Parameters for EDBUTIL.EXE를 참조하십시오.
10. 위의 단계가 모두 실패하면 마지막 수단으로 정보 저장소를 완전히 제거할 수 있습니다. 일반적으로 이를 수행해야 할 경우에는 먼저 공용 저장소를 제거해야 합니다. 두 가지를 모두 수행해 보면 이 프로세스가 왜 강력한지 그 이유를 알게 될 것입니다. PRIV.EDB를 완전히 제거하면 모든 사용자 메일 메시지와 폴더가 복구할 수 없게 삭제되며 PUB.EDB를 완전히 제거하면 모든 공용 폴더가 복구할 수 없게 삭제됩니다.

공용 정보 저장소를 완전히 제거하는 경우:

1. 3단계(전체 백업)를 완료했거나 Exchsrvr\Mdbdata 디렉터리를 하드 드라이브의 다른 위치로 복사했는지 확인하십시오.
2. Exchsrvr\Mdbdata 디렉터리에서 모든 EDB*.LOG 파일과 모든 RES*.LOG 파일, EDB.CHK 및 PUB.EDB를 삭제합니다.
3. 이제 정보 저장소 서비스를 다시 시작합니다. 정보 저장소가 시작되면 모든 공용 폴더 정보(새 PUB.EDB, RES*.LOG 및 EDB.CHK가 자동으로 만들어짐)와 로그 파일의 모든 정보가 손실된 것입니다. 그러나 개인 정보 저장소(PRIV.EDB)에 저장되었던 모든 사용자 메일 메시지와 폴더는 유지됩니다.

공용 정보 저장소를 완전히 제거하지 못한 경우:

1. Mdbdata 디렉터리의 모든 정보를 제거합니다.
2. 테이프 또는 대체 위치에서 PUB.EDB의 복사본을 가져옵니다.
3. 정보 저장소를 다시 시작해 봅니다. 정보 저장소가 시작되면 공용 폴더 정보는 그대로 남아 있지만 모든 사용자 메일 메시지, 폴더 및 로그 정보는 사라집니다. 다음 번에 사용자가 로그온할 때 사서함이 다시 만들어집니다.

위의 단계가 모두 실패하면 Exchsrvr\Mdbdata에서 모든 정보를 제거하고 정보 저장소 서비스를 다시 시작합니다. 그러면 설치 기본값으로 돌아가게 됩니다.

DS/IS 일관성 조정기(서버 개체의 Advanced 탭)를 사용하여 디렉터리 서비스/정보 저장소 불일치를 제거합니다.

시스템을 복구할 수 있으려면 Exchange Server 정보 저장소를 매일 백업하고 트랜잭션 로그를 가지고 있어야 합니다. 일일 백업 절차를 올바로 사용하고 테이프를 확인할 것을 강력히 권고합니다.

Q143235, 제목: XADM: 오류 메시지: Error - 550 Has Occurred

이 문서의 내용은 Microsoft Exchange Server 버전 4.0, 5.0 및 5.5에 적용됩니다.

증상

Exchange Server를 실행하는 컴퓨터가 응답을 하지 않거나 모든 서비스를 올바로 중지했는데도 제대로 종료되지 않으면 다음 오류 메시지가 화면과 이벤트 로그에 표시됩니다.

전원 오류가 생긴 경우 디렉터리나 정보 저장소 데이터베이스에 이 메시지가 나타납니다.

원인

이 오류는 보통 데이터베이스가 불일치 상태에 있거나 시작될 수 없음을 나타냅니다.

해결

데이터베이스가 불일치 상태에 있는지 확인한 후 소프트 복구를 시도합니다. EDBUTIL.EXE를 실행하기 전에 모든 서비스를 중지하고 모든 파일을 백업하십시오.

1. 데이터베이스 상태를 확인합니다.

   Exchange 4.0 및 5.0의 경우:

   문제가 있는 데이터베이스에서 MH 옵션과 함께 EDBUTIL.EXE를 사용하고 결과를 텍스트 파일로 덤프합니다.

   EDBUTIL /MH c:\exchsrvr\dsadata\dir.edb >c:\edbdump.txt
   또는
   EDBUTIL /MH c:\exchsrvr\mdbdata\priv.edb >c:\edbdump.txt
   또는
   EDBUTIL /MH c:\exchsrvr\mdbdata\pub.edb >c:\edbdump.txt

   Exchange 5.5의 경우:

   문제가 있는 데이터베이스에서 MH 옵션과 함께 ESEUTIL.EXE를 사용하고 결과를 텍스트 파일로 덤프합니다.

   ESEUTIL /MH c:\exchsrvr\dsadata\dir.edb >c:\edbdump.txt
   또는
   ESEUTIL /MH c:\exchsrvr\mdbdata\priv.edb >c:\edbdump.txt
   또는
   ESEUTIL /MH c:\exchsrvr\mdbdata\pub.edb >c:\edbdump.txt

2. EDBDUMP.TXT 파일을 편집하고 데이터베이스가 불일치 상태에 있는지 확인합니다.
3. 일치하지 않으면 다음 명령을 실행합니다.

   Exchange 4.0 및 5.0의 경우:

   EDBUTIL /R /DS

   Exchange 5.5의 경우:

   ESEUTIL /R /DS

   개인 또는 공용 정보 저장소를 복구하기 위해 /DS 대신 /ISPRIV 또는 /ISPUB을 사용합니다.

Q152959, 제목: XADM: 사이트의 첫 번째 Exchange Server를 제거하는 방법

최종 수정일: 1998년 2월 3일

이 문서의 내용은 Exchange Server 버전 4.0 및 5.0에 적용됩니다.

요약

이 문서에서는 사이트에 설치된 첫 번째 Exchange Server를 제거하기 위해 필요한 단계에 대해 개략적으로 설명합니다.

사서함 및 공용 폴더 뿐 아니라, 기본적으로 사이트의 첫 번째 서버에는 오프라인 주소록 폴더(.OAB), Schedule+ 약속 있음/없음 정보 폴더 및 관리 양식 폴더(있는 경우) 등의 사이트 폴더가 있으며 첫 번째 서버가 이들을 관리합니다. 다음으로 설치되는 서버들은 기본적으로 첫 번째 서버로부터 이 정보를 가져옵니다. 예를 들어, 사이트의 세 번째 서버가 .OAB를 생성하려면 첫 번째 서버에 연결되어야 합니다. 아래 설명된 단계를 수행하지 않고 사이트의 첫 번째 서버를 제거하면 사이트 폴더 데이터에 액세스하지 못하게 될 수 있습니다.

기본적으로 첫 번째 서버는 사이트의 게이트웨이 라우팅 테이블(GWART)을 업데이트해야 하는 라우팅 계산 서버이기도 합니다. 사이트에서 첫 번째 서버를 제거하기 전에 이 책임을 다시 할당해야 합니다. 이 작업에 대한 절차는 기술 자료 Q162012, Title: XADM: Unable to Change the Routing Calculation Server에서 설명합니다.

이 문서를 읽기 전에 사이트에서 첫 번째 서버를 제거한 경우 Q152960, Title: XADM: Rebuilding the Site Folders in a Site를 참조하십시오.

추가 정보

사이트의 첫 번째 Exchange Server를 제거하기 전에 다음 단계를 따라 문제가 발생하지 않도록 하십시오.

중요 이 Exchange Server를 홈으로 하는 사용자나 공용 폴더(비 사이트)는 데이터가 손실되지 않도록 다른 사이트 서버로 옮겨야 합니다. 자세한 내용은 Microsoft Exchange Server 문서를 참조하십시오.

오프라인 주소록

1. .OAB를 포함할 사이트의 서버를 선택합니다.
2. Exchange 관리자 프로그램을 사용하여 Configuration 컨테이너를 선택하고 디렉터리 저장소 Site Configuration 개체의 등록 정보를 엽니다.
3. Offline Address Book Server 드롭 다운 목록에서 1단계에서 선택한 서버를 선택합니다.
4. Generate Offline Address Book Now 단추를 누릅니다.
5. OK를 누릅니다.

Schedule+ 약속 있음/없음 정보와 관리 양식

1. 사이트에서 Schedule+ 정보와 관리 양식을 포함할 서버를 선택합니다.
2. Exchange 관리자 프로그램을 사용하여 Configuration 컨테이너, Servers 컨테이너 및 1단계에서 선택한 서버를 선택합니다.
3. Public Information Store 개체를 두 번 누릅니다.
4. Instances 탭을 누릅니다.
5. Public Folders 목록 상자에서 Schedule+ Free Busy Information 및 Organization Forms 폴더를 선택하고 Add를 누릅니다. 이들 폴더는 사이트의 첫 번째 서버 이름을 가져야 하며, 이 이름 앞에 대시가 옵니다(예: Schedule+ Free Busy Information - firstserver). 이 프로세스로 1단계에서 선택한 서버에 이들 폴더의 복제본이 만들어집니다.
6. OK를 누릅니다.

라우팅 계산 서버

1. 사이트에서 새 라우팅 계산 서버로 사용할 서버를 선택합니다.
2. Exchange 관리자 프로그램을 사용하여 Configuration 컨테이너를 선택하고 Site Addressing 개체를 두 번 누릅니다.
3. General 탭을 누릅니다.
4. 라우팅 계산 서버 드롭 다운 목록 상자에서 1단계에서 선택한 서버를 선택합니다. Apply 단추를 활성화하고 변경 내용을 유지하기 위해 등록 정보 페이지를 일부 변경해야 합니다.
5. Routing 탭을 누르고 Recalculate Routing 단추를 누릅니다.
6. OK를 누릅니다.

   참고 이 절차가 성공적임을 확인하기 위해, 이 단계가 끝나면 사이트의 첫 번째 서버의 전원을 꺼서 네트워크에서 잠시 분리하십시오. Exchange 클라이언트를 시작하고 다른 사용자의 Schedule+ 약속 있음/없음 정보를 액세스할 수 있고 오프라인 주소록을 생성할 수 있는지 확인함으로써 변경 사항이 작동되는 것을 확인한 다음, 첫 번째 서버를 네트워크에서 분리된 상태로 놓아 두거나 전원을 끈 다음 아래 단계를 수행하여 사이트에서 완전히 제거합니다.

7. Exchange 관리자 프로그램을 사용하여 Configuration 컨테이너를 선택한 다음 Servers 컨테이너를 선택합니다.
8. 사이트의 첫 번째 서버를 강조 표시합니다.
9. Edit 메뉴에서 Delete를 누르거나 키보드의 DELETE 키를 누릅니다.

   참고 Exchange Schedule+ 약속 있음/없음 커넥터가 다른 모든 항목을 새 서버로 옮긴 후에도 첫 번째 서버의 받는 사람 컨테이너에 나타나는 경우, Schedule+ 약속 있음/없음 커넥터는 자동으로 이동되는 것이 아니라 첫 번째 서버가 사이트에서 제거될 때 삭제될 것입니다. 이 개체를 다시 만들려면 Q148199, Title: Recreating a Deleted Schedule+ Free/Busy Agent에 열거된 단계를 따르십시오.

Schedule+ 약속 있음/없음 정보를 포함하는 방법

Schedule+ 약속 있음/없음 정보 사이트 폴더는 사용자가 Schedule+에 로그온하여 변경 사항을 생성할 때 다시 채워집니다. 이 기간 동안 일부 사용자의 약속 있음/없음 정보는 일시적으로 사용할 수 없게 됩니다. 사용자가 로그온하여 약속("약속 있음" 시간)을 만들 때까지는 확인할 약속 있음/없음 정보가 없습니다.

Q177635 XADM: DIR.EDB용 재난 복구 서버를 설치하는 방법

최종 수정일: 1998년 1월 27일

이 문서의 내용은 Microsoft Exchange Server 버전 4.0, 5.0 및 5.5에 적용됩니다.

요약

DIR.EDB 파일에 포함된 Exchange 디렉터리 서비스로부터 정보를 복구하기 위해 Microsoft Exchange Server 컴퓨터를 설정하는 방법에 대해 설명합니다.

추가 정보

DIR.EDB 파일은 Windows NT 컴퓨터 이름에 따라 만들어지므로 같은 컴퓨터 이름을 갖는 서버에만 복원될 수 있습니다.

참고 다음 단계를 따르면 오프라인으로 서버를 구성할 수 있습니다. 프로덕션 Exchange 환경에서는 사용할 수 없습니다.

DIR.EDB 복구 서버를 만드는 단계:

1. Exchange 서비스 계정이 상주하는 프로덕션 도메인에 프로덕션 Exchange Server 컴퓨터와 Windows NT Server 및 서비스 팩 수준이 동일한 백업 도메인 컨트롤러(BDC)로 컴퓨터를 설치합니다.
2. 복구 서버 컴퓨터에 충분한 디스크 공간과 테이프나 CD-ROM 드라이브 등의 필요한 장치가 있는지 확인합니다. 이 컴퓨터를 프로덕션 네트워크 허브에서 분리하여 오프라인으로 만듭니다.
3. 이 서버의 수준을 주 도메인 컨트롤러(PDC)로 올리고 컴퓨터를 다시 부트합니다.
4. 도메인 서버 관리자에서 Exchange Server 컴퓨터와 동일한 이름의 Windows NT 컴퓨터를 갖는 BDC를 추가하고 복구 서버를 원래의 Exchange Server 컴퓨터 이름으로 다시 지정합니다. 이 때 우선 프로덕션 네트워크에 있지 않음을 확인하십시오.

   자세한 내용은 기술 자료 Q150298, Title: Renaming a Windows NT PDC or BDC를 참조하십시오.

5. 서버를 다시 부트합니다. 이제 복구 서버는 프로덕션 Exchange Server 컴퓨터와 동일한 버전의 Windows NT Server를 실행합니다.
6. Exchange Server를 새 사이트로서 설치하되 프로덕션 Exchange 환경에서와 동일한 조직 및 사이트 이름을 사용합니다. 서비스에 대해 사용한 프로덕션 도메인과 동일한 서비스 계정을 선택하십시오.
7. 프로덕션 Exchange Server 컴퓨터와 동일한 서비스 팩 수준으로 업데이트합니다.
8. 이전 Exchange 디렉터리 저장소 및/또는 Exchange 정보 저장소의 백업으로부터 복원합니다.

Q163686, 제목: XADM: 서비스 계정이 삭제된 경우 필요한 작업

최종 수정일: 1997년 10월 28일

이 문서의 내용은 Microsoft Exchange Server 버전 4.0, 5.0 및 5.5에 적용됩니다.

요약

Exchange 서비스는 시작할 때 Microsoft Exchange 서비스 계정이라고 하는 Windows NT Server 도메인 계정을 필요로 합니다. 이 문서에서는 실수로 서비스 계정이 삭제되었을 때 수행해야 하는 작업에 대해 설명합니다.

추가 정보

기본적으로 서비스 계정은 설치 과정에서 Exchange 디렉터리의 모든 개체에 대한 권한을 갖습니다. 디렉터리의 Windows NT 계정은 이름이 아니라 SID 값으로 참조됩니다.

서비스 계정이 Windows NT 계정 데이터베이스로부터 삭제되면 Exchange 서비스를 시작할 수 없습니다. 서비스 계정을 동일한 이름과 암호로 다시 만들어도 이와 연관된 SID 값이 이전 계정의 값과 다르므로 서비스가 디렉터리 개체를 액세스할 수 없습니다.

해결

이 문제에 대해 권장되는 유일한 해결책은 최신 백업으로부터 Windows NT 보안 데이터베이스(SAM)를 복원하는 것입니다. 이 방법을 사용하면 원래의 SID 값을 갖는 삭제된 서비스 계정이 복원되며 모든 Exchange 서비스를 시작할 수 있게 됩니다.

SAM에 대한 백업을 사용할 수 없는 경우 다른 유일한 대안은 서비스 계정 손실로 인해 영향을 받은 모든 서버에 Exchange Server를 다시 설치하는 것입니다.

Exchange 정보 저장소(PRIV.EDB 및 PUB.EDB)의 정보를 저장할 수 있지만 디렉터리를 다시 만들어야 하는데, 이 경우 사용자 정의 받는 사람, 메일 그룹, 사서함의 자세한 내용, 커넥터 등의 모든 디렉터리 고유의 정보가 손실됩니다.

정식 복원

복원을 수행한 후 복원된 서버의 디렉터리 정보가 변경되거나 자동으로 제거되는 경우, 역으로 채우는 바람직하지 않은 상태가 발생할 수 있습니다. 다른 서버의 변경 기록이 복원된 데이터베이스의 변경 기록보다 더 최근의 정보이기 때문에, 이렇게 역으로 채우는 현상은 이미 복제된 복원된 서버의 변경 사항이 다른 서버로 다시 복제되고 있다는 것을 의미합니다.

정식 복원 도구(AUTHREST.EXE)를 사용하면 복원된 디렉터리 데이터베이스가 백업으로부터 복원된 다음 다른 서버로 강제로 복제되도록 할 수 있습니다. Microsoft 고객 지원 서비스를 통해 이 도구 사용에 대한 도움을 받을 수 있습니다.

일반적으로 복원된 데이터베이스는 조직의 다른 모든 디렉터리 복제본에 있는 집합 정보보다 오래된 것으로 간주됩니다. 복원을 통해 손실된 데이터나 서버가 복구되기 때문에, 복원된 디렉터리는 보통 자신의 정보를 다른 서버가 가지고 있는 더 새로운 데이터로 바꿉니다. 그러나 때로는 사용자가 이를 원하지 않을 수 있습니다. 예를 들어, 관리 오류로 수천개의 사서함이나 중요한 구성 정보를 삭제한 경우 백업으로부터 복원하는 목적은 한 서버의 기능을 복원하는 것이 아니라 전체 시스템을 바람직하지 않은 변경 이전의 상태로 되돌리는 것입니다.

정식 복원을 사용하지 않으면 오류 이전의 백업으로부터 조직의 모든 서버를 복원하거나, 사이트의 모든 서버를 복원한 다음 다른 사이트의 브리지헤드 서버를 처음부터 다시 동기화해야 합니다. 한 서버만 복원하거나 한번에 하나씩 서버들을 복원하는 경우 각각의 복원된 서버는 복원된 데이터를 사이트의 다른 모든 서버에 있는 더 새로운(정확하지 않은) 정보로 즉시 겹쳐씁니다.

정식 복원 도구를 사용하여 백업에 있는 데이터가 다른 서버에 있는 복사본보다 더 최근 데이터를 갖도록 해당 디렉터리에 있는 기록 가능한 모든 개체의 USN과 개체 버전을 높일 수 있습니다. 그런 다음 일반적인 복제를 통해 복원된 정보를 모든 서버로 전송하게 만듭니다. 이 도구를 사용하면 모든 서버가 아니라 실수하기 이전 가장 최근 백업을 갖는 하나의 서버만 복원할 수 있습니다.

AUTHREST.EXE는 Exchange Server CD-ROM의 "\Support\Utils\<플랫폼>" 디렉터리에 있습니다.

서비스 팩 복원

복원된 데이터베이스는 원래의 Exchange 버전과 동일한 버전에서 실행되어야 하므로 복원 후 모든 코드가 최신 코드로 바뀔 때까지는 서비스를 시작하지 마십시오. 예를 들어, Exchange 서비스 팩 2를 실행하고 있지만 원래의 서버 CD-ROM과 SP2 코드를 갖고 있는 경우 SP2가 설치된 서버에서 복원한 데이터베이스와 함께 Exchange를 실행하려면 그 전에 먼저 SP2 코드를 로드해야 합니다.

이를 수행하려면 원래의 서버 코드와 서비스 팩을 설치할 때 setup /r 및 update /r 스위치를 사용하면 됩니다. 이 스위치는 설치 프로그램에게 서비스를 시작하지 않도록 알립니다. /r 스위치는 복원에서 데이터베이스 파일을 제공할 것임을 나타냅니다. /r 스위치를 사용하지 않고 setup 및 update를 실행할 수도 있으며, 정확한 서비스 팩 수준을 사용하면 데이터베이스를 복원하여 setup에서 설치한 새로운 데이터베이스를 교체할 수 있습니다. 해당 복원 절차를 따르십시오. setup 및 /r이 모든 경우에 사용될 수 있는 것은 아닙니다.

• setup /r은 .DIR, .PUB 및 PRIV.EDB 파일을 만들지 않습니다. 보통 이 파일은 설치 과정에서 주어진 조직 및 사이트 이름으로부터 만들어집니다. setup /r은 Exchange Server CD-ROM에서 복사하는 방식과 마찬가지로 DIR.EDB를 복사합니다. setup /r을 실행한 후에는 이 기본 DIR.EDB와 함께 디렉터리 서비스를 시작할 수 없게 됩니다.
• 디렉터리 저장소가 아니라 정보 저장소만 복원하려는 경우에는 setup /r을 실행하지 마십시오. 이 경우에는 모든 데이터베이스 파일(.DIR, .PUB 및 PRIV.EDB)을 복원해야 합니다.
• Exchange Server 버전 4.0 서비스 팩의 경우 UPDATE.EXE 프로그램이 /r을 지원하지 않습니다. Exchange 4.0 서버에 대해 재난 복구를 수행하는 경우 SETUP.EXE를 실행할 때는 /r 옵션을 사용하지 마십시오. 설치 프로그램이 완료된 후 update(/r 옵션 없이)를 실행하여 원하는 서비스 팩을 설치하고 기본 데이터와 함께 Exchange 서비스를 시작합니다. 이제 백업으로부터 정보 저장소 및/또는 디렉터리 서비스 데이터를 복원합니다.

사서함 삭제 후 .OST로부터 복원

.OST는 서버 기반 폴더의 종속 복제본입니다. 마스터를 삭제하면 종속 복제본의 연결이 끊어지게 됩니다.

원래의 Exchange 프로필이 수정되지 않은 경우 이전의 .OST를 사용하면 오프라인으로 시작할 수 있으며 .PST 파일로 복사하여 데이터를 복구할 수 있어야 합니다. 그러나 이전의 프로필이 삭제되거나 수정된 경우(새 사서함에 로그온하기 위해 이를 사용한 경우) 데이터가 손실됩니다.

이는 .OST에서 사용된 보안 수행 방법에 의해 일어납니다. Windows NT 인증은 사용자가 오프라인 상태에 있는 동안에는 수행될 수 없습니다. 대신 사용자는 .OST 파일로부터 로컬 액세스 권한을 부여받으려면, 자신이 서버 기반 마스터에 로그온하도록 허용되었음을 증명해야 합니다. 이 절차를 수행하려면, 사용자가 서버에 로그온되어 있는 동안 Exchange는 사용자 사서함에 대한 고유 항목 ID를 사용하여 암호화된 쿠키를 만들고 사용자의 Exchange 프로필에 안전하게 저장합니다. 사실 OST 키는 프로필에 들어 있습니다. 사용자가 .OST 파일을 액세스하려고 시도하면 .OST는 프로필에 이 키가 있는지 확인합니다.

이는 마스터 서버 사서함이 삭제되고 .OST에 대한 키를 포함하는 프로필이 삭제되거나 수정된 경우 .OST 데이터를 복구할 수 없음을 의미합니다.

SCANPST.EXE를 사용하여 .PST 및 .OST 파일 복구

받은 편지함 복구 도구라고도 하는 SCANPST 프로그램은 .PST 및 .OST 파일을 모두 복구할 수 있습니다. SCANPST는 Microsoft Mail의 MMF 검사 기능과 유사하고 기본적으로 Exchange 클라이언트 하위 디렉터리에 설치되며, 선택한 파일에 대해 8가지 사항을 검사합니다. 복구하는 동안 복구하기 전에 기존 파일들을 백업하는 옵션이 있는데, 이 옵션을 사용하려면 .PST나 .OST 파일 크기와 동일한 사용 가능한 디스크 공간이 있어야 합니다.

그림 6 SCANPST 화면

보안 식별자(SID), 보안 개체 및 Windows NT 기반 컴퓨터 계정

그림 7 일반 생산 과정에서 Windows NT 보안 채널의 예

EXS1에 대한 Windows NT SID는 xyz입니다. 각각의 Windows NT 기반 컴퓨터는 도메인 인증에 사용되는 고유의 SID를 가집니다. xyz는 실제 SID 형식이 아닙니다. 도메인에 연결하기 위해 Windows NT BDC나 구성원 서버는 인증이 발생할 수 있도록 일치하는 SID 및 LSA(로컬 보안 기관) 암호를 가져야 합니다.

그림 8 보안 채널 오류

이 예는 복구 서버를 설치하기 전에 먼저 Exchange 기반 서버 컴퓨터 계정을 삭제했다가 다시 추가하지 않은 경우에 발생하는 상황을 보여줍니다. Windows NT를 처음부터 설치하여 복구 서버를 만들고 동일한 컴퓨터 이름을 사용하는 경우, 이전 컴퓨터 계정과 SID가 도메인 SAM에 남아 있고 컴퓨터 계정을 삭제했다가 다시 추가하여 Server Manager 프로그램 내부에서만 다시 설정할 수 있으므로 NETLOGON에서 오류가 발생하게 됩니다.

그림 9 새로 만든 컴퓨터 계정

이는 새로 만든 컴퓨터 계정에 대한 예입니다. 이전 컴퓨터 계정이 삭제되었다가 도메인 SAM에 다시 추가되면 먼저 SAM 항목이 초기 상태로 설정됩니다. 새 서버가 추가되면 LSA 보안 개체가 SID와 함께 만들어져서 해당 컴퓨터에 대해 LSA 보안 개체(BDC나 구성원 서버에 로컬로 저장됨)가 SAM 개체와 동기화됩니다. 이 과정에서 만들어진 암호는 BDC나 구성원 서버 컴퓨터가 도메인에 로그온할 때마다 사용됩니다. 이 과정에서 BDC나 구성원 서버 및 PDC 간의 보안 채널이 만들어집니다. NETLOGON은 암호가 노출되지 않도록 이 보안 채널 암호를 자동으로 변경합니다.

LSA 보안 개체는 초기 설치 도중이나 서버가 도메인에 조인할 때 설치 프로그램에 의해 만들어집니다. 그러나 SAM 컴퓨터 계정은 서버 관리자 프로그램에 의해 만들어집니다. 자세한 내용은 기술 자료 문서 Q102476, Title: Changing the Name of Windows NT Workstations and Servers를 참조하십시오.

일반 실습

일일 백업 만들기 및 확인

잘못된 백업으로는 데이터를 복구할 수 없기 때문에, 백업을 확인하는 작업은 중요한 재난 복구 단계이지만 많은 사용자들이 이를 수행하지 않는 경향이 있습니다. 백업 테이프가 스왑되고 있고 데이터가 올바르게 백업되고 있다고 속단하면 안됩니다. 매일 이 과정을 확인해야 합니다. 모든 백업 로그를 검토하고 오류나 불일치가 있으면 이를 해결하십시오. 레지스트리 뿐만 아니라 키 관리 서버의 데이터도 백업해야 합니다. 시스템을 복원하면서 유효한 데이터를 보존할 뿐 아니라 전체(일반) 백업이 성공적이면 트랜잭션 로그가 재설정되고 제거됨으로써 사용 가능한 디스크 공간이 늘어납니다. 일일 전체 백업이 실패하면 트랜잭션 로그가 제거되지 않으므로 트랜잭션 로그 디스크 드라이브가 금방 가득 차게 됩니다. 순환 로깅 기능이 설정된 경우에는 사용 가능한 디스크 공간을 늘리는 것이 그다지 중요한 문제는 아닙니다. 그러나 다른 방법을 통해 사용 가능한 디스크 공간을 늘려 순환 로깅이 사용되는 것을 방지할 수 있습니다.

백업을 확인하는 방법

1. 백업으로부터 Exchange 데이터베이스를 복원합니다.
2. Exchange 5.5를 실행하는 경우 데이터베이스 무결성 검사(ESEUTIL /G)를 실행합니다.
3. Exchange 4.0이나 5.0을 실행하는 경우 데이터베이스를 조각 모음(EDBUTIL /D)합니다.

정기적인 파일 기반 백업 수행

모든 구성 데이터를 캡처하려면 전체 파일 기반의 백업을 정기적으로 수행합니다. 모든 Exchange 관련 파일이 닫혀져 있고 백업될 수 있는지 확인하기 위해 서비스를 종료합니다. 예약된 관리 창에서 이 작업을 수행할 수도 있습니다. 정보 저장소와 디렉터리 데이터베이스에 대해서는 온라인 백업(파일 기반이 아님)이 권장됩니다.

복원을 수행하기 전에 기존 로그 파일 백업

Exchange Server를 복원하기 전에 안전을 위해 기존 로그 파일을 백업하는 것이 바람직합니다. 데이터가 손실되거나 기존의 백업 세트가 실수로 복원된 경우, 로그를 사용하면 복구하기가 수월해집니다.

다음 상황을 생각해 봅시다. 전체 온라인 백업을 일요일 밤과 월요일 밤에 수행하였습니다. 정보 저장소가 화요일에 실행되어 50개의 로그 파일이 만들어졌습니다. 문제가 발생하였고 백업으로부터 복원해야 합니다. 월요일 밤의 전체 온라인 백업을 복원하려 하였는데 실수로 일요일 밤의 백업을 복원하였습니다. 이제 데이터베이스를 일요일부터 복원해야 하지만 드라이브의 로그 파일은 화요일에 만들어졌으며 월요일 로그 파일들은 월요일 밤 백업할 때 제거되었으므로 더 이상 존재하지 않습니다. 서비스가 시작되면 데이터베이스 엔진은 로그 파일 시퀀스에 공백이 있다는 것(월요일 로그가 없음)을 발견하고 화요일의 로그 파일을 삭제(갭 이후의 모든 로그 파일)합니다. 왜냐하면 이 파일들을 다시 재생할 수 없으며 서비스는 이러한 시퀀스 번호를 갖는 로그를 만들어야 하기 때문입니다. 이러한 상황이 발생하면 화요일에 만든 데이터를 복구할 수 있는 유일한 기회를 잃게 됩니다.

복원을 수행하기 전에 기존 로그 파일을 백업해 두어야 이러한 상황이 일어나지 않게 방지할 수 있습니다. 따라서 반드시 복원 전에 기존 로그 파일을 백업해 두도록 하십시오.

테이프 백업 형식 표준화

복구 장비는 프로덕션 테이프 장비와 호환 가능해야 합니다. 새로운 종류의 테이프 드라이브를 설치할 때는 복구 장비와 호환 가능한 모델인지 확인하십시오. 새 장비를 사용하려면 항상 그 전에 테스트해야 하며 설치한 장비를 정기적으로 테스트해야 합니다.

UPS를 설치하고 정기적으로 테스트

Exchange 기반 서버의 전원이 꺼진 경우 다른 서버의 전원도 꺼지도록 방치하지 마십시오. 가능한 모든 장소에 UPS 보호 장비를 연결하고, 이미 설치되어 있다면 이 장비를 확인하십시오. 사이트의 일부 콘센트에만 UPS가 연결된 경우도 종종 있습니다. 전용 UPS가 없는 경우에는 전기 기사나 운영 요원에게 레이아웃을 테스트하도록 하십시오. 안전하다고 가정해 버리지 마십시오. 사용자가 모든 Exchange 데이터를 잃어버리고 나서 콘센트가 UPS로 보호되었다고 명시된 서류에 언제 누가 서명했는지는 중요하지가 않습니다. 서버 등급의 UPS 시스템 배터리의 수명은 3년 정도밖에 되지 않습니다. 항상 주의해서 관리하십시오.

정기적인 소방 훈련 실시

훈련을 통해 재난에서 복구하는 사용자의 능력을 측정하고 재난 복구 계획이 제대로 수립되어 있는지 확인합니다. 테스트 환경을 만들어 전체 복구를 간단히 시도해 봅니다. 프로덕션 백업의 데이터를 사용하고 복구하는데 걸린 시간을 기록해 두십시오. 이 정보는 실제 재난이 발생할 경우를 대비한 신뢰성 있고 정확한 계획을 세우는 데 도움이 됩니다. 정보를 수집하고 계획을 세우고 정확한 도구를 얻는 시간을 다 합해도 복구 시간에 드는 시간의 1/3밖에 되지 않는다는 것을 훈련을 통해 알게 됩니다.

효과를 극대화하기 위해, 훈련을 수행하고 있다는 것을 다른 직원들에게는 알리지 마십시오. 이러한 훈련은 재난 복구 계획에서 가장 소중한 경험이 될 것입니다.

프로덕션 서버를 배치할 환경 검토

서버를 구축할 장소를 관찰하여 충분한 전원이 있는지 확인합니다. 가능하면 Exchange 장비에 대해 전용 전원선을 확보합니다. 기존 암페어와 새 암페어 요구 사항을 검토합니다. 물리적으로 안전한 장소에 서버를 놓고 실내 온도가 허용 가능한 한계 내에 있는지 확인합니다. 사이트에 소방 스프링쿨러(가스를 사용하는 소방 장치가 아니라)가 있는 경우 서버를 그 아래에 두지 마십시오. 서버를 설치할 때 기본 예방 관리 조치를 취하십시오.

Windows NT 이벤트 로그를 매일 점검

로그를 정기적으로 점검합니다. 그래야 문제를 조기에 발견할 수 있으며 때로는 문제가 영향을 미치기 전에 발견할 수도 있습니다. Exchange에서 사용할 수 있는 확장 로깅과 Microsoft BackOffice 리소스 키트 로깅 도구를 이용하십시오.

재난 키트 만들기

운영 체제 구성 시트, 하드 드라이브 파티션 구성 시트, RAID 구성, 하드웨어 구성 시트, EISA/MCA 구성 디스크, Exchange 구성 시트, Windows NT 응급 복구 디스켓, Exchange Performance Optimizer 설정 시트 등을 포함하는 재난 키트를 만들어 미리 계획을 세워둡니다. 이러한 자료는 아주 쉽게 수집할 수 있으며 복구 시스템을 구성하는 데 필요한 정보나 디스크를 찾는 데 시간을 허비하지 않도록 해주기 때문에 복구 시간을 최소로 줄여줍니다.

Microsoft Exchange 유지 관리 창 게시

Exchange 기반 서버에 있어 점검과 유지 관리는 필수적입니다. 메인프레임의 정비 일정에는 신중을 기하면서 서버에 대한 정비는 소홀히 하는 경우가 종종 있습니다. 계획적인 유지 관리를 수행하면 예기치 않은 가동 중지 시간을 줄일 수 있습니다. 사용자에게 가동이 중지되는 시간을 알려주십시오. 사용자들은 일반적으로 365일 하루 24시간 내내 가용성을 기대합니다. 정기적인 유지 관리 외에도 하드웨어 소프트웨어에 대한 업그레이드와 서비스 팩을 설치해야 합니다. 때로는 EDBUTIL을 사용하여 저장소 파일 크기를 줄이기 위해 정보 저장소 서비스를 중지해야 할 수도 있습니다. 시스템이 중지될 때는 미리 사용자에게 알려주십시오.

가동 중지 시간 비용 결정

가동 중지 시간 비용을 예측해 두면 복구 장비 구입을 평가할 때 유용하게 사용됩니다. 이 비용을 계산하는 방식은 다양합니다. 이러한 비용에는 손실된 순서/시간, 금융 거래의 지연이나 민감한 시장 의사결정의 지연으로 인해 발생하는 비용 등이 포함됩니다.

사이트 외부의 테이프와 장비에 대한 유지 관리

법적, 보안 또는 비용 상의 이유로 백업 테이프를 타사의 사이트로 보내지 못하는 경우, 적어도 자사 내의 사이트 외부에 보관하십시오.

복구 장비의 전용 사용 및 복구 실습 구성

일부 하드웨어는 복구 전용으로 사용하십시오. 종종 사람들은 작은 문제에는 현명하게 대처하면서도 테스트나 복구 장비를 프로덕션에 갖다 놓는 등의 큰 문제에서 실수를 범합니다. 전용 복구 장비를 확보하여 작업 순서대로 관리하고 항상 사용 가능한 상태로 유지하십시오. 테스트 실습은 그 자체만으로도 유용할 뿐 아니라 복구 도중 그 진가가 드러납니다. 복구와 데이터베이스 조각 모음에 EDBUTIL을 사용하기 위해서는 가장 큰 프로덕션 서버 정보 저장소 데이터베이스보다 최대 두 배의 디스크 공간이 필요합니다. 일반적으로, 하나의 복구 서버에 충분한 디스크 공간을 확보하는 것이 비용면에서도 효율적입니다.

프로덕션 서버에 대한 모든 구성 기록을 완벽하게 보관

복구 서버를 구성하는데 이 정보가 필요합니다. Windows NT 튜닝 설정, 경로 정보, 프로토콜 주소, Exchange 커넥터 구성 등의 정확한 기록을 보관하여 재난 복구 키트의 일부로 만드십시오.

정보 저장소 모니터

서버 성능과 정보 저장소 증가를 모니터하고 확장 문제와 물류에 관한 계획을 세웁니다. Windows NT 디스크 공간 경고를 설정하고, 남은 디스크 공간을 모니터합니다. 성능 모니터의 정보 저장소에 대한 개체를 활용하십시오.

보관 계획 수립

보관 계획을 통해 사용자는 서버 기반 메시지를 로컬 저장소 파일로 옮길 수 있으며, 서버 기반 정보 저장소의 크기를 줄일 수 있습니다. 또한 사용자가 .PST를 로컬 드라이브나 디스크 또는 정보 저장소와는 별개의 서버에 보관하도록 지정합니다. 필요하면 파일 서버를 .PST 보관 전용으로 사용합니다. 그렇지 않으면 데이터가 저장소에서는 줄어들지만 동일한 디스크나 논리 드라이브의 다른 영역에 추가되는 경우가 생길 수 있습니다. .PST는 메시지를 .RTF와 ASCII 형식으로 보관하며 .PST 파일에 대한 디스크 공간 제한을 설정할 수 없기 때문에 파일 서버를 전용으로 사용하는 것이 반드시 필요할 수 있습니다. 사용자 .PST 파일을 포함한 중요한 모든 데이터를 백업 전략에 추가하십시오. .OST와 .PST 파일은 암호화를 통해 만듭니다.

Exchange 구성 고려 사항

Microsoft Exchange Server의 역할 고려

Exchange 서버가 PDC로 지정되어 서버를 사용할 수 없게 되면 다른 도메인 컨트롤러의 수준을 PDC로 올려야 합니다. Exchange 서버가 PDC가 아니면 복구 도중 도메인 컨트롤러의 수준을 올리거나 내리는 문제에 대해 걱정할 필요가 없습니다. Exchange 서버를 PDC로 지정하지 마십시오.

원격 사무실의 Windows NT 인증을 위해 또 다른 컴퓨터가 요구되지 않도록, 계정 도메인에서 Exchange Server를 BDC에 두려는 경우도 있습니다. 그러면 다른 컴퓨터를 구입할 필요가 없지만 이러한 구성을 선택할 때는 Windows NT SAM과 Exchange 서버 메모리 용으로 충분한 RAM을 확보해야 합니다. 보통 Windows NT Server 도메인 컨트롤러는 SAM에 사용되는 RAM의 2.5배를 필요로 합니다. 도메인 계획에 대한 설명은 TechNet의 Windows NT 4.0 Networking Guide를 참조하십시오.

Exchange 서버가 구성원 서버이고(PDC나 BDC가 아님) 도메인 SAM에 대한 추가 메모리 오버헤드가 없으면, 원격 사무실을 갖는 회사는 Exchange 서버가 인증(BDC 역할) 및 메시징 서비스를 제공하도록 함으로써 비용을 절약할 수 있습니다. 적절한 디렉터리 서비스 복원을 위해서는 원래의 SAM에 액세스할 수 있어야 합니다. BDC가 없는 도메인에 Exchange 서버를 설치하지 마십시오.

다른 방법은 각각의 계정 도메인을 트러스트하는 큰 리소스 도메인에 Exchange 서버를 두는 것입니다. 이 경우 Exchange 리소스 도메인에 대한 SAM이 상대적으로 작기 때문에 큰 메모리 오버헤드 없이 BDC에 Exchange 서버를 둘 수 있습니다.

트랜잭션 로그 파일을 별도의 전용 물리 디스크에 두기

이는 Exchange 서버 성능에 있어 가장 중요한 사항이며 복구에 있어서도 마찬가지입니다. 트랜잭션 로그가 별도의 전용 물리 디스크에 있는 경우 이 로그는 또 다른 복구 메커니즘의 역할을 합니다. 즉, 데이터베이스가 들어 있는 드라이브가 손실된 경우라도 트랜잭션 로그 파일을 사용하여 복구가 가능합니다.

보호 기능을 강화하기 위해 트랜잭션 로그 디스크용으로 별도의 디스크 컨트롤러를 사용하는 것이 좋습니다.

정보 저장소를 RAID5 스트라이프 세트나 미러된 세트에 두기

정보 저장소는 임의 액세스 방식을 사용하므로 스트라이프나 미러된 세트에 정보 저장소를 두면 성능이 크게 향상되고 복구 수준이 높아집니다.

SCSI 컨트롤러 쓰기 캐시 기능 해제

SCSI 컨트롤러 쓰기 캐시를 사용할 수 없게 설정하면 데이터 손실을 방지하는데 도움이 됩니다. 프로그래밍 수준에서 write-through 플래그가 설정되어 있으면 Windows NT는 버퍼를 사용하지 않습니다. 따라서 프로그램이 Windows NT로부터 쓰기 완료 신호를 받으면 디스크에 대한 쓰기가 확실하게 완료된 것입니다. 이는 Exchange 트랜잭션 로깅 프로세스에 있어 중요합니다. 쓰기 캐시를 사용 가능하게 설정한 경우 Windows NT는 디스크에 쓰기가 이루어졌다고 판단하여 호출한 응용 프로그램에게 이 "잘못된" 정보를 알려줍니다. 디스크에 대한 지연 쓰기 작업이 이루어지기 전에 문제가 발생하면 데이터가 손상될 수 있습니다.

예비용으로 백업된 SCSI 컨트롤러의 쓰기 캐시를 안전하게 사용할 수 있도록 설정할 수 있습니다. 자세한 설명은 하드웨어 공급업체에 문의하십시오.

운영 체제 파티션으로 미러링 또는 RAID5 사용

이 방법은 기초 운영 체제에 대한 중복성을 제공합니다.

가능한 경우 하드웨어 RAID 및 미러링 사용

고장이 발생한 다음 시스템을 원래 구성으로 되돌릴 때 새 드라이브를 추가하려면 소프트웨어 RAID를 다시 구성해야 합니다. 대체 드라이브에 꽂아 디스크 드라이브 고장을 즉시 수정할 수 있도록 가능한 한 하드웨어 RAID5를 사용하는 것이 좋습니다. 중복성을 위해, 시스템 파티션은 미러되거나 RAID5여야 합니다.

순환 로깅 기능 해제

순환 로깅은 디스크 공간을 절약하는데 도움이 되지만 중요한 결점을 가지고 있습니다. 증분 및 차등 백업을 불가능하게 하며 뒤로 재생할 수 없는 잘린 로그를 반복적으로 만들어냅니다. 사용 가능한 디스크 공간을 만들기 위해 트랜잭션 로그 파일이 정기적으로 제거되도록 하려면 순환 로깅을 요구하지 않는 안전한 백업 전략을 세워야 합니다.

정보 저장소의 특성을 초기에 제한

사서함 저장소 제한 및 서버 기반 메시지의 최대 사용 기간을 설정합니다. MTA 메시지 크기와 사용자가 보낼 수 있는 메시지 크기를 제한합니다. 이를 통해 사용자 기대치를 설정하고 서버 로드를 줄이는 것이 가능해집니다.

MTA 구성

대기열이 빠르게 비워지고 대기열에 있는 메시지가 정보 저장소에 쌓이지 않도록 MTA 빈도를 구성합니다. 끊어진 링크가 있어도 메시지가 계속 전달되도록 중복 MTA 경로를 만듭니다. MTA가 자신을 통과하는 트래픽을 처리할 수 있으면 저장소의 메시지가 줄어들고 메시지 배달 시간이 감소합니다.

정기적인 오프라인 정보 저장소 유지 관리

서버에서 많은 수의 사서함을 삭제 또는 이동하거나 사서함을 정리하여 많은 메시지가 삭제된 경우, 이를 정보 저장소에 대한 오프라인 조각 모음 기회로 활용하십시오.

정보 저장소의 유지 관리에서 서비스 팩 1이 설치된 Microsoft Exchange Server 버전 5.5를 사용하면, 서비스가 개인 또는 공용 데이터베이스에 사용 가능한 빈 공간이 있음을 나타내는 이벤트를 Windows NT 이벤트 로그에 기록합니다. 다음은 이러한 이벤트의 예입니다.

온라인 조각 모음이 종료된 후 데이터베이스에는 95MB의 사용 가능한 공간이 있습니다. 꼭 필요한 것은 아니지만 eseutil /g를 실행하여 Exchange 데이터베이스의 무결성을 정기적으로(예: 분기마다) 확인하는 것이 좋습니다. 그러면 데이터베이스를 평가하여 문제가 발생하기 전에 적합한 조치를 취하여 문제를 해결할 수 있습니다.

정기적인 유지 관리 일정에 따른 데이터베이스 복구 시에는 edbutil /d /r이나 eseutil /p를 실행하지 마십시오.

Exchange 5.5에서 16GB보다 큰 데이터베이스에 대한 계획 수립

Exchange Server 5.5에서 데이터베이스 크기에 대한 16GB 제한은 없어졌으며 이제 데이터베이스 크기는 하드웨어에 의해서만 제한됩니다. 따라서 여러 서버를 하나로 통합하여 하드웨어 및 관리 비용을 줄일 수 있게 되었습니다.

서버를 통합하는 경우, 데이터베이스 계획을 세울 때 재난 복구를 고려하십시오. 데이터베이스가 클수록 백업과 복원에 드는 시간이 많아지며 오프라인 유지 관리에도 시간이 많이 걸리게 됩니다.

Exchange Server 5.5에서는 큰 데이터베이스를 처리할 때 여러 가지 방식으로 성능을 개선할 수 있습니다. 이제 백업 API는 30GB/시간 이상의 속도를 지원하므로 백업 병목 현상이 발생한다면 이는 하드웨어 상의 문제일 것입니다. 데이터베이스 유틸리티도 개선되었습니다. 하드웨어와 컴퓨터 로드에 따라, 새로운 ESEUTIL 프로그램은 약 10GB/시간의 속도로 데이터베이스 무결성을 검사할 수 있으며, 약 4 - 5GB/시간의 속도로 데이터베이스를 조각 모음할 수 있고 8 - 10GB/시간의 속도로 이를 복구할 수 있습니다.

정보 저장소 데이터베이스에 대한 상한선을 계산할 때 복구될 때까지의 유지 관리, 백업 및 가동 중지 시간을 염두에 두십시오. 이 값이 커지면 작업 시간이 더 늘어납니다. 사서함 제한을 설정하고 서버당 사서함 수를 제어하고 메시지 크기 제한을 설정하고 정기적으로 사서함을 정리합니다.

삭제된 항목 보관 기능은 유용한 Exchange 5.5 기능이지만 삭제된 항목에서 사용한 공간은 사서함이 사용한 공간을 계산할 때는 포함되지 않음을 기억하십시오. 삭제된 항목 보관 기능을 사용 가능하도록 설정하면 Exchange 4.0과 5.0 서버에 비해 Exchange 5.5의 경우에는 정보 저장소 크기가 크게 늘어날 수 있습니다. 삭제된 항목이 정보 저장소에서 제거된 이후의 일수를 설정할 때는 주의해야 합니다.

서버에 충분한 디스크 공간 확보

오프라인 유지 관리 및 복구 루틴은 EDBUTIL/ESEUTIL 유틸리티로 관리되고 있는 데이터베이스 파일에 대해 최대 2배의 디스크 공간을 요구합니다.

그림 10 Microsoft Exchange 정보 및 로컬 저장소 데이터의 배포를 보여주는 구성 예제

최적화된 성능과 복구를 위해 운영 체제 드라이브는 미러링(또는 RAID5)되어야 하고, 트랜잭션 로그는 전용 물리 드라이브(이 드라이브도 미러링될 수 있음)에 있어야 하며, 정보 저장소는 RAID5 스트라이프 세트에 있어야 합니다. Windows NT에서는 시스템과 동일한 파티션에 있는 스왑 파일이 메모리를 덤프할 수 있을 정도로 커야 합니다. 다른 드라이브에 스왑 파일들을 추가하면 시스템은 이를 사용하여 디스크 성능을 최적화합니다.

백업 유형에 따른 전략

백업 전략은 주로 비즈니스 요구 사항에 따라 결정됩니다. 이 절에서는 다양한 유형의 백업, 이점, 제한 및 장단점에 대해 설명합니다.

백업에 필요한 시간

그림 11 백업에 필요한 시간은 백업 유형에 따라 다릅니다

백업에 필요한 시간은 어떤 유형의 백업이 수행되는지에 따라 다릅니다. 위 차트는 이러한 시간이 대부분 일일 전체 백업에 사용됨을 보여줍니다. 데이터베이스 크기가 작으면 그래도 수용할 수 있지만 데이터베이스가 GB 단위로 커지게 되면 일일 전체 백업은 실용적이지 못합니다. 어떤 경우에는 정기적인 전체 백업과 그 사이의 증분 또는 차등 백업을 결합해서 수행하는 것이 보다 현실적입니다.

백업으로부터 복구하는데 걸리는 시간

백업으로부터 복구하는데 걸리는 시간은 필요한 모든 백업 세트를 복원하는 시간과 트랜잭션 로그 파일을 앞으로 재생하는 시간에 따라 달라집니다. 백업 전략을 세우기 전에 정상 근무일 동안에 트랜잭션 로그 파일을 몇 개나 만들 것인지를 결정해야 합니다. 만들어진 로그 파일 수가 많으면 증분 또는 차등 백업을 수행할 경우, 백업을 복원해야 할 때 증분 또는 차등 백업 도중 백업되는 각 로그 파일은 다시 재생해야 한다는 점을 명심하십시오. 이 과정은 관련 로그 파일 수에 따라 몇 시간이 걸릴 수 있습니다.

예 A—전체 일일 백업

일정: 일:전체, 월:전체, 화:전체, 수:전체, 목:전체, 금:전체, 토:전체

예 B—전체 백업과 한 번의 증분 백업

일정: 일:전체, 월:증분, 화:전체, 수:증분, 목:전체, 금:증분, 토:전체

예 C—전체 백업과 두 번의 증분 백업

일정: 일:전체, 월:증분, 화:증분, 수:전체, 목:증분, 금:증분, 토:전체

예 D—전체 백업과 두 번의 차등 백업

일정: 일:전, 월:차등, 화:차등, 수:전체, 목:차등, 금:차등, 토:전체

백업 전략은 비즈니스 요구 사항에 맞아야 하지만, 작은 데이터 세트에 대해서는 전체 일일 백업을 사용하고 큰 데이터 세트에 대해서는 전체, 증분 및 차등 백업 방법을 결합하여 사용하는 것이 좋습니다. 여러 백업을 결합하여 사용함으로써 시스템 성능에 대한 영향과 필요한 테이프 공간을 최소화할 수 있습니다.

"예비용" 서버에 대한 질문

Exchange 복구를 위해 항상 예비용 서버가 실행되도록 유지하는 것이 가능한가요? 대답은 예비용 서버를 어떻게 정의하느냐에 따라 달라집니다.

전체 정보 저장소/디렉터리 서비스 서버 복구의 경우 복구 서버는 Exchange 서버와 동일한 컴퓨터 이름으로 구성되어야 하므로 온라인 상태로 유지될 수 없습니다. 왜냐하면 NetBIOS 이름이 중복될 수 없기 때문입니다. Windows NT Server 도메인 내에 같은 이름을 가진 컴퓨터도 존재할 수 없습니다. 다른 이름으로 복구 서버를 구성하면 Exchange 디렉터리를 복원하는 데 이 서버를 사용할 수 없지만, 개인 사서함은 쉽게 복원할 수 있습니다. 이 경우 모든 개체에 대해 Windows NT 보안을 다시 구성해야 합니다. 이는 수동으로 이루어지는 복잡한 작업일 수 있습니다. 최소한, 모든 필수 프로덕션 코드의 복사본을 가진 복구 장비를 준비해 두십시오.

단일 사서함 복구에는 Exchange 디렉터리 복원이 포함되지 않으며 Exchange에서는 복구 서버가 동일한 사이트 및 조직 이름(컴퓨터 이름은 달라도 됨)을 가질 것만을 요구하므로 Windows NT Server 기반 컴퓨터는 온라인으로 유지할 수 있습니다. 복구 서버가 한 사이트에서만 서비스되고 있는 경우에는 Exchange를 시작 및 실행할 수 있지만 프로덕션 사이트에는 연결할 수 없습니다.

전체 서버 복구에서는 사이트, 조직 및 컴퓨터 이름이 모두 동일해야 합니다. 복구 서버가 다른 컴퓨터 이름을 사용하여 추가 RAS 서버나 Microsoft Mail 다중 작업 메시지 전송 에이전트(MTA)로 서비스를 제공하는 등의 그다지 중요하지 않은 작업을 수행하도록 유지 관리할 수 있습니다. 전체 서버 복구를 위한 컴퓨터가 필요하면 Windows NT 이름을 바꾸거나 다시 설치합니다. 복구 서버에 설치 코드를 보관하고(\ntinstall\i386, \patches\sp4, \exchinst\i386) 프로덕션 서버와 동일한 용량을 갖고 있는지 확인합니다.

Exchange Server 5.5는 Microsoft Cluster Server를 지원하며 클러스터가 제공하는 높은 가용성을 활용할 수 있습니다.

온라인 백업 자동화 예

다음 단계에 따라 정보 저장소/디렉터리 서비스의 온라인 백업을 수행하십시오.

1. 로컬 컴퓨터의 Windows NT 디렉터리에 있는 Windows NT 리소스 키트를 사용하여 WINAT.EXE를 설치합니다.
2. Microsoft Exchange Backup이라고 하는 Windows NT 공통 그룹을 만듭니다.
3. BACKUP.LOG 파일에 대한 아이콘을 만듭니다. 이 아이콘으로 백업 로그를 빠르게 액세스하여 살펴볼 수 있습니다.
4. NTBACKUP.EXE 아이콘을 관리 도구 그룹에서 Microsoft Exchange Backup 그룹으로 복사합니다.
5. Microsoft Exchange Backup 그룹에 WINAT.EXE에 대한 아이콘을 만듭니다.
6. 제어판에서 서비스를 누르고 일정 서비스를 강조 표시한 다음 시작 단추를 누릅니다. 자동 시작이 되도록 구성하고 Windows NT 백업 운영자 그룹의 구성원인 하나의 ID를 할당합니다. 정확한 암호를 입력해야 합니다. 관리자 ID 암호가 변경되면 일정 서비스에 대한 암호도 변경해야 합니다. 이 계정은 또한 백업할 구성 컨테이너와 Exchange 조직 사이트 내에서 "Admin" 권한을 가져야 합니다. 완료되면 일정 서비스를 시작합니다.
7. 백업 배치 파일을 만들고 BACK.BAT이라는 이름으로 \winnt 하위 디렉터리에 저장합니다. 아래는 파일에 대한 예입니다.
8. WINAT.EXE 프로그램을 실행하고 BACK.BAT 파일의 일정을 잡습니다. 정의된 보안 컨텍스트 아래서 작업을 수행하기 위해 일정 서비스가 로그온하기 때문에, WINAT가 실행되고 있는 컴퓨터에 로그온 세션이 있을 필요는 없습니다. 대화형 모드에 대해 배치 작업을 설정하십시오.

온라인 백업을 위한 배치 파일 예제

rem ** 8/15/98 백업 작성자 <사용자 이름>
rem ** 이는 <서비스 이름1>과 <서비스 이름2> 모두에 대해 IS 및 DS를 백업합니다.
ntbackup backup DS \\SERVERNAME1 IS \\SERVERNAME1 /v /d "SERVERNAME1 IS-DS" /b /t Normal /l c:\winnt\backup.log /e
ntbackup backup DS \\SERVERNAME2 IS \\SERVERNAME2 /a /v /d "SERVERNAME2 IS-DS" /b /t Normal /l c:\winnt\backup.log /e
exit

오프라인 백업을 위한 배치 파일 예제: 예 1

실습 순서는 서비스 중지한 순서와 동일해야 할 수도 있습니다. 서로 종속 관계가 있으므로 종속 서비스를 중단하지 않고는 서비스를 중단할 수 없습니다.

rem ** Microsoft Exchange Services를 중지합니다.
rem ** Microsoft Exchange 서비스를 중지하고 자동으로 백업하도록 다시 시작할 수 있음
rem ** 특정 서비스가 사용중인 상태를 유지하는 파일임
REM // 모든 서비스를 중지함
echo Stopping Services...
net stop MSExchangeMSMI
net stop MSExchangePCMTA
net stop MSExchangeFB
net stop MSExchangeDX
net stop MSExchangeIMC
net stop MSExchangeMTA
net stop MSExchangeIS
net stop MSExchangeDS
net stop MSExchangeSA

ntbackup backup c:\ d:\ /a /v /d "Full File Based Backup" /b /l c:\winnt\backup.log /e

REM edbutil OPTIONS

net start MSExchangeSA
net start MSExchangeDS
net start MSExchangeIS
net start MSExchangeMTA
net start MSExchangeIMC
net start MSExchangeDX
net start MSExchangeFB
net start MSExchangePCMTA
net start MSExchangeMSMI

오프라인 백업을 위한 배치 파일 예제: 예 2

서비스 이름 양쪽에 따옴표를 표시하면 PCMTA 서비스를 시작하거나 중지할 수 있습니다. Windows NT 제어판의 Exchange 관리자 프로그램에서 서비스 이름을 결정하거나 Windows NT 레지스트리(HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services)를 조사하여 서비스 이름을 결정할 수 있습니다. 서비스는 알파벳 순서로 나열됩니다.

rem 배치 파일이 Microsoft Exchange 서비스를 중단 또는 다시 시작함
rem 파일 기반 백업용
echo Stopping Services ...
net stop MSExchangeMSMI
net stop MSExchangePCMTA
net stop MSExchangeFB
net stop MSExchangeDX
net stop MSExchangeMTA
net stop MSExchangeIMC
net stop MSExchangeIS
net stop MSExchangeDS

net stop "PC MTA - HUB"
net stop MSExchangeSA

ntbackup BACKUP d:\exchsrvr\mdbdata /v /d "File Based Backup" /b /l c:\winnt\backup.log /e

net start MSExchangeSA
net start MSExchangeDS
net start MSExchangeIS
net start MSExchangeMTA
net start MSExchangeIMC
net start MSExchangeDX
net start MSExchangeFB
net start MSExchangePCMTA
net start MSExchangeMSMI

net start "PC MTA - HUB"

WINAT 스케줄러 및 Windows NT 예약 서비스

그림 12 Windows AT 명령 스케줄러

NTBACKUP.EXE의 경우 BACK.BAT 작업은 대화형으로 설정해야 합니다.

WINAT 스케줄러 프로그램을 사용해서 일정을 잡은 작업은 Windows NT 예약 서비스에 의해 실행됩니다. 배치 작업은 예약 서비스의 컨텍스트로 실행되므로 Windows NT 보안을 고려해야 합니다. 예약 서비스를 구성할 때 계정을 Windows NT 백업 운영자 그룹의 구성원으로 지정합니다. 이렇게 하면 전체 정보 저장소/디렉터리 서비스 백업이 가능해집니다.

그림 13 Windows NT 예약 서비스 구성 대화 상자

최종 수정일:
Microsoft TechNet
1998년 9월
Volume 6, Issue 9

(0) (0)