Exchange의 오프라인 백업 및 복원 절차

기술 자료 번역 기술 자료 번역
기술 자료: 296788 - 이 문서가 적용되는 제품 보기.
이 문서는 이전에 다음 ID로 출판되었음: KR296788
모두 확대 | 모두 축소

이 페이지에서

요약

이 문서에서는 온라인 백업 API(응용 프로그램 인터페이스)를 사용하지 않고 Exchange 정보 저장소 데이터베이스를 수동으로 백업 및 복원하는 방법에 대해 설명합니다. 단일 Exchange 서버에 여러 개의 저장소 그룹이 있는 경우 각 저장소 그룹은 오프라인 백업과 복원을 위해 독립적이고 자체적인 장치로 간주되어야 합니다.오프라인 및 스냅샷 백업에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.
296787 XADM: Exchange Server 4.0, 5.0 및 5.5의 오프라인 백업 및 복원 절차

추가 정보

시작하기 전에

오프라인 백업을 수행하기 전에 다음 사항을 확인하십시오.
  • 저장소 그룹에 순환 로깅이 설정되어 있는지 여부를 확인합니다. 기본적으로 Exchange에서는 순환 로깅이 해제되어 있습니다. 순환 로깅이 설정되어 있는지 여부를 확인하려면 Exchange System Manager에서 storage_group 개체의 속성을 연 다음 일반 페이지를 봅니다. 순환 로깅을 해제하려면 Circular Logging 확인란의 선택을 취소합니다. 순환 로깅에 대한 변경 내용은 저장소 그룹에 있는 각 데이터베이스를 중지해야 적용됩니다.

    오프라인 백업을 수행하기 위해 순환 로깅을 해제할 필요는 없습니다. 그러나 트랜잭션 로그를 복원된 오프라인 백업에 재생하려면 순환 로깅을 해제해야 합니다.
  • Exchange 데이터베이스, 스트리밍, 트랜잭션 로그 및 검사점 파일의 경로 위치와 저장소 그룹의 로그 파일 접두사를 확인합니다.

    이 정보를 찾으려면 Exchange System Manager에서 storage_group 개체의 속성을 연 다음 일반 페이지를 봅니다. 다음 세 개의 상자에 있는 값을 기록합니다.
    • 로그 파일 접두사(E0n, 여기서 E0n은 E00, E01, E02, E03...)
    • 트랜잭션 로그 위치(E0n*.log)
    • 시스템 경로 위치(E0n.chk)
    데이터베이스 경로는 각 database_name 개체의 데이터베이스 속성에 표시됩니다. 저장소 그룹에 있는 각 데이터베이스에 대해 다음 두 개의 필드에 있는 값을 기록합니다.
    • Exchange 데이터베이스(.edb)
    • Exchange 스트리밍 데이터베이스(.stm)
Exchange System Manager를 사용할 수 없는 경우 ADSIEDIT 또는 LDIFDE와 같은 도구를 사용하여 Active Directory에서 원시 특성을 직접 읽어 위의 정보를 모두 확인할 수 있습니다. 다음 LDIFDE 명령을 사용하여 Active Directory 포리스트의 모든 Exchange 서버에 대한 정보를 출력할 수 있습니다.

참고: 이 명령에 대한 텍스트는 읽기 쉽도록 여러 줄로 표시했습니다.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=configuration_container_domain,DC=top_level_domain" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
다음은 위 명령의 출력 예입니다.
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Connecting to "dc1.child.test.com"
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries...

<중간 출력 생략>

.dn: CN=First Storage Group,CN=InformationStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Excha nge,CN=Services,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Public Information Store (EXCHANGE1),CN=First Storage Group,CN=Informati onStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Private Information Store (Exchange1),CN=First Storage Group,CN=Informat ionStore,CN=Exchange1,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Te st,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
트랜잭션 로그를 성공적으로 재생하려면 파일을 백업했던 경로 위치에 데이터베이스 파일(.edb 및 .stm)을 복원해야 합니다. 예를 들어, E:\Mdbdata 폴더의 데이터베이스 파일과 F:\Mdbdata 폴더의 스트리밍 데이터베이스 파일을 백업한 경우 파일을 E:\Mdbdata와 F:\Mdbdata에 각각 복원해야 합니다. 이 제한 사항은 단일 사서함을 복구하는 경우와 같이 완전히 다른 서버에 데이터베이스를 복원하려는 경우에도 적용됩니다.

최종 백업 후에 데이터베이스 경로를 변경하면 트랜잭션 로그를 부분적으로만 재생할 수 있으며 나머지 부분은 경로를 다시 원래 위치로 변경해야만 재생할 수 있습니다. 이전 경로로 되돌린 경우 경로를 변경한 지점까지 로그를 재생할 수 있습니다.

트랜잭션 로그 파일(E0n*.log)을 원래 백업 위치와 다른 경로에 복원할 수 있습니다. 트랜잭션 로그는 해당 트랜잭션 로그가 연결된 데이터베이스의 위치를 기록하지만 데이터베이스는 트랜잭션 로그의 위치를 기록하지 않기 때문입니다. 재생하는 동안 로그는 트랜잭션 로그 헤더에 저장된 경로 정보를 사용하여 데이터베이스를 "찾습니다". 온라인 백업 API는 데이터베이스 경로 변경을 내부적으로 보완하므로 이 제한 사항이 적용되지 않습니다.

검사점 파일(E0n.chk)은 백업이나 복원 대상은 아니지만 복구하는 동안 검사점 파일을 검사하거나 삭제해야 하기 때문에 검사점 파일의 현재 위치를 알고 있어야 합니다.

