콘텐츠로 이동
≡

Administrator

Developer

Tools

External Tools

11. 증분 백업과 복구#

이 장은 Altibase가 제공하는 증분 백업과 증분 백업을 이용한 복구에 대하여 설명한다.

증분 백업 (Incremental Backup)#

Altibase는 증분 백업 또는 전체 백업으로 유실 또는 손상된 데이터를 복구할 수 있다.

증분 백업이란 마지막으로 증분 백업이 수행된 이후부터 데이터 파일에서 변경된 데이터 페이지만 백업하는 방식을 일컫는다. 증분 백업 방식은 전체 백업 방식과 비교하여 백업의 양이 적다. 따라서 백업에 필요한 디스크 공간이 절감될 뿐만 아니라, 디스크 I/O 양이 적어 백업 성능이 더 높다. Altibase가 제공하는 증분 백업은 서버가 온라인 상태에서 수행 가능하며, 데이터 파일의 페이지를 백업하는 물리적 백업 방식이다.

증분 백업은 레벨 0과 레벨 1로 분류된다. 증분 백업의 종류에 대해서는 다음 절에 설명한다.

기존의 전체 백업은 데이터 파일 전체를 백업하는 방식으로 이에 대한 자세한 설명은 10. 백업 및 복구 장을 참조한다.

증분 백업의 종류#

증분 백업은 레벨 0과 레벨 1로 분류된다. 레벨 0의 증분 백업은 전체 백업과 유사하나 향후 레벨 1의 증분 백업을 수행하기 위해 반드시 해야한다. 레벨 0 증분 백업을 하면, 백업 정보가 backupinfo 파일에 기록되어 이를 기준으로 레벨 1 증분 백업이 가능하다.

  • 레벨 0 증분 백업
  • 레벨 1 증분 백업
    • 차등 증분 백업
    • 누적 증분 백업

레벨 0 증분 백업#

레벨 0(Level 0) 증분 백업은 데이터 파일의 모든 페이지들을 백업한다는 면에서 전체 백업과 동일하다. 그러나 전체 백업이 증분 백업 전략의 한 부분으로 참가할 수 없다. 증분 백업은 전략상 필요에 따라 레벨 0과 레벨 1의 증분 백업을 선택하여 사용할 수 있는데, 이 때 레벨 1의 증분 백업을 하기 위해서는 그 전에 한번은 레벨 0의 증분 백업이 먼저 수행되어야 한다.

아래는 레벨 0 증분 백업과 전체 백업의 차이점을 설명한다.

  • 기존의 전체 백업(온라인 전체 백업)과 동작 방식은 동일하지만, 백업이 이루어진 시점에 대한 정보가 기록된다는 점이 다르다.
  • 데이터베이스의 페이지들이 변경되었다는 것을 판단하기 위한 기준을 만드는 백업이다.

레벨 1 증분 백업#

레벨 1 증분 백업은 이전의 증분 백업 이후로 변경된 페이지만 백업한다. 레벨 1 증분 백업은 변경된 페이지만 백업하므로, 백업 파일의 크기가 작고 백업 수행 시간이 적게 걸린다. 레벨 1 증분 백업에는 차등 증분 백업(differential incremental backup)과 누적 증분 백업(cumulative incremental backup)이 있다.

차등 증분 백업(Differential Incremental Backup)#

가장 최근에 수행된 레벨 0 또는 레벨 1 증분 백업 이후에 변경된 페이지를 백업한다. 차등 증분 백업을 수행하면 Altibase는 가장 최근에 발생한 레벨 1 백업을 찾아서 그 백업 이후에 변경된 모든 페이지를 백업한다.

만약 레벨 1 백업이 없다면, 레벨 0 백업 이후로 변경된 모든 페이지를 백업한다. level 0 백업도 없다면 레벨 1 백업이 불가능하다는 에러가 반환된다.

