백업과 복원 - 시스템에 발생할 수 있는 장애와 백업의 목표

 

시스템에 장애가 발생되면 관리자는 바로 장애가 일어난 원인을 찾고 복구해야 하지만, 실제로 일어나는 장애 중 에는 복구와는 상관없거나 자체적으로 복구되는 경우도 있습니다. 우선 장애를 다음과 같이 다섯 종류로 구분해 보고 각 구분에 따라 이를 해결하는 방법을 알아보겠습니다.

 

 

사용자 에러

 

사용자 에러의 발생 원인은 크게 실수로 인한 테이블 삭제, 잘못된 트랜잭션의 커밋으로 발생될 수 있습니다. 사용자 에러는 먼저 사용자에게 데이터베이스에 대한 가용성과 무결성에 대해 충분히 교육하여 장애를 예방해야 합니다. 그리고 장애가 발생했을 때 운영 모드가 단순 복구 모델이라면 데이터베이스를 닫힌 백업 파일을 이용하여 백업 시점으로 되돌리는 물리적인 복구 이외에는 방법이 없고, 데이터베이스를 장애 발생 이전 시점으로 복구하는 불완전 복구가 가능하지만 장애를 인지하는데 시간이 많이 지체되는 경우 사용자들이 입력한 데이터가 많이 손실되어 다시 입력해 주어야 하는 상황이 발생할 수 있습니다.

따라서 사용자 에러는 장애로부터 장애를 인지하는 시간의 간격이 좁을수록 복구하기 쉽고 사용자들의 데이터 손실도 최소화 할 수도 있습니다. 사용자 에러의 피해를 최소화하기 위해서는 평소에 관리자는 앞에서 언급한 장애 예방 교육과 함께 장애를 발생시킬 경우 최대한 빠른 시간에 관리자에게 알려줄 수 있는 경로를 확보해야 합니다.

 

 

미디어 장애

 

미디어 장애의 발생 원은은 크게 세 가지로 나누어 생각해 볼 수 있습니다. 첫째, 파일의 삭제, 둘째, 디스크 고장, 셋째, 디스크 컨트롤러 고장이 있습니다.

 

미디어 장애는 저장 매체의 고장이나 파일의 삭제 등 물리적으로 구성된 데이터베이스에 직접 손상이 일어나는 장애를 뜻합니다. 그러나 관리자가 평소에 이에 대비하여 데이터베이스를 구성하는 파일 들에 대해서 백업을 수행하는 동시에 장애에 대한 복구 계획을 마련하고 이런 계획에 따라 운영 모드를 정해서 운영해 왔다면 미디어 장애가 발생했을 때 장애로 인한 데이터베이스 정지 시간을 최소로 하여 데이터베이스를 복구할 수 있습니다.

 

 

구문 장애

 

구문 장애는 프로그램 오류, 권한 오류, 사용 가능 용량 제한이나 할당량 초과 및 여유 공간 부족으로 발생할 수 있습니다.

 

일반적으로 시스템에서 발생하는 구문 장애의 대부분은 프로그래머나 사용자에게 에러 구문을 알려주고 정상적인 사용을 유도하는 것만으로도 문제를 해결할 수 있스며, 필요한 경우 사용자가 사용 가능한 용량을 늘려주거나 권한을 할당하여 쉽게 문제를 해결할 수 있습니다. 그리고 일반적인 구문 장애는 데이터베이스에 손상을 입히지 않으며 입력에 실패하고 그에 해당하는 에러 메시지를 사용자에게 출력하는 정도이기 때문에 관리자가 복구할 필요는 없는 장애입니다.

 

 

사용자 프로세스 장애

 

사용자 프로세스 장애의 원인은 대부분 비정상적인 세션 종료 때문에 일어납니다. 다시 말하면 클라이언트 시스템을 다시 시작하거나 접속 프로그램을 종료하는 등의 문제로 세션이 비정상적으로 종료되었을 때 이런 장애가 발생할 수 있습니다. 데이터베이스의 관리 툴은 데이터베이스에 접근하는 사용자 프로세스를 감시하고 사용자 프로세스가 비정상적으로 종료되었을 경우 이 세션의 서버 프로세스를 찾아 트랜잭션을 롤백하고 자원과 락을 해제하므로 관리자가 복구 작업을 수행할 필요가 없습니다.

 

 

인스턴스 장애

 

인스턴스 장애는 정전으로 인한 서버의 종류, CPU, 메모리 등의 장치 장애나 운영체제 장애로 인한 종료, 백그라운드 프로세스 장애등으로 발생될 수 있습니다.

 

SQL 서버는 인스턴스를 시작하면 자동으로 롤 포워드와 롤백을 수행하여 인스턴스를 복구합니다. 이러한 작업은 시스템 모니터가 수행하며 관리자는 사용자에게 유실된 트랜잭션을 다시 실행하도록 통보하면 됩니다. 인스턴스 장애도 데이터베이스에 장애를 일으키지 않으므로 관리자가 복구 작업을 수행할 필요가 없습니다.

 

 

 

 

백업의 목표

 

어떤 시스템을 이용하더라도 관리자의 가장 중요한 업무는 장애를 미리 방지하고, 장애가 발생하면 이를 수습하는 것입니다. 이를 위해서는 발생할 수 있는 장애를 유형별로 파악해서 이에 맞는 전략적인 대응 방안을 미리 세워야 합니다.

 

또한 시스템 오류 발생 시 전체 데이터베이스를 복원하거나 실행 취소 명령만으로는 실수를 바로 잡을 수 없는 경우 개체를 복원하려면 데이터베이스의 백업 복사본이 필요합니다. 따라서 일부 변경 내용이나 실수는 되돌릴 수 없으므로 데이터 손상이 발생하기 전에 데이터베이스 백업 복사본을 만드는 것이 좋습니다. 이와 함께 데이터베이스가 자주 변경되는 활성 데이터베이스의 경우에는 정기적으로 데이터베이스를 백업하는 일정을 만드는 것이 좋습니다.

 

데이터베이스 백업 복사본이 저장 공간을 낭지하는 것처럼 보일 수 있지만 데이터 및 디자인 손상을 방지함으로써 절약할 수 있는 시간을 생각해 보는 것이 좋습니다. 백업 복사본이 없으면 손상되거나 손실된 개체 또는 데이터베이스 디자인에 대해 변경 내용을 복원할 수 없습니다.