Exchange 데이터베이스 파일의 상호 연결 방법

.edb 및 .stm 파일은 모든 데이터베이스 정보의 최종 리포지토리입니다. 대개의 경우 이 두 파일을 단일 파일로 취급하며 동시에 백업하고 복원합니다. 이 파일은 서로 동기화 상태를 유지해야 하며 서로 다른 날짜에 백업한 .edb 파일과 스트리밍 파일은 일치할 수 없습니다.

Exchange 2000 또는 Exchange 2003 서버는 최대 4개의 저장소 그룹을 지원할 수 있으며 각 저장소 그룹은 최대 5개의 데이터베이스를 지원할 수 있습니다. 저장소 그룹은 트랜잭션 로그 파일의 공통 집합을 공유하는 데이터베이스 집합입니다. Microsoft Exchange Server 5.5는 최대 하나의 저장소 그룹만 지원할 수 있으며 저장소 그룹은 최대 두 개의 데이터베이스, 즉 개인 정보 저장소와 공용 정보 저장소를 지원합니다.

데이터베이스를 변경하면 변경 내용은 먼저 현재 트랜잭션 로그 파일에 기록된 후 메모리 내 캐시에 기록됩니다. 캐시에 변경 내용이 있으면 해당 변경 내용이 즉시 사용자에게 표시됩니다. 캐시에 있는 페이지는 편리한 시간에 데이터베이스에 플러시됩니다. 모든 트랜잭션이 실제로 데이터베이스 파일에 플러시될 때까지 검사점은 로그 파일 시퀀스에 위치를 표시합니다. 검사점이 최신 로그 파일보다 세 개 이상의 로그 파일만큼 뒤에 있는 것은 정상입니다.

각 저장소 그룹에 속해 있는 로그 파일을 혼동하지 않기 위해 특정 저장소 그룹에 속하는 Exchange 로그 파일 이름의 처음 3자에는 고유한 로그 접두사가 사용됩니다. Exchange 2000 또는 Exchange 2003 서버에서 지원되는 네 개의 저장소 그룹에 사용할 수 있는 로그 접두사는 E00, E01, E02 및 E03입니다. 이 문서에서는 저장소 그룹의 로그 접두사를 E0n으로 나타냅니다. 저장소 그룹의 현재 로그 파일은 항상 E0n.log입니다.

트랜잭션 로그의 크기는 항상 5MB입니다. 현재 로그 파일이 가득 차면 로그 생성 번호인 16진수 시퀀스 번호를 사용하여 다른 이름이 지정된 새로운 현재 로그 파일이 생성됩니다. 로그 파일은 E0n00001.log, E0n00002.log 등으로 번호가 지정됩니다. 이 문서에서는 번호가 지정된 로그 파일은 E0nxxxxx.log로 나타냅니다.

데이터베이스가 비정상적으로 중지되면 검사점 파일(E0n.chk)은 복원을 재생해야 하는 부분부터 트랜잭션 로그를 기록하여 일관성 있게 데이터베이스를 복원할 수 있습니다. 이 프로세스를 "소프트 복구"라고 합니다. 소프트 복구는 온라인 백업의 복원 후에 로그 파일을 재생하는 프로세스인 "하드 복구"와 대조됩니다. 소프트 복구와 하드 복구 사이의 가장 중요한 차이점은 하드 복구의 경우 복구하는 동안 로그 파일 재생 프로세스에 패치 파일 데이터를 삽입한다는 점입니다.

일관성이 없는 Exchange 데이터베이스 파일은 처리되지 않은 모든 트랜잭션이 아직 기록되지 않은 파일입니다. 일반적인 작업을 수행할 때 캐시에는 아직 파일에 실제로 기록되지 않은 정보가 있기 때문에 Exchange 데이터베이스 파일이 일관성이 없게 됩니다. 일반적으로 Exchange 데이터베이스 파일은 데이터베이스 서비스를 정상적으로 종료한 후에만 일관성이 있는 것으로 간주할 수 있습니다. 그러나 트랜잭션 로그와 데이터베이스 파일에 있는 정보 모두를 포함하는 의미의 데이터베이스는 필요한 로그 파일을 미리 삭제하지 않는 한 항상 일관성이 있는 것으로 간주됩니다.

Exchange 데이터베이스 오프라인 백업