차등 증분 백업으로 생성되는 백업 파일의 크기는 누적 증분 백업으로 생성되는 백업 파일의 크기보다 작다. 따라서 백업 시간도 더 적게 걸린다. 하지만 차등 증분 백업을 여러 번 수행하여 백업 파일의 수가 많아진다면, 매체 복원(Media Restore)시 백업 파일의 수만큼 복원(restore)해야 하기 때문에 복구 시간이 더 길어질 수 있다.

누적 증분 백업(Cumulative Incremental Backup)#

가장 최근에 수행된 레벨 0 백업 이후에 변경된 페이지를 백업한다.

누적 증분 백업은 레벨 0 백업 이후 시간이 경과할수록 백업 파일의 크기가 커지기 때문에 백업 소요 시간도 더 길어진다.

하지만 누적 증분 백업을 이용하여 매체 복원(Media Restore)을 하는 경우에는 가장 마지막의 레벨 1 백업 파일만 복원하면 되기 때문에, 차등 증분 백업을 이용하는 것보다 복구 시간이 더 짧다.

증분 백업 관련 기능 및 파일#

페이지 변경 추적#

페이지 변경 추적 기능은 각 데이터 파일에서 변경된 페이지를 Altibase가 페이지 변경 추적 파일에 기록함으로써 증분 백업 성능을 향상시킨다.

페이지 변경 추적 기능은 레벨 0 증분 백업 이후 변경된 페이지의 정보를 페이지 변경 추적 파일에 비트맵(bitmap)으로 관리하고, 레벨 1 백업 수행 시 Altibase는 이 비트맵을 확인하여 변경된 페이지만 백업한다.

비트맵의 한 비트(bit)는 한 개 이상의 페이지에 대응한다. 이렇게 한 비트에 대응하는 페이지의 묶음을 증분 청크(Incremental Chunk)라고 한다. 한 묶음에 속해 있는 페이지들 중 한 페이지라도 변경된다면, 그 묶음의 모든 페이지가 백업될 것이다. 증분 청크의 크기는 INCREMENTAL_BACKUP_CHUNK_SIZE 프로퍼티로 조절할 수 있다. 이 프로퍼티에 대한 상세한 설명은 General Reference > 2장. Altibase 프로퍼티를 참고하도록 한다.

추적 기능을 활성화하면 증분 백업을 위해 서버는 변경 추적 파일을 사용해서 변경된 파일을 식별하며, 데이터 파일의 모든 페이지를 조사하지 않는다.

아래의 구문으로 페이지 변경 추적 기능을 활성화할 수 있다.

iSQL(sysdba)> ALTER DATABASE ENABLE INCREMENTAL CHUNK CHANGE TRACKING;

이 구문은 오직 SERVICE 구동 단계에서 sysdba 권한으로 수행이 가능하다. 추적 기능을 활성화하면, $ALTIBASE_HOME/dbs 디렉터리에 변경 추적 파일과 backupinfo 파일이 생성된다.

페이지 변경 추적 기능을 비활성화하려면 아래의 구문을 사용하라.

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

이 구문은 모든 구동 단계에서 sysdba 권한으로 수행이 가능하다. 추적 기능을 비활성화하면, $ALTIBASE_HOME/dbs 디렉터리에서 변경 추적 파일이 삭제된다. bakcupinfo 파일의 삭제는 backupinfo 파일의 설명을 참고한다.

주의: 페이지 변경 추적 기능을 활성화하더라도 실제로는 변경된 페이지를 바로 추적하지 않는다. 변경 페이지 추적은 레벨 0 백업이 수행될 때 시작한다.

changeTracking 파일#

이 파일에는 변경된 페이지의 정보가 비트맵으로 저장된다. 이 파일은 증분 백업을 수행하기 위해 필수적으로 필요하다.

changeTracking 파일은 $ALTIBASE_HOME/dbs 디렉터리에 위치한다.

주의:

  • changeTracking파일이 소실되거나 유효하지 않다면 SYS 사용자가 sysdba 권한으로 changeTracking을 활성화하는 SQL구문을 실행하여 다시 생성해야 한다. changeTracking파일이 재생성 되면 그동안 추적하여 변경된 페이지 정보가 사라진다. 따라서 레벨 0 백업을 먼저 수행한 후 레벨 1 백업을 수행할 수 있게 된다.
  • 추적 기능을 활성화하면 Altibase 서버의 성능이 하락할 수 있다. 이 경우 추적 기능을 비활성화하면 서버의 성능은 회복할 수 있지만, 증분 백업 기능은 사용할 수 없다.

