정보 처리/데이터베이스

백업과 복원 - 데이터베이스 백업과 복원 계획 수립 방법

본클라쓰 2010. 1. 2. 08:56

 

데이터베이스의 백업과 복원 방법에 대해 익혔다면, 데이터베이스를 언제, 어떻게, 어디에 백업할 것인지에 대한 확실한 계획을 수립하고 이를 문서화하는 것이다. 소용량의 데이터베이스를 운영한다면 단지 자주 백업하고, 여러 곳에 백업하는 것만으로도 충분할 수 있지만 대용량의 데이터베이스를 운영하는 경우는 다음과 같은 부분을 고려하여 백업 및 복원 계획을 수립하는 것이 중요한다.

 

 

1. 운영 메뉴얼 작성

 

비상상황에서는 어떻게 복원하겠다는 계호기이 정확히 수립되어 있어야 한다. 열심히 백업을 받아놓은 회사의 경우에도 실제 비상 상황이 발생하면 어떻게 복원해야 하는지 허둥대는 경우가 많다. 백업을 잘 받아놓으면 결국 복원은 되겠지만, 1초의 시간의 절박한 인터넷 기업의 경우에는 완벽한 복원과 더불어 얼마나 짧은 시간에 복원하느냐도 매우 중요하다. 그러므로 운영 매뉴얼을 작성한 후에는 매뉴얼의 상황대로 테스트를 해보아서 원하는 시간에 복원이 되는지를 확인하는 것이 필요하다.

 

 

2. 백업 받을 데이터베이스 결정

 

특히, 시스템 데이터베이스는 꼭 백업을 받아야 한다. 앞에서 실습했듯이 시스템 데이터베이스에 심각한 문제가 발생되면 SQL Server가 가동되지 않는다. 그렇다면 시스템 데이터베이스는 얼마나 자주 백업을 받을 것인가? master 데이터베이스의 경우에는 데이터베이스를 생성, 수정, 삭제하는 경우나 SQL Server 사용자 정보의 수정, 데이터베이스 구성 값 변경 등이 생길 때마다 백업을 새로 받아주면 된다.

 

 

3. 데이터베이스의 중요도와 데이터 갱신 시간

 

데이터베이스의 중요도와 얼마나 자주 데이터가 갱신되느냐에 따라서 백업하는 방법과 주기를 결정해야 한다. 대개, 중요하다고 생각되는 데이터베이스는 일주일에 한번 정도 전체 백업을 받아주고, 차등 백업은 매일, 로그 백업은 시간 단위로 받는 것이 적절하다. 물론, 이 기준은 절대적인 것이 아니다. 더 자주해야 하는 중요한 데이터베이스가 있을 수 있고 또 그렇지 않은 경우도 있을 수 있다.

 

 

4. 데이터베이스가 많이 사용되는 시간에 따라서

 

많은 인터넷 기업들은 주로 주간에 데이터베이스를 사용하며 야간에는 거의 사용하지 않는 경향이 많다. 그렇다면 백업은 주간에 받는 것보다 업무가 끝난 야간에 받는 것이 적절하다. 만약, 야간에만 사용되는 데이터베이스가 있다면 이는 아침시간에 백업을 받는 것이 적절할 것이다.

 

 

5. 백업되는 시간

 

테이프, 광학 쥬크 박스 등은 가격이 저렴하지만, 디스크에 비해서 속도가 매우 느리다. 권장할 만한 방법은 디스크에 백업을 수행한 후에, 이를 테이프 등에 옮기는 것이 백업 시간을 많이 단축시켜 줄 수 있을 것이다. 또는 다중 백업 장치를 이용하면 백업시간을 훨씬 단축할 수 있다.

 

 

6. 백업매체의 보관

 

백업한 매체를 보관 시에 보관되는 장소의 온도나 습도 등도 고려해야 한다. 열심히 백업 받는 테이프를 막상 복원하려는 순간에 매체의 손상으로 난감한 상황을 겪을 수가 있다. 그리고 정말 중요한 데이터라면 화재 등의 재난에 대비해서 같은 장소가 아닌 지리적으로 멀리 떨어진 장소에도 보관해야 할 필요도 있다.

 

 

7. 서드파티 프로그램은 꼭 검증 후에 사용

 

백업의 성능향상을 위해서 서드파티 프로그램을 별도로 구매해서 사용하는 경우에는 꼭 해당 프로그램을 검증한 후에 사용하도록 하자.

 

 

8. 적절한 복구 모델의 선택

 

가장 안전한 것은 전체 복구 모델이지만, 이 모델은 시스템에 과부하를 줄 위험이 있다. 특히, 대량 로그 작업이 일어나는 경우에는 더욱 그러하다. 대량 로그 작업이 필요한 경우에 잠시 복구 모델을 대량 로그 복구 모델로 전환하고, 대량 로그 작업이 끝나면 다시 전체 복구 모델로 변경하는 것도 좋은 방안이다. 관리자의 입장에서는 좀 귀찮을 수 있지만, SQL Server 관리자를 꽤 고맙게 생각할 것이다.