Open Source RDBMS - Seamless, Scalable, Stable and Free

한국어 | Login |Register

Versions available for this page: CUBRID 8.2.1 |  CUBRID 8.3.0 |  CUBRID 8.3.1 |  CUBRID 8.4.0 |  CUBRID 8.4.1 |  CUBRID 8.4.3 |  CUBRID 9.0.0 | 

백업 정책 및 방식

백업을 진행할 때 고려해야 할 사항은 다음과 같다.

  • 백업할 대상 데이터 선별
    • 보존 가치가 있는 유효한 데이터인지 판단한다.
    • 데이터베이스 전체를 백업할 것인지, 일부만 백업할 것인지 결정한다.
    • 데이터베이스와 함께 백업해야 할 다른 파일이 있는지 확인한다.
  • 백업 방식 결정
    • 증분 백업, 온라인 백업 방식을 결정한다. 부가적으로 압축 백업, 병렬 백업 모드 사용 여부를 결정한다.
    • 사용 가능한 백업 도구 및 백업 장비를 준비한다.
  • 백업 시기 판단
    • 데이터베이스 사용이 가장 적은 시간을 파악한다.
    • 보관 로그의 양을 파악한다.
    • 백업할 데이터베이스를 이용하는 클라이언트 수를 파악한다.
온라인 백업

온라인 백업(또는 핫 백업)은 운영 중인 데이터베이스에 대해 백업을 수행하는 방식으로, 특정 시점의 데이터베이스 이미지의 스냅샷을 제공한다. 운영 중인 데이터베이스를 대상으로 백업을 수행하기 때문에 커밋되지 않은 데이터가 저장될 우려가 있고, 다른 데이터베이스 운영에도 영향을 줄 수 있다.

온라인 백업을 하려면 cubrid backupdb -C 명령어를 사용한다.

오프라인 백업

오프라인 백업(또는 콜드 백업)은 정지 상태인 데이터베이스에 대해 백업을 수행하는 방식으로 특정 시점의 데이터베이스 이미지의 스냅샷을 제공한다.

오프라인 백업을 하려면 cubrid backupdb -S 명령어를 사용한다.

증분 백업

증분 백업(incremental backup)은 전체 백업에 종속적으로 수행되는 백업으로 이전에 수행된 백업 이후의 변경된 사항만을 선택적으로 백업하는 방식이다. 이는 전체 백업보다 백업 볼륨이 적고, 백업 소요 시간이 짧다는 장점이 있다. CUBRID는 0, 1, 2의 백업 수준을 제공하며, 낮은 백업 수준으로 백업을 수행한 이후에만 순차적으로 다음 수준의 백업을 수행할 수 있다.

증분 백업을 하려면 cubrid backupdb -l <level> 명령어를 사용한다.

다음은 증분 백업에 관한 예시로서, 이를 참조하여 백업 수준에 관해 상세하게 살펴보기로 한다.

incrementalbackup.png 

  • 전체 백업(백업 수준 0) : 백업 수준 0은 모든 데이터베이스 페이지를 포함하는 전체 백업이다.
  • 데이터베이스에 최초 시도되는 백업 수준은 당연히 수준 0이 된다. DBA는 복구 상황을 대비하여 정기적으로 전체 백업을 수행하여야 하며, 예시에서는 12월 31일과 1월 5일에 전체 백업을 수행하였다.
  • 1차 증분 백업(백업 수준 1) : 백업 수준 1은 수준 0의 전체 백업 이후의 변경 사항만 저장하는 증분 백업으로서, 이를 "1차 증분 백업"이라 한다.
  • 주의할 점은 예시의 <1-1>, <1-2>, <1-3>과 같이 1차 증분 백업이 연속적으로 시도되더라도 언제나 수준 0의 전체 백업을 기본으로 증분 백업을 수행한다는 점이다.
  • 만약, 동일 디렉터리에서 백업 파일이 생성된다고 할 때, 1월 1일에 이미 1차 증분 백업 <1-1>이 수행되고, 1월 2일에 또다시 1차 증분 백업 <1-2>가 시도되면, <1-1>에서 생성된 증분 백업 파일을 덮어쓰게 된다. 1월 3일에 1차 증분 백업이 다시 수행되었으므로, 최종 증분 파일은 이 때 생성된다.
  • 그러나, 1월 1일이나 1월 2일의 상태로 데이터베이스를 복구하여야 하는 상황이 발생될 수 있으므로, DBA는 최종 증분 파일로 덮어쓰기 전에 <1-1>과 <1-2> 각각의 증분 백업 파일을 저장 매체에 별도로 보관하는 것이 좋다.
  • 2차 증분 백업(백업 수준 2) : 백업 수준 2는 1차 증분 백업 이후의 변경 사항만 저장하는 증분 백업으로 이를 "2차 증분 백업"이라 한다.
  • 1차 증분 백업이 선행되어야만 2차 증분 백업을 수행할 수 있으므로, 1월 4일에 시도한 2차 증분 백업 시도는 성공할 것이고, 1월 6일에 시도한 2차 증분 백업 시도는 당연히 허용되지 않을 것이다.
  • 이러한 백업 수준 0, 1, 2로 생성된 백업 파일들은 모두 데이터베이스를 복구할 때 필요하므로, 2차 증분 백업이 완료된 1월 4일의 상태로 데이터베이스를 복구하기 위해서는 <2-1>에서 생성된 2차 증분 백업 파일, <1-3>에서 생성된 1차 증분 백업 파일, <0-1>에서 생성된 전체 백업 파일이 모두 필요하다. 즉, 완전한 복구를 위해서는 직전에 생성된 증분 백업 파일로부터 이전 최종으로 생성된 전체 백업 파일이 요구된다.
압축 백업 모드

압축 백업(compress backup)은 데이터베이스를 압축하여 백업을 수행하기 때문에 백업 볼륨의 크기가 줄어들어 디스크 I/O 비용을 감소시킬 수 있고, 디스크 공간을 절약할 수 있다.

압축 백업을 하려면 cubrid backupdb -z|--compress 명령어를 사용한다.

병렬 백업 모드

병렬 백업 또는 다중 백업(multi-thread backup)은 지정된 스레드 개수만큼 동시 백업을 수행하기 때문에 백업 시간을 크게 단축시켜 준다. 기본적으로 시스템의 CPU 수만큼 스레드를 부여하게 된다.

병렬 백업을 하려면 cubrid backupdb -t|--thread-count 명령어를 사용한다.