제목 : 익스체인지 서버 2000 데이터베이스 구조: 복원작업하는 날은 언제나 궂은 날
저자 : Will Schmied
번역자 : 채현수
URL : http://www.msexchange.org/tutorials/The_Exchange_Server_2000_Database_
Structure_Its_always_a_rainy_day_when_youre_doing_restorations.html
익스체인지 서버의 구축과 기본 프로세스를 이해하면, 마침내 인생에서 진정으로 유일하게 가치 있는 “행복”에 확실히 다가갈 수 있다.
익스체인지 서버는 복잡한 괴물이다. 가장 덜 복잡한 괴물이라고 해두자. 익스체인지 서버는 우리가 도망갈수 없는 현실이다. 익스체인지를 사용하는 사람이라면, 이 사실을 받아들이고 작업하는 것이 최선이다. 익스체인지 2000이 아무리 쉽다고 하더라도, 여전히 토요일 오후에 할만한 가장 즐겁고 쉬운 일은 될 수가 없다(다른 날도 마찬가지겠지만).
익스체인지 서버의 구축과 기본 프로세스를 이해하면, 마침내 인생에서 진정으로 유일하게 가치 있는 “행복”에 확실히 다가갈 수 있다.
데이터베이스
요즘은 모든 것에 일종의 데이터베이스가 필요하다. 국세청, 액티브 디렉토리, 심지어 동네 슈퍼마켓에서도 데이터베이스를 사용한다. 데이터베이스, 좋다. 하지만 데이터베이스를 이해하기가 항상 쉽지는 않다. 그림 1은 익스체인지 데이터베이스가 어떻게 생겼는지 보여준다.
그림 1 – 현재 데이터베이스(익스체인지 2000 서버 리소스 키트 28장 참조)
그림 1에서 보는 바와 같이, 저장그룹을 구성하는 현재의 익스체인지 데이터베이스는 사실상 3개의 파일이다. 3개의 파일에 대해 설명하자면 다음과 같다.
• .edb파일은 데이터 전송을 위한 모든 폴더와 테이블 그리고 인덱스를 보유하고 있다. 그리고, 이 파일은 MAPI 메시지와 첨부파일 전송을 위한 폴더, 테이블, 인덱스도 함께 보유한다.
• .stm 파일(익스체인지 2000에서 새롭게 나온 형식)은 포맷형식 자체에 인터넷 컨텐츠를 포함하고 있다.
• .log 파일(트랜잭션 로그)은 저장그룹 내에 저장되어 있는 모든 메시지의 레코드(기록)를 보유한다. 데이터베이스에서 반드시 복원되어야 하는 이벤트의 오류 한계(제한)를 제공한다. 익스체인지 2000 로그 파일은 항상 5MB(5,252,880 바이트)의 크기를 유지하므로, 크기가 다르다면 손상을 입은 것이다. 각각의 저장그룹은 또한 로그파일을 가진다. Res1.log, Res2.log는 서비스 공간이 부족할 때 사용되는 여분디스크 공간에 위치한다.
체크포인트 파일
앞에서 설명한 파일들 이외에, 익스체인지 서버 데이터베이스를 정상적으로 유지하도록 만드는 특별한 파일 하나가 더 있다. 체크포인트 파일(edb, chk)은 트랜잭션 로그파일 내에 이미 기록된 기록사항 들을 추적한다. 앞서 말한 바와 같이, 어떤 기록사항들은 복원시에 다시 재실행될 필요가 있을 것이다. 체크포인트 파일은 로그파일의 기록사항들 가운데 어느 것이 재실행되어야 하는지 정확하게 ESE 에게 통보함으로써 복구 속도를 증가시킨다. 그렇게 함으로써, 복원과정에서 불필요한 쓰기작업을 막는다.
순환 로깅
일반적으로 로그파일이 가득차면, 익스체인지는 로그파일의 이름을 바꿔서 다른 곳으로 옮겨두고, 로그파일을 다시 만든다. 이렇게 하면, 로그 파일이 지워지지도 않고 5MB의 증가범위 내에서 계속 사용한다. 트랜잭션의 수가 늘어나면, 로그파일 세트가 만들어진다. 만약 데이터베이스에서 오류가 발생하면, 트랜잭션은 로그파일을 이용해서 데이터를 복원하여 원상회복시킨다. 순환 로깅이 가능한 상태에서는, 최초 로그 파일은 로그 파일에 포함된 데이터가 데이터베이스에 쓰여진 이후부터 덮어쓰기가 되면서 재사용된다. 순환로깅을 사용할 수는 있지만, 기본값으로는 사용안함으로 설정되어있다. 순환로깅을 사용하게 되면, 마지막 전체 백업 이후에 상태로 복구할 수 없다. 이러한 이유로, 순환로깅은 중요한 작업이 이루어지는 상황에는 일반적으로 권장하지 않는다.
체크섬
체크섬 개념은 새로운 것이 아니다. 체크섬은 파일의 유효성을 결정하는데 오랫동안 사용되었다. 익스체인지 서버는 체크섬을 “.edb”파일의 유효성을 확인하는데 사용한다. 모든 “.edb”파일은 최대 4KB 페이지의 크기로 만들어지며, 각 페이지의 무결성은 체크섬과 데이터베이스 페이지의 헤더에 있는 4바이트 크기의 페이지 번호를 통해서 판별한다. 데이터베이스의 각 페이지에서 처음 82바이트는 헤더 정보를 포함하는데, 헤더에는 페이지의 유형에 대한 플래그 와 페이지에 어떤 종류의 데이터가 포함되어 있는지에 관한 정보를 포함하고 있다. 데이터에서 페이지가 읽혀질 때, 페이지들을 정확한 페이지 번호와 비교하는 동시에 체크섬과도 비교한다. 체크섬은 페이지가 손상되지 않고 읽혔는지 확인하는데, 손상이 발견되면 오류값이 반환되고 데이터베이스는 멈추는 동시에 이벤트 로그에 이벤트가 기록된다. 이렇게 함으로써 데이터베이스는 최상의 무결성을 유지하면서 작동하도록 보장된다.
그외의 중요한 파일들
비록 실질적인 익스체인지 데이터베이스에 포함되는 것은 아니지만, 다음의 두 파일은 익스체인지 서버에 존재할 수 있다.
• .srs 파일은 익스체인지 5.5 디렉토리 서비스를 에뮬레이트함으로써 익스체인지 5.5 서버와 호환성을 제공한다. 이 파일은 익스체인지 ADC 가 설치되었을 경우에 한하여 존재하며, 여러분은 사이트 복제 서버를 설정한다.
• .kms 파일은 보안과 암호화 서비스를 제공한다. 이 파일 역시 KMS 를 설치했을 경우에만 존재한다.
그래서, 어쩌라고.
좋다. 그럼 우리는 이제 익스체인지 서버의 데이터베이스가 어떻게 구성되고, 이것에 어떤 특별한 기능이 있는지 대충 감을 잡았다. 하지만, 무슨 상관이란 말인가? 그래서 특별한 점은 무엇인가? 글쎄다. 내가 토요일 오후에 익스체인지 작업을 시작하기 앞서 언급했을 때만해도, 토요일 오후가 익스체인지 서버를 박살낼 수 있는 좋은 타이밍이라서 망가진 서버를 직접 복구하고, 월요일에는 일상적인 업무를 계속할 수 있다고 생각했기 때문이었다. 그래서, 여러분들이 동참했던 것이다. 안 그런가?
나는 ‘재난 복구’라는 장에서 익스체인지 복구에 관해 설명했다. 그러나, 백업 시스템의 설정이나 복원 작업의 실행 방법에 대한 세부사항까지는 언급하지 않았다. 백업 실행 과정을 다루기 전에, 좀더 상세하게 말하면, 어떻게 익스체인지가 백업 요청을 처리하는가를 다루기 전에, 우리는 각 백업 유형의 목적에 대해 이해하여야 한다.
백업 유형
ntbackup.exe를 사용하여 수행될 수 있는 백업의 유형은 모두 다섯 가지이다. 그러나, 이 가운데 네 가지만이 익스체인지 서버에 적용된다. 요약하면 다음과 같다.
• 전체(일반)백업은 전체 웹 저장 시스템(Web Storage System)과 익스체인지 로그 파일을 백업한다. 데이터베이스 상에서 이미 완료(커밋)된 트랜잭션을 포함하고 있는 모든 트랜잭션 로그는 삭제된다. 전체백업으로 복원하는 것은 전체백업 미디어로만 가능하다. 전체백업은 익스체인지 데이터베이스를 백업에서 선호되는 방법이다.
• 복사백업은 전체 백업과 동일하다. 단지, 트랜잭션 로그 파일이 지워지지 않고 남아있다는 점만이 다를 뿐이다. 여러분은 다른 유형의 백업 상태에 영향을 주지 않고, 복사백업을 할 수 있다.
• 증분백업은 모든 로그파일을 백업하지만, 체크 포인트 로그 이전의 모든 로그 파일을 삭제합니다. 추가적으로, 증분백업은 모든 트랜잭션 로그 파일을 백업하고 데이터베이스에서 완료된 트랜잭션을 포함하는 로그 파일을 삭제한다. 증분백업으로 복원하기 위해서는 가장 최근의 전체백업과 그 이후로 진행한 일련의 증분백업이 필요하다. 만약 하나의 증분 백업이 손상되었다면, 손상된 로그 파일이 이후의 로그 파일을 실행하지 못하도록 만들기 때문에, 손상된 로그 파일의 시점 이후로 생성된 어떤 증분백업도 복원할 수 없다. 데이터 손실이나 데이터베이스 손상을 막기 위해서 로그 파일을 재실행하기에 앞서 모든 증분백업을 복원한다는 점은 매우 중요하다.
• 차등백업은 체크포인트 파일보다 앞서는 모든 로그파일을 백업한다. 그러나, 지우지는 않는다. 그렇기 때문에, 각각의 백업파일은 이전의 백업파일보다 크다. 차등백업으로 복원할 때는 가장 최근의 전체백업과 그 이후에 만들어진 차등 백업가운데 마지막으로 만든 차등백업이 필요하다. 차등백업은 전체백업 다음으로 선호되는 백업 방법이다.
백업 과정
Ntbackup.exe를 사용하여 백업을 시작하면, 웹 저장 시스템(Web Storage System)은 백업모드가 시작된다는 사실을 ESE에게 알려주며, 백업된 데이터베이스용 패치파일이 각각 생성된다. 전체백업의 경우에는 패치파일이 생성되지 않는다. 현재 열려있는 로그 파일은 닫히고 이름이 변경되며, 동시에 새로운 로그파일이 열리게 된다. 이것은 백업작업이 완료된 후에 ESE가 해당 포인트에서 로그를 잘라낼 수 있음을 의미한다. 그림 2는 백업과정을 나타낸 것이다.
그림 2. 백업 과정 (익스체인지 서버 리소스 키트 28장 참조)
백업이 시작되면, 에이전트는 데이터베이스는 ESE로부터 모든 데이터베이스 페이지를 읽어 들이고 정렬하도록 요청한다. 데이터베이스가 페이지들을 읽는 동안, ESE는 각 페이지들이 유효한지를 체크섬을 사용하여 확인을 한다. 만약 유효하지 않은 페이지라면, 백업은 손상된 데이터의 저장을 피하기 위해서 멈춘다. 백업이 완료되고 모든 페이지를 읽은 이후에, 백업은 로그파일과 패치파일을 백업세트로 복사한다. 백업의 시작을 기점으로 새로운 로그가 발생되면서, 로그파일은 포인트를 기준으로 잘리거나 삭제된다. 백업 세트는 닫히고, ESE는 일반모드로 바뀌며 백업이 모두 완료된다.
진행과정 설명은 여러분이 온라인 백업(데이터 베이스가 백업 당시 온라인상태)을 수행한다는 가정하에서 진행되었다. 이는 데이터베이스가 온라인 상태를 유지하여 사용이 가능하도록 허용되므로 선호되는 방법이다. 그러나, 여러분은 또한 데이터베이스가 오프라인 상태에서 오프라인 백업을 진행할 수도 있다. 오프라인 백업은 항상 전체백업이 되며, 데이터베이스 서비스가 내려진 상태이므로 네트워크내의 사용자들은 쓰기작업은 불가능하다.
복원 과정
복원과정은 백업과정을 반대로 한 것과 매우 유사하다. 복원을 하기 전에, 데이터베이스나 저장 그룹을 오프라인 상태로 만들어야 한다. 일단 복원작업이 진행되면, ESE는 복원 모드로 들어간다. 백업 에이전트는 백업 미디어를 지정된 위치로 복제한다. 관련된 로그파일과 패치파일은 백업 오퍼레이터가 지정한 임시 저장소로 복제되며, 그럼으로써 이 파일들이 익스체인지나 프로덕션 데이터베이스 디렉토리의 파일들과 동일한 위치에 저장되지 않게 된다. 로그파일과 패치파일이 동일한 위치로 옮겨지게 되면, 로그파일이 기존의 로그파일을 덮어쓰면서 데이터베이스에 문제를 일으키게 된다. 파일들이 복원된 후에, ESE는 오로지 데이터베이스를 복원하기 위한 특수 인스턴스를 시작한다. 이 작업은 패치파일과 로그파일을 데이터베이스를 갱신하도록 만든다. 복원이 완료된 후에, 로그파일과 패치파일은 임시 저장소에서 삭제되며, 저장그룹은 올려져서 사용할 수 있게 된다. 그림 3은 복구과정을 요약한 것이다.
그림 3 – 복구 과정( 익스체인지 2000 서버 리소스 키트 28장 참조)
마지막 한가지
윈도우 2000(5.0.2172.1)에서 제공되는 ntbackup.exe는 익스체인지 2000 서버 백업을 수행하는 데 사용할 수 없다는 것을 말해두고자 한다. 여러분은 5.0.2195.1117이나 그 이후 버전이 시스템에 설치되어 있어야 할 것이다. 그림 4는 윈도우 2000에서 제공되는 수정되지 않은 ntbackup.exe의 모습이다. 그리고 그림 5은 서비스 팩2에서 제공되는 ntbackup.exe이다.
그림 4 - ntbackup.exe original file.
그림 5 – 서비스 팩2의 ntbackup.exe
마무리
이상에서 살펴본 바와 같이, 비록 익스체인지 서버 데이터베이스가 손상을 최소화하고 손상된 데이터베이스의 사용을 막기위해서 보호장치가 추가되었기 때문이라고 하더라도, 익스체인지 서버 데이터베이스의 구조는 매우 복잡하다. 비록 대부분의 과정이 눈에 보이지는 않기는 하지만, 백업과 복원과정은 매우 복잡한 것이 사실이다. 여러분에게 말하고 싶은 가장 중요한 것은 다음 두 가지이다. 첫째로 트랜잭션 로그나 체크포인트 로그를 임의적으로 삭제하지 말라. 삭제하게 되면, 정말로 아주 정말로 여러분의 주말을 망칠 수도 있다. 둘째로 익스체인지와 백업과정이 이 파일들을 정리하도록 내버려두라. 이것이 더 나은 방법이다.
'윈도우 서버군 기술 강좌 > Exchange Server' 카테고리의 다른 글
| 백업. 잘 되고 있습니까? (0) | 2008/06/10 |
|---|---|
| Key Management Service In Exchange 2000 Server (0) | 2003/04/04 |
| 익스체인지 서버 2000 데이터베이스 구조: 복원작업하는 날은 언제나 궂은 날 (0) | 2003/03/10 |
| 재해 복구 (0) | 2002/08/18 |
| 익스체인지 2000으로 메시지 아카이빙하기(Message Archiving) (0) | 2002/08/13 |
| Blocking Incoming Mail Using Microsoft Exchange 2000 (0) | 2002/08/13 |



댓글을 달아 주세요