Exchange 데이터베이스를 오프라인으로 백업하려면
  1. 백업할 데이터베이스를 분리합니다. 저장소 그룹에 있는 모든 데이터베이스를 분리할 필요는 없고 백업할 데이터베이스만 분리하면 됩니다.
  2. 데이터베이스 파일(.edb 및 .stm 파일 모두)이 일관성이 있으며 서로 일치하는지 확인합니다. 이렇게 하려면 각 파일에 대해 다음 명령을 실행합니다.
    eseutil /mh database file | find /i "DB Signature"
    참고: Exchange 2000 서비스 팩 2 이상에서는 데이터베이스 상태를 "Consistent"나 "Inconsistent"가 아니라 "Clean Shutdown"이나 "Dirty Shutdown"으로 보고합니다. "Clean Shutdown"은 "Consistent"와 동일한 의미이며 "Dirty Shutdown"은 "Inconsistent"와 동일한 의미입니다. Exchange 2000 서비스 팩 2 이상인 경우 이 추가 명령을 실행하여 각 데이터베이스의 상태를 확인하십시오.
    eseutil /mh database_name | find /i "Shutdown"
    다음은 위 명령의 출력 예입니다.
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    앞의 예에서는 DB 서명이 같습니다. 이는 edb 파일과 .stm 파일이 동일한 집합에 속한다는 것을 의미합니다. 두 서명 줄의 문자가 완전하게 일치해야 서명이 일치하는 것으로 간주됩니다.

    DB 서명이 일치해야 할 뿐 아니라 파일 역시 서로 동기화되고 일치해야 합니다. 각 파일에 대해 다음 명령을 실행합니다.
    eseutil /mh database file | find /i "consistent"
    다음은 위 명령의 출력 예입니다.
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    앞의 예에서 두 파일은 모두 "State: Consistent"를 보고합니다. 각 파일의 괄호 안에 있는 16진수(0x2CC7,1F14,1F7)도 일치해야 합니다. Last Consistent 타임 스탬프는 일치하지 않아도 됩니다. 이 파일은 모두 일관성이 있으며 서로 일치합니다.

    둘 중 한 파일에서 "State: Inconsistent"를 보고하거나 Last Consistent 로그 위치가 동기화되어 있지 않으면 데이터베이스가 정상적으로 분리된 것이 아닙니다. 이 경우 데이터베이스를 탑재했다가 다시 분리합니다. 파일이 정확하게 일치하지 않거나 일관성이 없을 경우 Microsoft 고객기술지원부(PSS)에 문의하여 도움을 받으십시오.
  3. 각 .edb 데이터베이스 파일과 해당 .stm 스트리밍 데이터베이스 파일을 백업 위치에 복사합니다.
  4. 백업한 데이터베이스를 탑재합니다.
  5. 순환 로깅이 설정되어 있는 경우 이 단계를 건너뜁니다. 순환 로깅이 해제되어 있고 나중에 "롤 포워드"하려면 번호가 지정된 모든 트랜잭션 로그 파일(E0nxxxxx.log 파일)을 백업해야 합니다. E0n.log, Res1.log 및 Res2.log 파일은 백업하지 마십시오.

    로그 파일의 이름이 E0n.log에서 E0nxxxxx.log로 바뀐 후에는 Exchange에서 해당 파일을 다시 변경하지 않으므로 번호가 지정된 로그 파일은 만들어진 직후를 포함하여 편리할 때 언제든지 백업할 수 있습니다. 그러나 백업한 로그 파일은 6단계의 지침에 따라서만 제거하십시오.

    로그 파일 백업은 데이터베이스 백업과 일대일로 대응하지 않습니다. 각 로그 파일 백업은 여러 개의 다른 데이터베이스 백업에 대해 재생할 수 있는 로그 파일의 체인에서 하나의 링크에 해당합니다. 데이터베이스 헤더의 "Last Consistent" 줄에 나열된 로그에서 시작하여 로그가 연속적으로 연결되어 있는 경우 특정 데이터베이스 백업에서 롤 포워드할 수 있습니다. 이 문서에서는 일관성 있는 마지막 로그를 "낮은 앵커 로그"라고 합니다.

    앞의 예에서 일관성 있는 마지막 항목은 (0x2CC7,1F14,1F7)입니다. 세 개의 숫자는 각각 로그 파일, 해당 로그 파일의 페이지 및 해당 페이지의 바이트 오프셋을 나타냅니다. 각 로그 파일에는 크기가 각각 512바이트인 페이지가 약 10,000개씩 포함되어 있습니다. 페이지 오프셋은 로그 파일이 채워진 비율을 알려 주지만 복구와 관련은 없습니다. 앞의 예에서 0x1F14는 십진수 7956에 해당하므로 해당 로그 파일은 약 80%가 채워져 있는 것입니다. 복구는 항상 로그 파일의 맨 처음부터 시작합니다.

    이 예에서 낮은 앵커 로그 파일은 E0n02cc7.log입니다.

    일관성 있는 마지막 로그의 이름이 여전히 E0n.log일 수 있으므로 디스크상의 일관성 있는 마지막 로그는 번호가 지정된 로그로 나타나지 않을 수도 있습니다. 즉, 시퀀스 번호 E0n.log는 데이터베이스가 중지되어 있는 동안 로그 파일 헤더를 검사하면 제공됩니다. 데이터베이스가 실행되고 있을 때는 E0n.log 헤더에 대한 액세스가 거부됩니다.

    내부 로그 생성 번호를 보려면 다음 명령을 실행합니다.
    eseutil /ml [log file] | find /i "lGeneration"
    다음은 위 명령의 출력 예입니다.
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    대개의 경우 각 데이터베이스 백업이 양호한지 확인하는 것보다 로그 파일 백업이 양호한지 확인하는 것이 더욱 중요합니다. 각 데이터베이스 백업은 서로 중복될 수 있지만 데이터베이스 백업의 전체 복구는 해당 백업 후에 생성된 로그 파일이 모두 있어야만 가능하기 때문입니다.
  6. 순환 로깅이 설정되어 있는 경우에는 이 단계를 건너뜁니다. 검사점 파일의 헤더를 검사하여 안전하게 제거할 수 있는 가장 높은 번호의 로그 파일을 확인합니다. 검사점은 데이터베이스가 비정상적으로 중지된 경우 자동 복구에 필요한 가장 낮은 번호의 로그 파일을 추적합니다. 검사점 파일을 검사하려면 다음 명령을 실행합니다.
    eseutil /mk E0n.chk
    다음은 위 명령의 출력 예입니다.
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    세 번째 줄인 Checkpoint 줄에는 관련 정보가 포함되어 있습니다. LastFullBackupCheckpoint 항목은 온라인 백업에서 사용되며 데이터베이스에 대해 온라인 백업이 수행되지 않은 경우 모두 0으로 남아 있습니다. 검사점 로그 위치 형식은 데이터베이스 헤더의 일관성 있는 마지막 항목과 같습니다. 이 예에서 검사점은 E0002cc7.log에 있습니다.

    순환 로깅이 해제되어 있는 경우 로그 파일은 수동으로 삭제되거나 온라인 백업 과정에서 자동으로 제거될 때까지 계속 축적됩니다. 순환 로깅이 설정되어 있으면 검사점이 로그 파일을 통과한 후 데이터베이스 서비스에 의해 기존 로그 파일이 자동으로 삭제되므로 기존 로그 파일을 특별히 관리할 필요가 없습니다.

    번호가 지정된 로그 파일을 모두 백업한 후에는 검사점 로그는 제외하고 검사점 로그까지 번호가 지정된 모든 로그 파일을 제거하여 디스크 공간을 다시 사용할 수 있습니다.

    중요: 검사점 로그는 제거하지 마십시오.

    이 예에서는 E0002cc6.log까지의 모든 로그를 제거할 수 있습니다.
  7. 이 단계는 선택적입니다. Esefile 유틸리티를 사용하여 복사한 데이터베이스의 페이지 수준 무결성을 확인할 수 있습니다.

    Esefile.exe 파일은 Exchange Server 5.5 서비스 팩 3 CD-ROM, Exchange 2000 Server 설치 CD-ROM 또는 Exchange Server 2003 설치 CD-ROM의 Support 폴더에 있습니다. Microsoft PSS에서도 Esefile.exe 파일을 구할 수 있습니다. Esefile 유틸리티는 Exchange Server 5.0 및 5.5, Exchange 2000, Exchange 2003의 .edb 파일에 사용할 수 있습니다.

    현재 온라인 백업 이외의 방법으로는 .stm 파일의 각 페이지에 대한 체크섬을 확인할 수 없습니다. .stm 파일에는 원시 데이터가 포함되어 있습니다. 해당 데이터를 구성하는 모든 인덱스와 포인터는 .edb 파일에 있습니다. .stm 파일에 문제가 발생하면 일부 특정 클라이언트 데이터가 손실되지만 데이터베이스 전체의 구조적 또는 논리적 무결성은 손상되지 않습니다.

    Exchange 데이터베이스에 대한 페이지 체크섬을 확인하려면 다음 Esefile 유틸리티 명령을 실행합니다.
    esefile /s database_name
    다음은 위 명령의 출력 예입니다.
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    초기화되지 않은 페이지는 허용되지만 문제가 없는 데이터베이스에서 불량 체크섬(bad checksums)은 0, 잘못된 페이지 수(wrong page numbers)는 0입니다.

    데이터베이스가 Esefile 유틸리티 무결성 검사를 통과하지 못하는 경우 최선의 선택은 양호한 이전 백업을 복원하고 데이터베이스를 롤 포워드하는 것입니다. 해당 백업이 없는 경우 PSS에 문의하여 데이터베이스 복구 또는 구제에 관한 조언을 받으십시오.
  8. 이 단계는 선택적입니다. 다음 명령을 사용하여 백업한 로그 파일의 무결성을 확인할 수 있습니다.
    eseutil /ml E0n
    다음은 위 명령의 출력 예입니다.
    k:\backups>eseutil /ml E00
    							
    이 명령은 백업한 로그 파일이 들어 있는 폴더에서 실행해야 합니다. 현재 실행 중인 로그 폴더에 대해 이 명령을 실행할 수도 있지만 Eseutil이 저장소 그룹에 있는 데이터베이스가 실행되는 동안 E0n.log의 헤더를 읽으려고 하면 -1032 오류(JET_errFileAccessDenied)가 나타납니다.

    이 명령은 로그 파일의 손상된 내용이 있는지 검색하고, 시퀀스 중간에 로그 파일이 없거나 로그 파일 간에 서명이 일치하지 않으면 경고도 표시합니다.