backupinfo 파일#

이 파일은 증분 백업 수행에 대한 정보를 저장한다. 한 번의 증분 백업 수행에 대해 증분 백업 레벨, 백업 종류, 백업 태그 이름, 백업 시작 일시, 백업 완료 일시, 및 백업 파일의 위치가 증분 백업 수행 시간 순서대로 backupinfo 파일에 저장된다. backupinfo 파일은 $ALTIBASE_HOME/dbs 디렉터리에 위치한다.

backupinfo 파일은 매체 복원(Media Restore) 시에 복원해야 할 백업 파일의 순서를 파악할 수 있는 정보를 제공한다. 만약 backupinfo 파일이 존재하지 않으면, 백업 파일이 존재하더라도 복구가 불가능하다.

주의:

backupinfo 파일에는 증분 백업이 수행된 일시 순으로 백업정보가 저장되어 있다. 그런데, backupinfo 파일과 백업 파일의 정보가 일치하지 않는 경우는 사용이 불가능하다. 백업 파일의 일부가 소실되어 증분 백업이 무효화 되거나, 필요 없어진 경우는 아래의 구문으로 backupinfo 파일을 삭제할 수 있다.

backupinfo 파일의 삭제#

아래의 구문은 sysdba 권한으로 Process 단계에서 수행할 수 있다.

iSQL(sysdba)> ALTER DATABASE REMOVE BACKUP INFO FILE;

증분 백업 예제#

데이터베이스와 테이블스페이스 단위로 레벨 0 증분 백업과 레벨 1 증분 백업을 수행하는 예제이다.

백업 경로 설정#

증분 백업 파일들은 Altibase 서버에 의해 관리된다. 따라서 아래의 구문으로 증분 백업 파일이 저장될 위치를 지정해야 한다.

iSQL(sysdba)> ALTER DATABASE CHANGE BACKUP DIRECTORY '/backup_dir';

주의: 변경 추적 기능이 활성화 되어 있는 상태에서만 이 구문을 수행할 수 있다.

레벨 0 백업#

위에서 설명한 바와 같이 레벨 0 증분 백업은 전체 백업과 동일하다. 단, 레벨 0 증분 백업을 수행하면 backupinfo 파일에 백업 정보가 기록된다. 또한 증분 백업의 기준 파일이 되는 레벨 0 백업 파일을 전체 백업 파일로 대체할 수 없다.

데이터베이스 단위 증분 백업#

백업 태그를 지정하지 않고 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE;

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_20121030_214906

$ ls /backup_dir/TAG_20121030_214906
SYS_TBS_MEM_DATA-0-0_TAG_20121030_214906.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_20121030_214906.ibak
SYS_TBS_MEM_DIC-0-0_TAG_20121030_214906.ibak
undo001.dbf_TAG_20121030_214906.ibak

백업 태그를 지정하여 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'MONDAY';

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_MONDAY

$ ls /backup_dir/TAG_MONDAY
SYS_TBS_MEM_DATA-0-0_TAG_MONDAY.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_MONDAY.ibak
SYS_TBS_MEM_DIC-0-0_TAG_MONDAY.ibak
undo001.dbf_TAG_MONDAY.ibak

테이블스페이스 단위 증분 백업#

백업 태그를 지정하지 않고 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 TABLESPACE SYS_TBS_MEM_DIC;

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_20121031_040537

$ ls backup_dir/TAG_20121031_040537
SYS_TBS_MEM_DIC-0-0_TAG_20121031_040537.ibak
backupinfo

백업 태그를 지정하여 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 TABLESPACE SYS_TBS_MEM_DIC WITH TAG 'MONDAY';

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_MONDAY

$ ls backup_dir/TAG_MONDAY
SYS_TBS_MEM_DIC-0-0_TAG_MONDAY.ibak
backupinfo

