1.1 백업의 개요 및 목적
데이터베이스 백업이란, 시스템 장애 발생 시 이를 복구하기 위한 일종의 “보험”과 같은 개념입니다. 관계형 데이터베이스를 사용하는 가장 큰 장점 중 하나는 데이터베이스에 이상이 발생했을 때 언제든지 데이터베이스 복구를 수행하여 현재 상황으로 복구할 수 있다는 점입니다. 이러한 복구가 가능하기 위해서는 데이터베이스 관리자가 복구 가능한 상태로 데이터베이스를 운영해야 합니다. 예를 들어 사용자가 NO ARCHIVE MODE로 운영할 경우, 데이터베이스를 처음 생성한 시점이나 전체 백업을 받은 시점으로만 복구가 가능하기 때문입니다.
일반적으로 백업 정책 없이 과도한 양의 백업을 받으면 일정 기간이 경과하면 백업의 의미가 희미해지고, 정상적인 작업을 수행하지 못할 때 백업 파일이 필요할 경우 작업을 수행할 수 없는 상황이 발생할 수 있습니다.
데이터베이스 관리자는 백업 정책을 수립하여 꼭 필요한 데이터를 최소한의 양으로 백업을 받고 최소의 시간을 소비하면서도 항시 복구 가능한 상태를 유지해야 합니다. 이는 고객의 MTTR(MEAN TIME TO RECOVERY)을 만족하는 시간을 목표로 해야 합니다.
1.2 주요 고려사항
데이터베이스는 기존의 파일 시스템과 달리 전체 사용자 OBJECT를 하나의 TABLESPACE로 관리하거나 필요에 따라 나누어 사용 및 관리하므로 백업뿐 아니라 복구 시에도 상당한 주의가 필요합니다. 만일 ARCHIVE LOG 상태에서 이상이 발생할 경우, 복구 작업에 필요한 LOG FILE 중 하나라도 없어지거나 사용할 수 없으면 정상적인 복구가 불가능합니다.
이러한 불행한 경우를 방지하기 위해 DBA는 항상 복구가 가능한 상태로 작업하기 위한 백업 정책을 수립하여 정확하게 작업해야 합니다.
또한, 24시간 365일 DOWN TIME 없이 운영되는 시스템의 경우, COLD BACKUP과 같은 FULL IMAGE 백업이 불가능할 수 있으므로 HOT BACKUP 또는 EXPORT를 통한 LOGICAL 백업만이 가능할 수 있습니다. 이러한 제약으로 인해 발생할 수 있는 장애에 적절히 대응하지 못할 수 있습니다.
이러한 상황을 파악하여 백업 정책 수립에 심혈을 기울여야 하며, 시스템 운영의 묘를 살려야 할 것입니다. 또한 HOT BACKUP 등의 ONLINE 상태에서 데이터베이스를 백업하기 위해서는 반드시 ARCHIVE MODE로 운영되어야 합니다.
1.3 백업 전략
DBA가 어떤 방법으로 백업을 유지하느냐에 따라 복구 성공률이나 복구 속도 등이 결정됩니다. 물론 매일 작업 종료 후 전체 데이터베이스를 FULL BACKUP한다면 가장 안전한 백업이지만, 많은 시간이 요구되므로 현실적으로 불가능한 작업입니다.
예: XXX 시스템의 특징은 24시간 365일 무중단 운영을 원칙으로 하며, 타 시스템과의 INTERFACE 대상의 DATA LOAD가 야간에 대량으로 발생하고, 정산 및 온라인 통계 작업을 통한 대량의 TRANSACTION이 발생합니다. 이는 COLD BACKUP을 위한 시스템 중단이 사실상 불가능하다는 의미입니다.
이러한 시스템의 특성을 반영한 백업 시스템 정책은 HOT BACKUP을 업무가 집중되지 않는 시간에 수행하는 것으로 정해야 하며, 단위 업무별로 대량의 변화가 발생할 경우 데이터의 수정, 삭제, 변화가 발생하기 전에 각 단위 팀의 별도 APPLICATION을 통해 데이터 BACKUP을 수행해야 합니다.
가. 업무 수행에 지장을 받지 않는 시간대에 HOT BACKUP을 수행합니다. 나. 업무 변화가 대량으로 발생하기 전에 APPLICATION을 통한 BACKUP을 수행합니다. 다. 자주 read-write되는 tablespace는 자주 online backup을 수행합니다. 라. 데이터베이스에 구조적인 변화가 생기기 전후로 full backup을 수행합니다. 마. 이전의 backup본을 최소한 2본 이상 가지고 있을 필요가 있습니다. 바. 특정 테이블들의 data 입력 오류로 인해 과거 특정 시점으로 회귀하거나, 특정 테이블 데이터의 분실로 다시 복귀를 해야 할 경우를 대비하여 Logical Backup인 Export를 수시로 받아놓도록 합니다. 사. Unrecoverable로 생성된 Object는 redo log file에 logging되지 않기에 이러한 Object들은 Export Utility를 사용하여 Backup하도록 하며, 초기 생성 후 정상적인 데이터 입력/수정이 이루어지면 logging으로 변경하도록 합니다.
1.4 백업 방법
1.4.1 Physical Backup
물리적인 데이터베이스 파일을 한 위치에서 다른 위치로 복제하는 것을 Physical Backup이라 합니다. 또한 Physical Backup은 Offline, Online Backup(Without Archiving / With Archiving)으로 나눌 수 있습니다. 즉, 데이터베이스 상태가 Down인 상황에서 백업을 수행하면 Offline Backup이며, 이 백업은 Archive Log 파일의 백업은 불필요합니다. 데이터베이스가 Online인 상황에서 백업을 수행하는 Online Backup인 경우에는 백업 중에도 Transaction이 발생할 수 있으며, 이 기간 중에 발생한 데이터를 보존하기 위해 Archive Log를 반드시 백업해야 합니다.
1.4.1.1 Cold Backup (Offline Backup)
데이터베이스를 Shutdown한 이후 아래와 같은 파일들을 백업 Library로 복사해야 합니다.
가. DataFiles (V$datafile 확인 자료) 나. Redo Log Files (V$logfile 확인 자료) 다. Control Files (V$controlfile 확인 자료) 라. Parameter Files(initSID.ora, spfileSID, configSID.ora 등)
1.4.1.2 HOT Backup(Online Backup)
데이터베이스가 구동 중인 상태에서 datafile을 복사하는 방식으로 Archive Log Mode로 운영되어야 합니다.
SQL> ALTER TABLESPACE …… BEGIN BACKUP; $ *.DBF의 COPY 수행 SQL> ALTER TABLESPACE ….. END BACKUP;
이 명령을 수행하는 동안 해당 TABLESPACE가 HOTBACKUP MODE로 운영 중이어서 해당 TABLESPACE 안의 TABLE에 대한 DML이 발생할 경우 DATAFILE WRITE가 불가능하기 때문에 REDO LOG에만 기록하게 됩니다. 백업이 완료된 시점에서 LOG에 저장된 변경 사항을 다시 Data file에 기록하기 위해 부하가 발생할 수 있습니다. 그러므로 ONLINE HOT BACKUP을 수행하는 시간은 작업량이 적고, 사용자의 접근을 최소화할 수 있는 시간을 선정해야 하며, 최소한의 시간에 HOT BACKUP을 수행할 수 있어야 합니다.
또한, 백업의 시작과 끝에는 HOT BACKUP 시작 전까지 발생한 TRANSACTION의 REDO LOG를 변경하도록 하여 ARCHIVING하도록 합니다. 또한, 백업이 종료한 후에도 LOG 변경을 하여 백업 중에 발생한 데이터에 대한 REDO LOG 변경분을 DATAFILE에 기록하고 ARCHIVING을 통해 ARCHIVE FILE 백업을 동시에 수행할 수 있도록 해야 합니다.
SQL> ALTER SYSTEM ARCHIVE LOG CURRENTS;
1.4.2 Logical Backup
Export Utility를 이용한 데이터 백업은 보통 DML 발생 빈도가 높아 데이터블록의 활용도나 Capacity를 높이지 못할 경우 데이터블록을 최적화하기 위해 사용할 수 있으며, 사용자의 실수 혹은 구조상의 문제로 인한 데이터 손실을 최소화하기 위해 데이터 보존을 목적으로 사용하는 방법입니다. Export Utility를 이용한 데이터 백업 방법은 Full, User, Table 단위의 Export Mode가 있습니다.
1.4.3 Archive Log File의 Backup
1.4.3.1 Archive Log Mode 구조
오라클에서 Online Backup을 받거나 완벽한 복구 작업을 수행하기 위해서는 데이터베이스를 “Archive Log Mode”로 운영해야 합니다.
오라클의 log File 기록 방법은 “순환” 기록 방법을 채택하고 있습니다. 첫 번째 log File을 기입하고 나면 두 번째 것을 기입하고, 그것이 끝나면 세 번째 log를 기록합니다. 그리고 마지막 Online Redo Log File을 쓰고 나면 Log Writer(LGWR)가 첫 번째 Log File을 다시 선택하여 덮어쓰기를 시작합니다.
Oracle Archive Log Mode에서 작동할 때 ARCH(Archive Background Process)는 각각의 Redo Log File을 덮어쓰기 전에 그에 대한 복사본을 지정된 디렉토리에 만듭니다.
CheckPoint가 발생할 때까지는 Redo Log File은 재사용되지 않으며 ARCH에 의해 물리적으로 Redo Log File은 다시 백업됩니다.
1.4.3.2 Archive Mode와 No-Archive Mode의 비교
위 그림에서 보는 바와 같이 Redo Log가 덮어쓰이기 시작하고 Archive Mode가 아니면 Media Recovery는 마지막으로 Full Backup받은 시점으로 밖에 복구가 불가능합니다. 반면에 Archive Mode로 운영되는 데이터베이스는 가장 나중의 변화까지도 복구가 가능합니다. Archive Log Mode로 운영 시 log_archive_dest Directory 밑에 Archive File이 계속 발생하여 할당된 Space가 부족할 경우 log Change가 발생하지 않아 데이터베이스가 Hang-Up 될 수 있으므로 Space 관리를 유의해야 합니다.
1.4.3.3 Archive Log의 백업
데이터베이스 백업 주기 결정 시 archive log의 백업 주기도 결정되어야 합니다.
Archive log는 O/S Backup을 통해 보관하고, Archive Log가 너무 많이 발생하지 않도록 Archive Log의 Size, 즉 Redo Log의 사이즈를 적절히 조절하여야 복구를 위한 필요 시간을 줄일 수 있습니다.
Archive Log는 데이터베이스 백업 수행과는 별도로 Space의 여유분을 체크하여 일정 수치 이상 Free Space가 부족할 경우 자동으로 Copy한 다음 삭제하도록 스케줄링해야 합니다.
1.5 백업 주기
1.5.1 백업 주기의 결정
백업의 주기 및 백업 시기, 시간은 어떤 백업 방법을 적용할 것인가와 어느 정도의 Down Time을 허용할 것인가에 따라 결정됩니다.
즉, Hot Backup만을 허용하는 사이트에는 Transaction 양이 최소화되는 시간을 선택하여 백업을 수행할 것이며, 시스템을 사용할 수 없는 최대한의 시간을 13시간으로 선정했다면 복구를 위해 주어진 시간이 13시간으로 판단되어 이에 맞는 백업 주기가 결정됩니다.
전체 시스템을 모두 백업하는 데 걸리는 시간을 산정해야 합니다. 예를 들어 전체 시스템을 Hot Backup하는 데 최대 3시간이 걸린다면 이를 3일 주기로 전체 시스템을 백업할 수 있도록 나눈다면 하루에 백업에 소요되는 시간은 대략 1시간이 됩니다.
그러나 3일 주기로 백업의 한 사이클이 종료되므로 월요일에 백업한 테이블스페이스에 속한 데이터파일에 문제가 생긴 시기가 수요일 오후라면 약 이틀간 발생한 Archive Log를 이용하여 복구를 해야 합니다. DataFile, Archive Log Restore 및 복구를 마치는 데 주어진 Down Time 안에 해결할 수 있는지 판단해야 합니다.
일반적으로 백업 주기는 1년, 1분기, 1월, 1일 단위로 두고 주기 및 방법을 정합니다. 또한 백업 주기뿐 아니라 백업한 Media의 보관 주기 또한 백업 및 복구에 큰 영향을 미치는 요소입니다.
1.5.2 백업 주기별 대상 결정
백업 주기(일 단위, 주 단위, 월 단위, 분기 단위, 년 단위, 기타)별로 백업 대상을 선정하여 백업 매체를 선정하고, 백업 대상을 LIST-UP한 다음 백업하도록 합니다.
1.5.2.1 백업 주기