Exchange 데이터베이스의 오프라인 백업 복원

이 절에서는 오프라인 백업을 복원하는 두 가지 방법에 대해 설명합니다.
  • "지정 시간" 복원. 로그 파일이 데이터베이스로 재생되지 않습니다. 백업 후 생성된 모든 데이터는 손실됩니다.
  • "롤 포워드" 복원. 백업 후 생성된 로그 파일이 데이터베이스로 재생됩니다. 모든 로그 파일을 사용할 수 있는 경우 백업 후 생성된 모든 데이터를 보존할 수 있습니다. 순환 로깅이 설정되어 있으면 오프라인 백업의 "지정 시간" 복원을 수행해야 합니다. "롤 포워드" 복원은 선택할 수 없습니다.
복원하는 파일 집합은 다음과 같은 최소 기준을 만족해야 합니다.
  • 지정 시간 복원의 경우 저장소 그룹에 있는 중지된 데이터베이스가 모두 일관성이 있고 유효한 검사점 파일이 있어야 합니다. 현재 검사점 파일이나 기존 로그 파일은 삭제하지 마십시오.
  • 롤 포워드 복원의 경우 저장소 그룹에 있는 모든 데이터베이스가 중지되어 있고 일관성이 있어야 하며 현재 E0n.log를 포함하여 백업 후에 생성된 모든 로그 파일이 있어야 합니다. 검사점 파일은 삭제해야 합니다.