레벨 1 백업#

주의: 레벨 1 증분 백업은 이전에 레벨 0 증분 백업이 한 번이라도 수행되었어야 가능하다.

데이터베이스 단위 증분 백업#

차등 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE;

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_20121031_043507

$ ls /backup_dir/TAG_20121031_043507
SYS_TBS_MEM_DATA-0-0_TAG_20121031_043507.ibak
backupinfo
loganchor1
loganchor0
loganchor2
system001.dbf_TAG_20121031_043507.ibak
SYS_TBS_MEM_DIC-0-0_TAG_20121031_043507.ibak
undo001.dbf_TAG_20121031_043507.ibak

누적 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE;

누적 증분 백업으로 생성되는 파일들은 차등 증분 백업으로 생성되는 파일들과 이름에는 차이가 없다. 단, 파일 내의 내용이 다르다.

백업 태그를 지정하여 레벨 1 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'TUESDAY';

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_TUESDAY

$ ls /backup_dir/TAG_TUESDAY
SYS_TBS_MEM_DATA-0-0_TAG_TUESDAY.ibak
SYS_TBS_MEM_DIC-0-0_TAG_TUESDAY.ibak
backupinfo
loganchor0
loganchor1
loganchor2
system001.dbf_TAG_TUESDAY.ibak
undo001.dbf_TAG_TUESDAY.ibak

테이블스페이스 단위 증분 백업#

차등 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYS_TBS_MEM_DIC;

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_20121031_211432

$ ls /backup_dir/TAG_20121031_211432
SYS_TBS_MEM_DIC-0-0_TAG_20121031_211432.ibak
backupinfo

누적 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE TABLESPACE SYS_TBS_MEM_DIC;

누적 증분 백업으로 생성되는 파일들은 차등 증분 백업으로 생성되는 파일들과 이름에는 차이가 없다.

백업 태그를 지정하여 레벨 1 증분 백업하는 구문의 예제이다.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYS_TBS_MEM_DIC WITH TAG 'WEDNESDAY';

백업을 수행한 후 백업 경로에서 파일들을 확인한 결과이다.

$ ls /backup_dir
TAG_WEDNESDAY

$ ls /backup_dir/TAG_WEDNESDAY
SYS_TBS_MEM_DIC-0-0_TAG_WEDNESDAY.ibak
backupinfo

증분 백업에 대한 매체 복구#

이 절은 증분 백업 파일을 이용한 매체 복원 및 매체 복구에 대해서 설명한다.

매체 복원 및 복구#

증분 백업 파일을 이용한 매체 복원 및 매체 복구의 수행은 Altibase의 CONTROL 구동 단계에서 이루어질 수 있다.

매체 복원 (Media Restore)#

매체(Media)에 장애가 발생하여 데이터베이스 파일이 소실된 경우 백업 파일을 복사해서 소실된 파일을 대체하는 것을 복원이라고 한다.

전체 백업 파일을 이용한 매체 복원의 경우, 관리자가 복사 명령어(cp 등)를 사용해서 소실된 데이터 파일을 복원할 수 있다. 하지만 증분 백업에 대한 매체 복원의 경우, 아래의 SQL 구문을 사용해서 소실된 데이터 파일을 복원할 수 있다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

매체 복구 (Media Recovery)#

백업 파일로 복원된 데이터 파일에 아카이브 로그를 적용하는 것을 복구라고 한다. 증분 백업에 대한 복구는 아래의 SQL 구문으로 수행할 수 있으며, 이는 전체 백업에 대한 복구 방법과 동일하다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

주의: 증분 백업 파일을 이용한 매체 복원이 완료되면 이후에는 기존 온라인 전체 백업 파일을 이용한 매체 복구와 동일한 방법으로 매체 복구를 수행할 수 있고 복구 동작도 동일하다.

증분 백업에 대한 복구 절차#

이 절은 증분 백업을 이용한 데이터베이스 복구 절차를 개략적으로 살펴본다. 먼저 changeTracking 파일과 backupinfo 파일의 복원 방법을 살펴본 후, 데이터베이스 복구 방법을 설명한다.

