Backing up the Application Server 10g Oracle Application Server Tips by Burleson Consulting

The first step is to define you backup strategy and implement it.  You must periodically review you strategy to insure that it still meets your business needs.  A backup strategy defines when you need to backup each server, and how you will recover if a server goes down.  Part of this discussion must also address down time cost.  If a system has a high per minute downtime cost (thousands of dollars per minute) then there is a need to implement a high available solution, even if system availability requirements are only 10 hours per workday.  Most companies start by stating that their system must be available 24 hours a day, 7 days a week.  In this case, refer to chapter 9, High Availability.  Faced with the expense of these solutions, many companies more realistically define their availability needs based on user/customer requirements.  Your backup strategy must support your business needs.

The system availability requirements will determine whether you can perform cold or hot backups.  A cold backup requires that you shutdown the application server, to include the Metadata Repository.  A cold backup is consistent across the application server components because they are not running when the backup is taken.  Cold backups are the easiest to execute and maintain.  Hot backups are required when the application server must remain available to respond to users during the backup process.  A hot backup of the middle tier instances is a relatively easy process but is muck more complicated for the Metadata Repository database and the backend database.  Finally there are solutions external to the Oracle software to automate backups such as products from Veritas etc.  For information on these products you should refer to the vendor.  For this discussion, we will focus on the application server and the metadata repository database.

What to Backup

On each server within the application server topography there are four types of files that need different levels of protection.  This is true for both the application server and the Oracle9i database.  Your backup strategy needs to address each category of file.

First are the operating system files.  These files make up the OS and you need to refer to the OS reference to determine which OS files needs protection.  Normally these files do not change over time unless you change the configuration or apply patches.  A full backup, taken after updates will normally suffice. 

The second set of files are the Oracle product files.  These files are located in the instance $ORACLE_HOME and the oraInventory directories.  These include the product binary files.  Like the OS, these files do not change once installed unless additional components or patches are installed.  Again, a full backup after changes in configuration or patches will suffice.

The third set of files is the data, configuration and application files that change during the normal course of operation.  These include files maintained buy the user application, the Oracle Internet Directory, and the Metadata Repository database data files, control files and archive log files.  It is these files that backup protection must be routinely maintained.

The final set of files are the log files.  Unless you have a audit, SLA or other reason to insure that these files are protected, their loss will have little impact and they can be excluded from a backup routine.  Note, this does not included database archive log files that are critical to the database recovery mechanism.

The easiest strategy is to execute a full backup of all servers each night.  While easy, there are drawbacks.  First the backup will be large and time consuming.  If will also be time consuming if you are required to restore one file, which must be located within the full backup.  Second it is wasteful of resources because for the most part you are constantly backing up unchanged data.  A more useful strategy would be to execute a full backup on the weekend and do nightly backups of the third set if files. 

Finally, it is important to know your system because you may only need to backup the middle tier once with nightly backups of the infrastructure tier.  If the files on the middle tier are static then they only need to be backed up when changed.

Application Server Protection

For the most part, the files that make up the application server do not change over time.  Static web pages and configuration files will not change unless you update the user application or deploy additional applications.  For example, if the Web Cache is placed in front of a cluster of application servers if only needs to be backed up when the configuration changes.  It is a waste of resources to nightly backup the Web Cache server since the only data that has changed is in the cache itself and you don't want a backup of the cache data.  On the other hand, the Infrastructure instance contains OID which normally is regularly updated by the user application and the application server. 

Backing Up Application Server Instances

Developing a backup strategy for a middle tier instance requires knowledge of the user application running on it.  For instance, if the user application maintains local data or state information in a local file, that file may be critical to routinely backup.  If all persistent data is maintained in a back-end database, there may be no requirement to nightly backup a middle tier instance.  Normally, a nightly backup of the instance $ORACLE_HOME will suffice.  You can also take incremental backups of only changed files, however this could lead to problems while attempting to find a file that needs to be restored.  Since it was only backed up when changed, you will have to first identify which backup contains the file before beginning the restore process.  To completely restore the instance, you would need to restore the last full backup and all later incremental backups to insure that you have restored the latest version of each file.  For that reason, I recommend that you take a full backup of the instance $ORACLE_HOME for each routine backup.  This can be accomplished using the tar utility or you backup utility.

[oracle@appsvr oracle]$ . ./midenv
[oracle@appsvr oracle]$ cd $ORACLE_HOME
[oracle@appsvr oracle]$ tar cvzf /u03/oracle/backup/mid_back.tz . 

The above commands will source the mid tier environment, change to the mid tier?s $ORACLE_HOME directory and then backup that entire directory to the backup location.  I can then backup mid_back.tz to tape in the background if needed.  This command can be used while the instance is running.

In the case of the Infrastructure instance, the Metadata Repository database is an Oracle9i database and must be maintain accordingly, see next section.  You still want to backup the database files with the instance but you will also have to execute a database backup (Hot or Cold). 

Finally, do not forget to backup the oraInventory directory whenever you take any action that requires starting the Oracle Universal Installer.  This is where Oracle saves information about what is installed on the server to include patch information.  If you have to rebuild the server you will need to restore the oraInventory directory in order to apply patches/upgrades in the future.  When you backup the oraInventory directory, include the oraInst.loc and oratab files.

Now that we have a backup, hopefully you will never use it.  But if you need it, you need to know how to use it to restore an application server instance.

This is an excerpt from "Oracle 10g Application Server Administration Handbook" by Don Burleson and John Garmany.