파일 집합이 앞의 조건을 만족하지 않는 경우에도 복원과 재생이 성공할 수 있지만 소프트 복구 과정에서 -1216 오류 메시지(JET_errAttachedDatabaseMismatch)가 나타날 수 있습니다.

-1216 오류 처리

Exchange 2000 이상의 추가 소프트 복구 안전 장치에서는 수동으로 변조된 데이터 파일이 발견되었는데 현재 데이터 집합으로 복구를 실행할 경우 기존 데이터가 손실될 것으로 판단되면 -1216 오류를 발생시킵니다.

이전 버전의 Exchange에서는 파일 집합이 불완전하지만 성공적인 재생에는 적합한 경우 관리자에게 더 이상 경고가 표시되지 않고 소프트 복구가 시작됩니다. Exchange 2000 이상에서 관리자는 Eseutil을 사용하여 -1216 오류를 명시적으로 무시해야 합니다.

오프라인 백업의 지정 시간 복원

오프라인 백업의 지정 시간 복원을 수행하려면
  1. 복원할 데이터베이스가 현재 탑재되어 있는 경우 분리합니다. 저장소 그룹에 있는 다른 데이터베이스가 분리되어 있는 경우 이 데이터베이스의 데이터베이스와 스트리밍 파일(.edb 및 .stm)은 각각 일관성이 있고 일치해야 합니다. 일관성과 일치 여부를 확인하려면 이 문서의 "Exchange 데이터베이스 오프라인 백업" 절에 있는 2단계를 참조하십시오.

    저장소 그룹에 있는 모든 데이터베이스가 분리되어 있는 경우 모든 데이터베이스는 일관성이 있어야 하며 유효한 검사점 파일도 있어야 합니다. 유효한 검사점 파일이란 실행하고 있던 저장소 그룹의 데이터베이스 중 마지막으로 사용되고 검사점으로 E0n.log를 나열하는 헤더가 있는 검사점 파일입니다. 저장소 그룹에 있는 데이터베이스가 여전히 탑재되어 있는 경우 유효한 검사점 파일은 시스템에서 현재 사용 중인 검사점 파일입니다. 저장소 그룹에 있는 데이터베이스가 실행 중인 경우 유효한 검사점이 있습니다.

    모든 데이터베이스가 중지될 때 검사점 파일을 확인하려면 다음 명령을 실행하십시오.
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    다음은 위 명령의 출력 예입니다.
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    앞의 예에서 검사점은 e00.log인 lGeneration이 0x2cc7인 로그(e00.log)에 있습니다. 따라서 검사점은 유효한 것으로 간주될 수 있습니다.

    검사점이 유효하지 않은 경우 저장소 그룹에 있는 데이터베이스를 탑재하려고 하면 -1216 오류 메시지(JET_errAttachedDatabaseMismatch)가 나타날 수 있습니다. 이 문제는 저장소 그룹에 있는 모든 데이터베이스가 일관성이 있는 경우에도 발생할 수 있습니다.
  2. 백업한 .edb 및 .stm 파일을 적절한 데이터베이스 및 스트리밍 파일 위치에 복사합니다. 이 위치를 찾으려면 이 문서의 "시작하기 전에" 절을 참조하십시오. 복원된 파일이 일관성이 있고 일치하는지 확인합니다.

    참고: 복원할 데이터베이스 파일의 복사본이 이미 서버에 있는 경우 기존 파일을 시작할 수 없더라도 데이터베이스를 복원하기 전에 이 파일을 백업하십시오. 이 파일은 복구할 수 있으며 Exmerge 유틸리티를 사용하여 이 파일에서 데이터를 구제할 수 있습니다.
  3. 복원된 데이터베이스를 탑재합니다. 해당 데이터베이스는 E0n.log 파일의 끝에 자동으로 연결됩니다. 데이터베이스가 성공적으로 시작된 후에는 기존 로그 파일이 데이터베이스로 재생될 수 없습니다. 계층 구조에 수천 개의 폴더가 포함되어 있는 공용 폴더 데이터베이스는 시작하는 데 오랜 시간이 걸릴 수 있습니다. 계층 구조에 있는 1,000개의 폴더마다 최소 1분이 걸립니다.

    이전 버전의 Exchange Server에서는 대개 정보 저장소 데이터베이스의 오프라인 백업을 복원한 후에 정보 저장소 데이터베이스를 디렉터리와 동기화하기 위해 ISINTEG -patch 명령을 실행해야 했습니다. 데이터베이스가 다른 서버, 저장소 그룹 또는 논리 데이터베이스 개체로 복원되거나 Active Directory에서 데이터베이스에 대한 Active Directory 개체가 삭제되었다가 다시 만들어진 경우가 아니면 Exchange 데이터베이스에 대한 패치가 필요할 때 시스템에 의해 해당 패치가 자동으로 수행됩니다. 이러한 경우에는 다음과 유사한 오류 메시지가 응용 프로그램 이벤트 로그에 기록됩니다.
    이벤트 종류: 오류
    이벤트 원본: MSExchangeIS Mailbox Store
    이벤트 범주: 일반
    이벤트 ID: 1087
    날짜: 2001-05-04
    시간: 오후 8:33:42
    사용자: N/A
    컴퓨터: EXCHANGE1
    설명: 오프라인 백업에서 정보 저장소가 복원되었습니다. Microsoft Exchange System Manager에서 "First Storage Group\Private Information Store" 데이터베이스가 패치될 수 있도록 복원을 허용하십시오.
    이 문제를 해결하려면 Exchange System Manager의 데이터베이스 개체에 대한 데이터베이스 속성에서 복원 시 데이터베이스 덮어쓰기 가능 확인란을 선택해야 합니다.