매체(Media)에 장애가 발생하여 $ALTIBASE_HOME/dbs 디렉터리에 changeTracking 파일 또는 backupinfo 파일이 소실되면, 서버를 CONTROL 구동 단계로 시작할 수 없다. 이 경우 서버를 PROCESS 구동 단계로 시작하여 changeTracking 파일과 backupinfo 파일에 대해 다음과 같은 작업을 수행해야 한다.

changeTracking 파일#

이 파일은 매체 복원에는 필요하지 않다. 따라서 아래의 구문을 실행하여 서버가 더 이상 changeTracking 파일을 검사하지 않도록 해야 한다.

iSQL(sysdb)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

backupinfo파일#

이 파일은 매체 복원에 반드시 필요하다. backupinfo 파일은 증분 백업을 수행할 때 자동으로 백업된다. 따라서 가장 최근에 수행된 증분 백업 경로에서 copy 명령어를 이용하여 backupinfo 파일을 복원하도록 한다.

$ cp /backup_dir/BACKUP_TAG/backupinfo $ALTIBASE_HOME/dbs

앞의 장에서 설명한 바와 같이 전체 백업에 대해서는 아래 두 가지 불완전 복구(Incomplete recovery) 방법를 지원한다.

특정 시점으로 불완전 복구:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL TIME '2012-10-31:17:55:00';

유효한 로그가 존재하는 지점까지 불완전 복구:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

증분 백업에 대해서는 위의 두 가지 방법과 함께 추가로 백업 태그 이름을 이용한 불완전 복원 및 복구를 지원한다.

백업 태그 이름을 이용한 불완전 복원:#

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';

백업 태그 이름을 이용한 불완전 복구:#

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE FROM TAG 'TUESDAY';

증분 백업을 사용하여 매체 복원을 할 때에는 로그 파일이 사용되지 않기 때문에 ALTER DATABASE RESTORE DATABASE UNTIL CANCEL 구문이 지원되지 않는다(UNTIL TIME은 가능).

백업 태그 이름을 이용한 불완전 복원 후 복구 시에는 복원과 복구에 사용되는 백업 태그 이름이 동일해야 한다. 아래와 같이 복원과 복구에 서로 다른 백업 태그 이름을 사용하면 복구에 실패할 것이다. 성공적인 복구를 위해서는 'SUNDAY'가 아닌 'TUESDAY'를 사용해야 한다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';
iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE FROM TAG 'SUNDAY';

만약 TUESDAY라는 백업 태그를 이용해 복원하고 그 이후 시점으로 불완전 복구를 하고 싶다면 아래와 같이 UNTIL TIME 혹은 UNTIL CANCEL구문을 사용하면 된다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'TUESDAY';
iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

매체 복원 예제#

매체 복원 및 복구의 예를 들기 위해, 아래와 같이 증분 백업을 했다고 가정하자.

iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'MONDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'TUESDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'WEDNESDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 0 DATABASE WITH TAG 'THURSDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'FRIDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE WITH TAG 'SATURDAY';
iSQL(sysdba)> ALTER DATABASE BACKUP INCREMENTAL LEVEL 1 DATABASE WITH TAG 'SUNDAY';

완전 복원#

아래의 구문을 사용하여 완전 복원을 수행할 수 있다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

이 구문을 실행하면, 먼저 증분 백업 중에 가장 최근의 레벨 0 증분 백업(태그 이름 THURSDAY)으로 복원된다. 그런 다음 레벨 1 누적 증분 백업(태그 이름 SATURDAY)으로 복원되고, 마지막으로 레벨 1 차등 증분 백업(태그 이름 SUNDAY)으로 복원된다.

불완전 복원#

백업 태그 이름 'WEDNESDAY'까지 불완전 복원#

아래의 구문을 사용하여 백업 태그 이름 'WEDNESDAY'까지 불완전 복원을 수행할 수 있다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

