Backing up the Application
Oracle Application Server Tips by Burleson
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
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
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
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
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
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
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.