ENTERPRIZE BACKUP UTILITY

Question

제품 : ORACLE SERVER
작성날짜 : 1996-11-29
1. The Problem
과거 메인 프레임 환경에서 사용하던 고객들이 저 비용, C/S환경으로
Migration시에는 주로 Open system과 Oracle RDBMS를 채택하고 있다.
이런 관계로 해당 제품 시장은 고 성장을 구가하고 있기도 하다.
이러한 고 성장을 가능케 하는 요소는 물론 H/W,S/W에서의 혁신적인
진보이나, 메인 프레임급에 걸 맞는 대용량 DB를 관리하고 Backup하는
데 필수적인 System management tool은 과거와 크게 달라진 바가 없다.
tar, cpio, dd같은 UNIX backup tool들은 실제 backup media의 관리
측면에서 별 기여 를 하지 못하고 있다. 대용량 DB를 위한 Backup script는
source만 해도 수백line에 달하며 test와 troubleshoot에서도 많은 문제점을
갖고 있다. 뿐만 아니라 대용량 Database(이하 VLDB)의 Restore는
Backup보다도 훨씬 더 복잡한 문제를 갖고 있다.
최근의 Backup file이 어느 곳에 저장 되었는지를 알기 위해 Backup
tape을 분류하고, damaged file들을 restore 해야 하는 등의 일련의 작업이
필요하다.
2. The Solution
최근에 몇몇 media management vendor들은 media management기능,
scheduling기능, 강력한 security기능, UNIX system에서 제공하는 backup
tool이상의 신뢰성을 갖는 강력한backup product를 공급하기 시작했다.
이러한 product들은 system level에서의 관리를 용이하게 해주는 장점은
있으나 이미 위에서 지적된 VLDB의 backup시 제기되는 문제점들을
완전히 해결해 주지는 못한다.
Oracle7 Enterprise Backup Utility(이하 EBU)는 이런 문제점을 해결하는
solution이다. EBU는 backup/restore시 media management product와 강력한
인터페이스를 제공하며 다른 어느것과 비교 할 수 없는 강점을 갖고
있다.
3. Introducing Oracle7 Enterprise Backup Utility
EBU는 open system상에서 메인 프레임급 성능을 제공하여 한 기업
전반에 걸쳐 전략적으로 중요한 역할을 감당하게 된다. 이 utility는 DB의
신속한backup과 restore를 위해disk와 backup될 media device에서H/W
parallelism을 이용한다.open system의 full capacity를 이용하기 위해
device가 add될 때 performance가 증가된다.parallel H/W, backup
configuration check ,error detection and cleaning ,restore시의
database의block verification과 같은 특징들이EBU가 high reliability를 갖게
하는 특징들이다.
Oracle7 데이타베이스는 data files, control files, redo log files로
구성되는데 EBU는data file, control file을 backup받고 archived redo log
file을 받는다. (release2.0.8) Media failure의 경우 DB를 full restore/
partial restore가 가능하며 data file도 선택적으로 최근의 last backup까지,
어느 일정 시점 까지 만의 선택이 가능하다. 또한 recovery도 일정 시점으로
완전recovery가 가능하다.
4. Architecture
EBU는 크게 두 부분으로 구성되는데 backup하려 하는 DB에 관한 모든
current정보와history를 관리하는 catalog부분, 그리고 실행 파일 부분으로
구성된다. 실행 파일들과 catalog는 반드시 같은 host내에 존재할 필요는
없다. 실행 파일들은 다음으로 구성된다.
*obackup : 모든 다른 프로세스들을 monitor하며 backup하려하는 DB,
catalog와의 communication을 담당한다.또한 Instance Manager를
running시킨다.
*brio  : obackup, brdk, brtp사이 조정 역할을 수행한다.parallel I/O
stream당 하나의 brio process가 발생한다.
*brdk : Disk file의 read/write를 조절한다. File당 하나의 brdk를 발생시키
므로 만일 여러 개의 file들을 하나의 single data stream으로 결합시
키는 경우 하나의 I/O stream내에 여러 개의 brdk process를
create한다.
*brtp : Tape file들의 read/write를 조절한다. I/O stream당 하나의 brtp
create.
*brd : Instance Manager로써 backup catalog, obackup을 monitor하는
daemon process이다. backup을 위한 cleanup과 비정상 종료된 작업을
복구 한다.
Backup동안 database file들은 disk process인 brdk에 의해 읽혀져 backup
buffer area로 넘겨지고 그 후 third vendor의 media management s/w를
경유하여 backup device에 brtp process에 의해 write된다. Restore시는
반대의 과정이 진행된다. 위의backup buffer는 hard disk와 tape device간에
발생하는 I/O상의 speed mismatch를 조절하는 역할을 한다.
5. EBU의 장점(Benefits)
Third vendor의 media management product와 함께 사용되는 EBU는
기존의 UNIX 에서 제공하는 backup tool보다 다음과 같은 강력한 장점을
지닌다.
(1) 강력한 Reliability.
*. Consistent backup procedures
기존의 hot backup script의 경우 만일 datafile이 추가될 경우 script에
새로 지정해 주어야 하며 VLDB의 경우 script만 해도 수백line에 달하여
관리상 번거로운 게 사실 이였다. 그러나 EBU의 경우는 어느 datafile이
어느directory에 위치하는지를 작업자가 알 필요가 없고 script는 짧고
단순하여 누구든 쉽게 알아볼 수 있다.
또한 DB 구성이 자동으로 확인되며 backup media를 자동으로 인식 및
관리한다.
예).full online backup script .partial online backup script
backup online database backup online
db_name = "PRODB" db_name = "PRODB"
oracle_sid = "PROD" oracle_sid = "PROD"
tablespace = "SALES"
.full restore script
restore database
db_name = "PRODB"
oracle_sid = "PROD"
이와 같이 간단한 script에 의해 DBA는 VLDB를 쉽게 backup과 restore를
할 수 있으며 작업에 필요한 세부정보는 backup catalog내에 있게 된다.
*. End-to-End checksum
Backup시 EBU는 각 backup data의 byte를 계산하고, restore시도 계산하여
정상 수행 여부를 판단 시 checksum 값을 상호 체크 한다.
*. Instance Manager
Instance Manager는 backup/restore시에 진행 상황을 monitor하고 작업
중에 에러가 발생시 복구 및 각종resource를 release시키는 기능을 담당하게
한다.
(2) High Performance
다음과 같은 EBU의 특징과 고속media device의 지원 아래 VLDB의
backup을 적은시간 내에 완전하게 수행 할 수 있게 되었다.
*. Parallel Hardware Capability
Backup/restore시 multiple device를 사용하여 동시에 여러 tablespace에
대한 작업을 수행 할 수 있다. VLDB와 같이 다수의 tablespace, datafile이
여러 disk에 분산되어 있는 경우 이와 같이 물리적으로 다수의 device를
parallel하게 사용함으로서 performance를 극대화 시킬 수 있다.
Backup시 동시 사용되는 device의 수와 performance는 정비례하게 나타난다.
*. Multiplexing
EBU는 backup device가 최고의 속도로 backup을 수행 할 수 있게 script에
지정 할 수가 있다.이것은 backup media access속도보다 disk access
속도가 훨씬 작은 경우에 여러 disk에 분산된 datafile들을 한device에
multiplexing되게 지정함으로 가능하다.
*. Null Block Compression
EBU는 backup시 null data block을 skip시키고 restore시 재구성함으로써
공간 을 절약하며 performance를 증가시킨다.
*. Buffered I/O
EBU는 disk I/O와 device I/O사이의 access speed의 mismatch를 줄이기
위하여 모든 I/O stream을 bufferring한다. 양쪽의 I/O는 shared memory
buffer를 거치게 함으로써 backup/restore수행 중 항시 일정 속도를 유지
하게 한다. shared memory는 user가 parameter로 구성할 수 있으며 기본
적으로는 parallel data stream의 개수와 buffer size에 dependent하다.
(3) Availability
한 기업에서 전략적으로 중요한 DB들은 대부분 24시간*7일 full로
가동되며, 사용 중에 backup을 수행할 수 밖에 없다. Offline full backup은
당연히 지원되며, EBU는 DB를 online상태로 full backup이 가능하며,
또한partial backup도 가능하다. 기존의 online backup이 backup으로 인해
performance를 저하시키는 단점이 있었으나 EBU는DB 운영에 최소의
영향만을 미친다.
Recovery시에도 full로 restore 시킬 수 있으며 나머지는 사용 중인
상태에서 필요 부분만 partial restore가 가능하다. 일단 EBU가 data를
restore시킨 후에는 기존의 Oracle7의 표준 recovery process가 적용되어
진다.
(4) Usability
*. Auto-configuration
Online backup을 수행 시 EBU는 current DB configuration과 backup catalog
내의 가장 최근의 configuration정보를 비교하여 backup catalog정보가 더
오래 전의 것이면 EBU는 DB의 backup직전으로 update시킨다.
Auto-configuration은 default이며 명시적으로 지정하여 disable시킬 수 있다.
Offline backup시는 backup script내에 backup command기술 전에 register
라는 명령어를 기술 해야만 configuration정보를 update시킬 수 있다.
*. Light-Out backups
Third party의 media management s/w를 이용하여 EBU를 operator의 개입 없
이 자동으로 수행이 가능하다. UNIX의 cron에서도 자동으로 수행되게 할 수
있다.
*. Raw device support
EBU는 raw device로 잡힌 DB도 operator의 특별한 조치 없이 일반 file
system의 backup과 똑같이 수행할 수 있게 한다.
*. Aggregated restore
기업의 mission-critical system에서의 backup 전략들은 흔히 partial
backup에 의존하게 된다. 이와 같은 환경에서는 backup data내의 모든file에
대한 current version을 검색하는 일이 중요한데 EBU는 이것을 자동으로
수행한다. partial backup data는 restore시 media failure이전에 취해진
가장 최근의 full backup data와 aggregated 되어져 이용된다.
*. Point-in-Time restore
EBU는 backup catalog내에 backup하려하는 DB에 대한 모든 configuration
history를 갖고 있어서, 만일 하나의 tablespace가 drop된 후 다시 필요하게
되면 비록 그 후 일정 시간이 경과되고 많은 변경이 일어났더라도 drop직전으로
일부분만 restore하여 사용이 가능하게 할 수 있다. 이 같은 tablespace는
다른 machine에 restore 될 수도 있어 현재의 DB작동에 아무 영향을 미치지
않고 수행할 수가 있다.
*. Backup catalog
EBU에 의해 제공되는 backup catalog는 모든 backup대상 DB의 configuration
과 history의 저장소로써 제공된다. backup catalog에 저장된 정보는 backup된
file, tablespace 그리고 multiplexing정보, 마지막backup이나 restore의
시간기록,backup type(full or subset),backup들이 저장 되어 있는 file set
등을 포함하고 있다. 하나의 backup catalog는 기업 내 모든 분산된 dB들을 관리
할 수 있다.
*. Dry Runs
VLDB를 backup시 겪는 문제 중 하나는 과연 script가 정상적으로 수행이 완료
되는지를 검증하는 것이다. 특별한 방법이 없는 한 긴 시간 동안 수행시켜 끝난
후 확인 할 수 밖에 없는데 EBU는 I/O없이 간단히 test로 수행을 시킬 수가
있다. 이로 인해 신뢰성 있는 backup전략을 DBA가 수립 가능하게 한다.
*. Enterprise-wide backup
이것은 backup이 단순히 single database에 국한되지 않고 한 기업 전체에
걸쳐서 global하게 수행 가능함을 말한다. 예로 전국적으로 다수의 site에
database가 구축 되어진 상황에서 각database들이 two phase commit,
snapshot 같은 분산처리 작업을 통해 다른 database들을 synchronous하게
또는 asynchronous하게 update할 경우 기업 전체를 하나의 logical
database로 보고 이런 logical database를 중앙에서 EBU를 통해 backup시킬
수가 있다.EBU는 중앙의 catalog내에 모든database들에 대한 backup정보를
간직하고 있다.
이와 같은 중앙의 한 지점을 통하여 기업 전체 모든 database들에 대한
backup수행 기능은 EBU의 가장 큰 장점 중 하나이며 이런 경우 N/W상에 대량의
data가 전송되어 network의 bandwidth가 backup의 중요한 요소로 부각된다.
6. Flexibility
*. EBU API
EBU는 앞에서도 소개되었듯이 단독으로 사용되는 것이 아니고 third-part
에서 제공하는 media management product와 같이 사용된다. 이때 두 product
사이의 interface는 backup/restore Application Programming Interface
(API Glue)에 의해서 이루어 진다. 이것은 third part에 의해 제공되며
EBU install시 installer에 의해 자동적으로 access된다.
*. Media management products
Epoch*s EpochBackup, IBM Adstar*s Distributed Storage Manager,
Legato Systems*NetWorker, HP*s Omniback*, SprectraLogic*s
Alexandria,StorageTek*s REEL, etc.
*. Media device
4mm and 8mm DATS,3480s,3490s,WORM,Writable Optical Devices and
automated systems such as stackers and silos.
7. Pricing
EBU는 무상으로 공급되며 사용을 위해서는 third vendor의 media
management product를 구입하여 설치하여야 한다.

Answer 1

Sure, would you clarify which DB, which OS and which product?
Concept in general is quite simple:
- stop BOE (SIA on XI3, All services, finishing with CMS on XIr2, ideally putting a sleep between all servers shutdown and CMS shutdown). NET STOP on windows.
- Backup the CMS DB (imp/exp on Oracle, mysqldump for MySQL)
- Backup the FileStore (use robocopy in a batch for delta backup)
- Restart BOE
The "catches" are around Oracle doing export in US7ASCII by default under Unix, which is a destructive conversion from UTF8 (your CMS DB should be under this format as per supported platforms), so you need to make sure to set the NLS_LANG to UTF8 on Unix user doing the backup.
Other than that, batch as shell can do all of that.
Regarding the "general" best practices, I recommend the following doc:
http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/c0020482-ca8d-2c10-9bad-d1bd332bbb28
Note on integrated BO tools: Import Wizard as biarengine are good tools for promoting a set of data between wto BOE environment or if you need to backup a specific set, but they are definitly not recommended as backup solution. I would refrain from this solution IF the point of the backup is to be able to recover the system when it crashes.
Does that answer the question?