이 구문을 실행하면, 백업 태그 이름 'WEDNESDAY' 이전에 수행된 레벨 0 증분 백업 중 가장 가까운 시점의 백업인 태그 이름 'MONDAY'로 복원된다. 그리고 레벨 1 차등 증분 백업인 태그 이름 'TUESDAY'와 'WEDNESDAY'로 복원된다.

백업 태그 이름 'SATURDAY'까지 불완전 복원#

아래의 구문을 사용하여 백업 태그 이름 'SATURDAY'까지 불완전 복원을 수행할 수 있다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'SATURDAY';

이 구문을 실행하면, 백업 태그 이름 'SATURDAY'이전에 수행된 레벨 0 증분 백업 중 가장 가까운 시점의 백업인 태그 이름 'THURSDAY'로 복원된다. 그런 다음, 레벨 1 누적 증분 백업인 태그 이름 'SATURDAY'로 복원된다.

매체 복구 예제#

완전 복구#

완전 복원 후 완전 복구#

아래의 구문을 사용하여 가장 최근의 백업인 백업 태그 'SUNDAY'로부터 데이터 파일을 복원한다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

매체 복구를 이용하여 최근 시점까지 아카이브 로그를 적용한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

시스템 임시 테이블스페이스 SYS_TBS_DISK_TEMP를 위한 파일은 백업이 되지 않기 때문에, 수동으로 파일을 생성한 다음 서버를 시작한다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> STARTUP SERVICE;

불완전 복원 후 완전 복구#

아래의 구문을 사용하여 백업 태그 이름 'WEDNESDAY'로부터 불완전 복원을 수행한다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

매체 복구를 통해 백업 태그 이름 'WEDNESDAY'부터 최근 시점까지 아카이브 로그를 적용한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE;

시스템 임시 테이블스페이스 SYS_TBS_DISK_TEMP를 위한 파일은 백업이 되지 않기 때문에, 수동으로 파일을 생성한 다음 서버를 시작한다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> STARTUP SERVICE;

불완전 복원 후 완전 복구 방법은 증분 백업 파일이 소실된 경우에 사용할 수 있는 복구 방법이다. 이 때는 소실된 증분 백업 파일 이전의 백업 파일로 복원한 다음, 아카이브 로그를 이용해 완전 복구를 수행하면 된다.

불완전 복구#

완전 복원 후 불완전 복구#

불완전 복구를 위해서는 과거의 loganchor 파일과 backupinfo 파일이 필요하다. loganchor 파일과 backupinfo 파일을 이용해서 과거 시점으로 불완전 복구를 수행하고, ALTER DATABASE MYDB META RESETLOGS구문으로 로그를 리셋하게 되면, 복구 전의 최신 backupinfo 파일에는 존재하지만 과거로 복원된 backupinfo 파일에는 존재하지 않는 백업 정보에 대응하는 백업 파일들은 더 이상 사용할 수 없게 된다.

아래와 같이 불완전 복구를 원하는 과거 시점의 loganchor 파일과 backupinfo 파일을 사용해서 loganchor와 backupinfo를 복원한다.

$ cp /backup_dir/TAG_WEDNESDAY/ loganchor* $ALTIBASE_HOME/logs
$ cp /backup_dir/TAG_WEDNESDAY/ backupinfo $ALTIBASE_HOME/dbs

loganchor 파일을 과거 버전으로 복원했기 때문에 changeTracking 파일이 더 이상 유효하지 않게 된다. 따라서 아래의 구문으로 서버의 PROCESS 구동 단계에서 변경 추적 기능을 비활성화해서 changeTracking 파일을 삭제하도록 한다.

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

아래의 구문은 가장 최근에 백업된 백업 태그 이름 'SUNDAY'로부터 데이터파일을 복원한다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE;

데이터베이스를 복원한 후, 아카이브로그를 이용해서 불완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

시스템 임시 테이블스페이스 SYS_TBS_DISK_TEMP를 위한 파일은 백업이 되지 않기 때문에, 수동으로 파일을 생성한 다음 resetlogs를 수행하고 서버를 시작한다.