오프라인 백업의 롤 포워드 복원

로그 파일을 복원된 데이터베이스에 성공적으로 재생하려면 다음과 같이 하십시오.
  • 가장 오래 전의 전체 백업 후 생성된 모든 트랜잭션 로그의 복사본을 보존합니다.
  • 바로 다음에 새로운 전체 백업을 수행하지 않았다면 데이터베이스 경로를 변경하지 마십시오.
  • 바로 다음에 새로운 전체 백업을 수행하지 않았다면 ESEUTIL /p 또는 ESEUTIL /d를 실행하지 마십시오.
  • 저장소 그룹에 있는 모든 데이터베이스의 전체 백업을 바로 수행하지 않았다면 저장소 그룹에 있는 데이터베이스를 추가하거나 제거하지 마십시오.
복원 프로세스를 시작하려면 다음과 같이 하십시오.
  1. 복원할 데이터베이스가 탑재되어 있으면 분리한 후 복원할 데이터베이스 파일을 서버의 적절한 경로에 복사합니다. 복원할 데이터베이스 파일의 복사본이 서버에 이미 있는 경우 기존 파일을 시작할 수 없더라도 데이터베이스를 복원하기 전에 이 파일을 백업하십시오. 이 파일은 복구할 수 있으며 Exmerge 유틸리티를 사용하여 이 파일에서 데이터를 구제할 수 있습니다.
  2. 저장소 그룹에 있는 모든 데이터베이스를 분리한 다음 현재 저장소 그룹에 있는 각 데이터베이스와 복원된 각 데이터베이스 파일에 대해 다음 명령을 실행합니다.
    eseutil /mh database_file_name | find /i "consistent"
    참고: Exchange 2000 서비스 팩 2 이상에서는 데이터베이스 상태를 "Consistent"나 "Inconsistent"가 아니라 "Clean Shutdown"이나 "Dirty Shutdown"으로 보고합니다. "Clean Shutdown"은 "Consistent"와 동일한 의미이며 "Dirty Shutdown"은 "Inconsistent"와 동일한 의미입니다. Exchange 2000 서비스 팩 2 이상인 경우 이 추가 명령을 실행하여 각 데이터베이스의 상태를 확인하십시오.
    eseutil /mh database_name | find /i "Shutdown"
    다음은 위 명령의 출력 예입니다.
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    이 명령을 실행하는 세 가지 목적은 다음과 같습니다.
    • 데이터베이스 파일이 서로 일관성이 있는지 확인
    • 각 데이터베이스에 대한 .edb 및 .stm 파일이 올바른 쌍인지 확인
    • -1216 오류를 생성하지 않고 모든 데이터를 성공적으로 복구하는 데 필요한 첫 번째와 마지막 로그 파일인 낮은 앵커 로그와 높은 앵커 로그 파일 식별. 모든 데이터베이스에서 가장 낮으며 일관성 있는 마지막 값은 낮은 앵커 로그이며 가장 높으며 일관성 있는 마지막 값은 높은 앵커 로그입니다.
    앞의 예에서 낮은 앵커 로그 파일은 E0002ac8.log이며 높은 앵커 로그 파일은 E0002cc7.log입니다.
  3. 각 데이터베이스 헤더에 기록된 로그 서명이 낮은 앵커 로그의 서명인지 확인합니다. 다음 명령을 실행합니다.
    eseutil /mh database_name | find /i "Log Signature"
    eseutil /ml low_anchor_log | find /i "Signature"
    다음은 위 명령의 출력 예입니다.
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    로그 파일에서 여러 개의 서명을 보고할 수 있습니다. 첫 번째 서명은 항상 로그 파일 자체의 서명이며 나머지는 로그 파일이 생성될 때 실행 중이던 데이터베이스의 서명입니다. 앞의 예에서 데이터베이스 파일에 기록된 로그 서명은 낮은 앵커 로그의 로그 서명과 일치합니다.

    낮은 앵커 로그를 찾을 수 없는 경우 해당 데이터베이스로 로그를 재생할 수 없습니다. 낮은 앵커 로그 파일을 찾을 수 없는 경우 데이터베이스로 어떤 로그 파일도 재생할 수 없습니다. 누락된 낮은 앵커 로그를 처리하는 데 사용할 수 있는 방법은 두 가지가 있습니다.
    • 모든 로그 파일을 제거할 수 있습니다. 데이터베이스는 모두 일관성이 있기 때문에 로그 파일 없이도 시작할 수 있지만 데이터베이스 파일에 아직 없는 데이터는 복원할 수 없습니다.
    • 낮은 앵커에서 높은 앵커로 연속적인 로그 파일 시리즈를 구성하고 나머지 데이터베이스에서 복구를 실행할 때까지 가장 낮으며 일관성 있는 마지막 값이 있는 데이터베이스를 제거할 수 있습니다. 제거한 데이터베이스를 다시 저장소 그룹에 넣으면 추가 데이터를 재생할 수 없습니다.
  4. 현재 데이터베이스 경로 위치가 백업을 만들 때와 동일한지 확인합니다.

    백업한 후에 트랜잭션 로그 경로나 작업 경로를 변경할 수 있지만 데이터베이스 파일이 백업한 위치에 있어야 로그 파일을 재생할 수 있습니다. 원래 위치가 확실하지 않은 경우 다음 명령을 실행하십시오.
    eseutil /ml "Last_Consistent"_log | find /i "database name or pattern"
    다음은 위 명령의 출력 예입니다.
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    참고: 첫 번째 데이터베이스가 로그에 연결되기 전에 시리즈 중 첫 번째 로그의 헤더가 생성되므로 낮은 앵커 로그가 E0n00001.log인 경우에는 헤더에 경로 정보가 없습니다. 이 경우 데이터베이스 경로 정보를 보려면 다음 로그의 헤더를 확인해야 합니다. 데이터베이스는 로그가 생성된 후에 만들어지거나 로그 스트림에 연결되므로 드물기는 하지만 첫 번째 이후의 로그에 이 사항이 적용되는 경우도 있습니다.
  5. 연속적인 시퀀스에서 가능한 한 앞쪽의 낮은 앵커 번호부터 로그를 모두 수집하고 이러한 로그를 현재 트랜잭션 로그 경로에 복사합니다. 서버에 이미 있는 로그를 먼저 백업하고 이러한 로그를 덮어씁니다. 이렇게 하려면 두 종류 이상의 백업 미디어에서 로그 파일을 복원해야 합니다.

    앞의 예에서 낮은 앵커는 E0002ac8.log이며 높은 앵커는 E0002cc7.log입니다. 사용 가능한 로그를 검사할 때 찾을 수 있는 가장 높은 번호의 로그는 필요한 번호보다 하나 낮은 번호가 될 수 있습니다. 예를 들어, 2cc7 대신 E0002cc6.log가 될 수 있습니다. 이는 주로 E0n.log가 아직 채워지지 않았으며 순서대로 번호가 있는 이름으로 바뀌기 때문입니다. E0n.log가 실제로 높은 앵커 로그인지 확인하려면 다음 명령을 사용하여 로그 파일 헤더에 있는 lGeneration 값을 검사해야 합니다.
    eseutil /ml E0n.log | find /i "lGeneration"
    다음은 위 명령의 출력 예입니다.
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    참고: Eseutil 유틸리티를 사용하여 로그 파일의 헤더를 보려면 /ml 스위치를 사용하고, 데이터베이스 파일의 헤더를 보려면 /mh 스위치를 사용합니다. 스위치를 잘못 사용하면 잘못된 결과가 출력됩니다.

    일반적으로 높은 앵커 로그는 사용 가능한 가장 높은 로그이지만 다음과 같은 경우는 이에 해당되지 않습니다.
    • 로그 파일이 재난으로 파괴된 경우

      또는
    • 저장소 그룹에 있는 모든 데이터베이스를 한번에 복원하는 경우
    첫 번째 경우에는 복구하는 동안 -1216 오류가 발생할 수 있습니다. 두 번째 경우에는 lGeneration 시퀀스가 계속되는 한 높은 앵커 로그를 지나서도 로그 파일을 앞으로 재생할 수 있습니다.
  6. 모든 로그가 동일한 로그 서명을 공유하며 연속적인 순서인지 확인합니다. 다음 명령을 실행합니다.
    eseutil /ml E0n > filename.txt
    다음은 위 명령의 출력 예입니다.
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    이 Eseutil 명령은 세 가지 작업을 수행합니다. 먼저 각 로그 파일이 손상되었는지 확인하고, 로그 파일 시퀀스에서 건너뛴 번호가 있는지 보고한 다음, 로그 서명 불일치를 찾습니다.

    모든 로그 서명은 재생할 모든 로그 파일 간에 일치해야 합니다. 재생을 시작하기 전에 일치하는 서명이 없는 로그는 제거해야 합니다.

    확인 테스트를 통과하지 못한 파일을 제거한 후에 Transaction Logs 폴더에 있는 유일한 트랜잭션 로그 파일의 특성은 다음과 같습니다.
    • 낮은 앵커 로그 파일에서 시작하여 최소한 높은 앵커 로그 파일까지, 가능한 경우 그 이상의 연속적 lGeneration 시퀀스에 있습니다.
    • 일치하는 로그 서명이 있습니다.
  7. 높은 앵커 로그의 이름이 아직 E0n.log로 바뀌지 않았으면 이름을 바꿉니다.
  8. System Path 폴더에서 E0n.chk 파일을 제거합니다.

    검사점 파일이 없으면 Exchange Server에서는 Transaction Logs 폴더에 있는 가장 낮은 번호의 로그 파일, 즉 낮은 앵커 로그를 재생하기 시작합니다. E0n.chk 파일이 있으면 Exchange Server에서는 이 파일에 기록된 검사점에서 재생을 시작합니다. E0n.chk가 낮은 앵커 로그 이후의 로그를 가리키면 복원된 파일 집합에 대해 전체적인 재생이 실패합니다. 대개 검사점 파일에서 실수하면 백업에서 데이터베이스 파일 복원을 다시 시작해야 합니다.
  9. 저장소 그룹을 탑재하기 전의 최종 검사 단계로 다음을 확인합니다.
    • 모든 데이터베이스 파일이 실행 중인 경로에 있는지 확인합니다.
    • 실행 중인 트랜잭션 로그 경로에 있는 로그 파일만이 낮은 앵커 로그에서 시작하여 E0n.log라는 가장 높은 로그가 있는 높은 앵커 로그 이상으로 진행되는 파일입니다.
    • System Path 폴더에는 E0n.chk 파일이 없습니다.
    이제 저장소 그룹을 성공적으로 탑재하고 이 파일 집합으로 트랜잭션 로그의 재생을 시작할 수 있어야 합니다. 복구가 완료되고 데이터베이스가 시작된 후에도 재생 중에 발생된 DB 서명과 경로 문제로 인해 모든 로그 파일에 있는 모든 데이터가 실제로 복구되지 않을 수 있습니다. 이 문서의 "데이터베이스 서명 및 경로 불일치 처리" 절에서는 이러한 문제에 대한 추가 정보를 제공합니다.
  10. 정보 저장소가 아직 실행 중이 아니면 정보 저장소를 시작한 후 저장소 그룹에 있는 데이터베이스를 하나 이상 탑재합니다. 이렇게 하면 저장소 그룹에 있는 모든 데이터베이스에 대해 소프트 복구가 실행됩니다.

    이전 버전의 Exchange Server에서는 정보 저장소 데이터베이스를 디렉터리와 동기화하기 위해 데이터베이스의 오프라인 백업을 복원한 후에 ISINTEG -patch 명령을 실행해야 합니다. 데이터베이스가 다른 서버, 저장소 그룹 또는 논리 데이터베이스 개체로 복원되거나 Active Directory에서 데이터베이스에 대한 Active Directory 개체가 삭제되었다가 다시 만들어진 경우가 아니면 Exchange 데이터베이스에 대한 패치가 필요할 때 시스템에 의해 해당 패치가 자동으로 수행됩니다. 이러한 경우에는 다음과 유사한 오류 메시지가 응용 프로그램 이벤트 로그에 기록됩니다.
    이벤트 종류: 오류
    이벤트 원본: MSExchangeIS Mailbox Store
    이벤트 범주: 일반
    이벤트 ID: 1087
    날짜: 2001-05-04
    시간: 오후 8:33:42
    사용자: N/A
    컴퓨터: EXCHANGE1
    설명: 오프라인 백업에서 정보 저장소가 복원되었습니다. Microsoft Exchange System Manager에서 "First Storage Group\Private Information Store" 데이터베이스가 패치될 수 있도록 복원을 허용하십시오.
    이 문제를 해결하려면 Exchange System Manager의 데이터베이스 개체에 대한 데이터베이스 속성에서 복원 시 데이터베이스 덮어쓰기 가능 확인란을 선택해야 합니다.
