Seminole Fuel Selector

"Sexual Morality? The essence of Love

Kidde Carbon Monoxide Detector Err Message

Integrating bacula and Oracle RMAN. Open draft

The idea is to define the pieces ( and combinations of them ), scenarios, tools and procedures to integrate the bacula backup solution with the Oracle Rman utility. Please, feel free to collaborate on this draft, use the comments and I will update the post with your contribution and credit. Once we'll have a good base, I will begin to develop the solution ( more hands are wellcome :D ).

Oracle releases



9i and 10g . When something described below will be only applicable for one of this releases will be informed accordingly.

Assumptions
Rman will not be able to talk 'directly' to tape device using bacula. The primary destination of rman backup pieces will be disk ( see below
Rman backup set to disk
point )

Pieces and scenarios

Rman binaries


The rman binaries can be located at the same host where resides the databases to be protected or in a different host than the databases to be protected ( could be the same host as the bacula director ).

In any case, bacula must be able to execute scripts on the host where rman binaries are installed. Personally I think that running rman in the same host where is running bacula seems a good approach, 'cause we can store rman backup result locally in the machine where bacula is running and from there, directly to tape. I'm trying to minimize the recover period and at same time, a good availability in case of restore ( we can hold on disk always the last rman backup done )




Rman catalog



rman backup catalog stored in the database control file to be backed up. Control files will grow ( and depending on retention, can grow a lot ). Rman takes care to backup controlfiles. rman backup catalog stored in dedicated oracle database. Here an inexpensive linux machine with Oracle XE can fit very well, being able to use an Oracle database as rman catalog at no extra cost ( 4 GB of user data gives a lot of space for rman catalog data ). An extra bacula backup job must be done to backup this new database/host after all other rman backups has been done. Take in mind that is possible to catalog an rman backup.

Rman backup set to disk

We can storage the rman backup set in local storage where rman is executed, or in remote storage disk via network protocols ( nfs, iscsi... ). IMMO we need to minimize the data 'migration' between hosts to provide a good backup timing.

• Types of backups

The idea is to create a set of jobs on both bacula and rman to Full, incremental and cumulative. Both rman and bacula support them and we can call the aproppiate rman script depending on the backup type to perform. Join retention policies.



Type of database

• Oracle monoinstance. Can be some databases in a multihomed host.

Oracle RAC
Oracle Dataguard ( as product or as concept ). We can make a backup of the standby database and if we are using rman catalog, we can clean archivelogs from both instances.

• Database mode

Archivelog or no archivelog. In archivelog we can create rman policies to backup to disk archivelogs several times a day, and delete the archives that have been at least N times backed up, to mantain under control the space in the archivelog destinations. For the 'at least N times backed up' we need to assure that archivelogs backed up has been moved to tape. We can take a look to the rman instructions to manage valid backups inside is own catalog. In no archivelog mode, we can use rman but database will must just to be mounted.

• Bacula

Pre jobs and after jobs scripts using bacula environment variables to merge with rman scripts ( coherence and reference for the admin ).

• rman backup optimizations

Avoid to backup Oracle databases with the begin/end backup, this freezes the datafiles headers but oracle writes database blocks into them and then you're copying the files in inconsistent state. For this cause Oracle writes the entire block to the redo files when it tries to write a block of a tablespace that is maked as 'backup' ( if is a intensive writing database you will have a lot of switchlogs and archiving load ) Prior to 10G, it's necessary to put each tablespace in backup mode, in 10G we can use 'alter database begin backup' that do the job for us ( then we don't need to take care about new datafiles added over time ).


Of course, we need to backup control files and other important Oracle files 'manually'.

• Another point against this type of backup, If you have created a datafile of 2 GB but never used more than 25% of it you're backing up 2GB ( the entire file ). Rman takes care of what datafiles/controlfiles/archives and parameter file to backup. In 9i rman only reads blocks from datafiles under high-watermark ( in the previous example about the 2 Gb datafile and the 25% used, rman only will backup the 25% of the file ) In 10g rman is able to backup ONLY the used blocks, not the empty ones, even if them are under the high-watermark.
On RAC environments we can instruct rman to use a connection channel for each node in the cluster, paralleling the backup/restore process, but in 9i if one of this channels goes down, the backup/recover process gets broken. In 10g rman can manage this and use only the surviving nodes.

In 10g rman can compress the result 'on fly' ( with the ability to backup only used blocks and the compression method, we end with very little backed up data )
In 10g we can use a new feature called 'Block Change Tracking' where we instruct Oracle about a special file where it tracks the changed blocks ( only once, not each time the same block changes ), this tracking is used by rman to backup only the changed blocks without needing to read each datafile in the search of them. This tracking can be reseted when necessary (When performing full backups, for example).


The temporary datafiles from locally managed temporary tablespaces
Are Not backed up. In 9i, after restore the dba Must recreate Them. In 10g rman Is Able to recreate this datafiles accordingly.