iSQL(sysdba)> ALTER DATABASE CREATE DATAFILE 'temp001.dbf';
iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS;
iSQL(sysdba)> STARTUP SERVICE;

불완전 복원 후 불완전 복구#

아래와 같이 불완전 복구를 원하는 과거 시점의 loganchor 파일과 backupinfo 파일을 사용해서 loganchor와 backupinfo를 복원한다.

$ cp /backup_dir/TAG_WEDNESDAY/ loganchor* $ALTIBASE_HOME/logs
$ cp /backup_dir/TAG_WEDNESDAY/ backupinfo $ALTIBASE_HOME/dbs

loganchor 파일을 과거 버전으로 복원했기 때문에 changeTracking 파일이 더 이상 유효하지 않게 된다. 따라서 아래의 구문으로 서버의 PROCESS 구동 단계에서 변경 추적 기능을 비활성화해서 changeTracking 파일을 삭제하도록 한다.

iSQL(sysdba)> ALTER DATABASE DISABLE INCREMENTAL CHUNK CHANGE TRACKING;

아래의 구문을 사용해서 불완전 복구를 원하는 시점 바로 이전에 수행된 증분 백업으로부터 데이터 파일을 복원한다.

iSQL(sysdba)> ALTER DATABASE RESTORE DATABASE FROM TAG 'WEDNESDAY';

불완전 복원 후, 불완전 복구를 수행한다.

iSQL(sysdba)> ALTER DATABASE RECOVER DATABASE UNTIL CANCEL;

resetlogs를 수행하고 서버를 시작한다.

iSQL(sysdba)> ALTER DATABASE MYDB META RESETLOGS;
iSQL(sysdba)> STARTUP SERVICE;

백업 파일 관리#

전체 백업과 달리 증분 백업 수행으로 생성된 백업 파일들의 관리는 DBA가 아닌 Altibase 서버에 의해 이루어진다.

백업 경로 지정/변경#

증분 백업 수행으로 생성되는 백업 파일들의 위치는 아래의 구문으로 지정할 수 있다. 백업 수행 전에 반드시 백업 경로를 지정해야 한다.

iSQL(sysdba)> ALTER DATABASE CHANGE BACKUP DIRECTORY '/backup_dir';

만약 처음에 지정한 경로에 디스크 공간이 부족하면, 위의 구문을 사용하여 새로운 백업 경로로 변경할 수 있다.

백업 파일을 이동하는데 시간이 오래 걸리거나, 생성되는 백업 파일들의 크기가 하나의 백업 디바이스에 유지할 수 없는 상황일 때에는 디스크 공간 관리를 위해 백업 경로를 변경하는 방법이 적합하다.

백업 파일 이동#

백업 경로의 디스크 공간이 부족한 경우, 백업 파일들을 다른 디바이스의 경로로 이동할 수 있다. 아래의 두 가지 이동 방법이 있다.

  1. SQL 구문으로 backupinfo 파일 내에서 백업 파일 경로만 변경하고, 기존 백업 파일은 관리자가 복사 명령(cp)을 사용해서 수동으로 이동하는 방법

    iSQL(sysdba)> ALTER DATABASE MOVE BACKUP FILE TO '/backup_dir2';

    $ cp ... /backup_dir2

  2. SQL 구문으로 backupinfo 파일 내의 백업 파일 경로 변경과 백업 파일의 이동을 동시에 수행하는 방법

    iSQL(sysdba)> ALTER DATABASE MOVE BACKUP FILE TO '/backup_dir2' WITH CONTENTS;

백업 파일 삭제#

아래의 구문을 사용해서 유효 기간이 지난 백업 파일을 삭제하여 디스크의 여유 공간을 확보할 수 있다.

iSQL(sysdba)> ALTER DATABASE DELETE OBSOLETE BACKUP FILES;

이 구문을 수행하면 V$OBSOLETE_BACKUP_INFO 성능 뷰에 나타나는 백업 파일들만 삭제된다. V$OBSOLETE_BACKUP_INFO 성능 뷰에서 아무 것도 조회되지 않는다면 삭제되는 파일이 없을 것이다.