데이터베이스를 시작할 때 발생할 수 있는 오류나 문제를 보려면 Microsoft Windows NT 이벤트 뷰어에서 응용 프로그램 이벤트 로그를 확인하십시오. 재생된 각 로그 파일에 대해 이벤트 301이 나타납니다. 복구 프로세스 동안 오류와 경고가 나타나는지 주의깊게 살피십시오.

데이터베이스 서명 및 경로 불일치 처리

데이터베이스에는 로그 파일과 마찬가지로 자체 서명이 있습니다. 그러나 로그 서명은 E0n000001.log 파일이 생성된 이후 변경되지 않는 반면, 데이터베이스 서명은 데이터베이스의 물리적 토폴로지가 바뀔 때마다 변경됩니다. 변경 사항은 로그 파일을 통해 추적되지 않습니다. Eseutil을 사용하여 데이터베이스의 오프라인 조각 모음이나 복구를 수행하면 DB 서명이 변경됩니다. 이러한 이벤트 후에 데이터베이스는 이전과 동일한 로그 스트림에 연결될 수 있지만 데이터베이스에 이전 서명이 있을 때 수행된 트랜잭션의 재생은 허용하지 않습니다. 데이터베이스의 이전 복사본은 데이터베이스 서명이 변경된 후에 수행된 트랜잭션의 재생을 허용하지 않습니다.

데이터베이스 서명은 이러한 방식으로 다시 설정되기 때문에 데이터베이스의 오프라인 조각 모음이나 복구 후에 즉시 전체 데이터베이스 백업을 수행해야 합니다. 나중에 기존 서명이 있는 데이터베이스의 복사본을 복원할 경우 서명이 변경된 시점까지는 재생이 성공하지만 그 후의 모든 변경 내용은 손실됩니다.

데이터베이스 경로가 로그 스트림 중간에 변경되면 서명을 변경하는 것과 비슷한 결과가 나타납니다. 재생은 변경 시점에서 중단됩니다. 온라인 백업 API는 복구 동안 경로를 다시 매핑하는 기능을 제공하므로 백업을 수행한 이후로 경로가 변경된 경우라도 온라인 백업 API는 로그를 완벽하게 재생할 수 있습니다.

DB 서명이나 DB 경로 문제는 재생 중에 발생하기 때문에 이러한 DB 서명이나 DB 경로 문제는 각 로그 파일의 301 재생 이벤트와 함께 응용 프로그램 이벤트 로그의 줄에 보고됩니다. 문제가 발생한 지점을 지난 로그 파일은 성공적으로 재생되는 것으로 나타날 수 있지만 이는 동일한 불일치 경고가 반복적으로 기록되지 않기 때문입니다. 일반적으로 특정 데이터베이스로의 재생은 해당 데이터베이스에서 첫 번째로 발생한 DB 서명이나 경로 오류 시점에서 잘립니다.





Microsoft 제품 관련 기술 전문가들과 온라인으로 정보를 교환하시려면 Microsoft 뉴스 그룹에 참여하시기 바랍니다.

속성

기술 자료: 296788 - 마지막 검토: 2007년 12월 3일 월요일 - 수정: 4.6
본 문서의 정보는 다음의 제품에 적용됩니다.
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
키워드:?
kberrmsg kbhowto kbproductlink KB296788

피드백 보내기

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com