11 Introduction to Backup and Recovery

11.2.1 Types of Backups

The Oracle Application Server backup strategy involves two types of backups:

• Complete Oracle Application Server Environment Backup

• Online Backup

Complete Oracle Application Server Environment Backup

A complete Oracle Application Server environment backup includes:

• A full backup of all files in the middle-tier Oracle homes (this includes Oracle software files and configuration files)

• A full backup of all files in the Infrastructure Oracle home (this includes Oracle software files and configuration files)

• A complete cold backup of the Metadata Repository

• A full backup of the Oracle system files on each host in your environment

In Figure 11-2, the files that are backed up during a complete Oracle Application Server environment backup are shaded. The complete Oracle Application Server environment backup includes everything necessary to restore the initial installation of your Oracle Application Server environment. You must shut down your Oracle Application Server environment before performing this backup.

Figure 11-2 Files Backed Up in a Complete Oracle Application Server Environment Backup

Description of the illustration asadm005.gif

Online Backup

An online backup includes:

• An incremental backup of the configuration files in the middle-tier Oracle homes.

• An incremental backup of the configuration files in the Infrastructure Oracle home

• An online backup of the Metadata Repository

In Figure 11-3, the files that are backed up during an online backup are shaded. The online backup involves saving the configuration information, applications, and data across your entire Oracle Application Server environment at the same point in time. You can leave your Oracle Application Server up while performing an online backup.

Figure 11-3 Files Backed Up in an Online Backup

Description of the illustration asadm006.gif

11.2.2 Recommended Backup Strategy

This section outlines the recommended strategy for performing backups. Using this strategy ensures that you will be able to perform the recovery procedures in this book.

1. Perform a complete Oracle Application Server environment backup.

   Immediately after you install Oracle Application Server, you should perform a complete Oracle Application Server environment backup. This backup contains everything you need in order to restore your environment to its initial state. It servers as a baseline for all subsequent online backups.

2. Perform online backups on a regular basis.

   After every administrative change, or, if this is not possible, on a regular basis, perform an online backup of your Oracle Application Server environment. This will enable you to restore your environment to a consistent state as of the time of your most recent online backup.

   
   

   See Also: Appendix G, "Examples of Administrative Changes" to learn more about administrative changes

   
   

3. After a major change, perform a new complete Oracle Application Server environment backup.

   If you make a major change to your Oracle Application Server environment, perform a new complete Oracle Application Server environment backup. This backup will serve as the basis for subsequent online backups.

   Perform a new complete Oracle Application Server environment backup after:

   • An operating system software upgrade

   • An Oracle Application Server software upgrade or patch application

4. Perform online backups on a regular basis.

   After you establish a new complete Oracle Application Server environment backup, return to Step 2 and continue to perform online backups on a regular basis.

11.6.1 Considerations for DCM File-based Repositories

All middle-tier instances that are part of a farm use a DCM repository. The DCM repository contains configuration information and deployed J2EE applications.

There are two types of DCM repositories:

• Database repository—this is stored in the DCM schema in a Metadata Repository.

• File-based repository—this is stored on the filesystem in the Oracle home of one middle-tier instance in the farm, known as the repository host instance.

If your environment contains a database repository, you do not need to perform any special steps because the repository will be backed up and recovered during normal Metadata Repository backup and recovery.

If your environment contains a file-based repository, there are some special considerations for backup and recovery.

• Backup Considerations for DCM File-based Repositories

  When you back up the middle-tier instance that contains the file-based repository (the repository host instance), you should perform an additional step to create a backup of the file-based repository. Then, in case you lose the instance, you can recover the repository. The steps for creating the repository backup are included in the backup procedures in this book.

  You can identify the repository host instance using the following command:

  ORACLE_HOME/dcm/bin/dcmctl whichFarm
  
  

  This command returns a Repository Type of "Distributed File Based (host)" when run in the Oracle home of the repository host instance.

• Recovery Considerations for DCM File-based Repositories

  If you lose the repository host instance, you must restore the file-based repository as part of restoring the instance. If you restore the instance to a new host, you must perform an additional step to notify the other members of the farm that the repository is on a new host. These steps are included in the recovery procedures in this book.

  
  

  See Also: Oracle Application Server 10g High Availability Guide for more information on DCM file-based repositories

  
  

11.6.2 Considerations for DCM Archives

A DCM archive is a snapshot of the configuration of an Oracle Application Server instance or cluster at a particular point in time. You can apply archived configurations to the same instance or cluster, or to a different instance or cluster.

DCM archives are stored in the DCM repository (file-based or database). For standalone J2EE and Web Cache instances, archives are stored on the local filesystem.

You can use DCM archiving separately from OracleAS Backup and Recovery. It is an easy way to save configurations before making changes to your system, or to save and restore a particular configuration for specific purposes, such as operating one configuration during the day and another at night.

In addition, you can incorporate DCM archiving into your OracleAS Backup and Recovery strategies as follows:

• Backup Considerations for DCM Archives

  Oracle recommends that you create a DCM archive of each middle-tier instance every time you perform a backup, and export the archives to a backup location. This provides an additional measure of safety. The steps for creating and exporting a DCM archive are included in the backup procedures in this book.

• Recovery Considerations for DCM Archives

  Typically, you will not require a DCM archive for restoring your environment. However, there may be situations when you cannot restore middle-tier configuration files or the repository successfully. You can then use the DCM archive to restore your DCM configurations.

  
  

  See Also: Distributed Configuration Management Reference Guide for more information on DCM archiving, and Oracle Technology Network (http://otn.oracle.com) for the latest information on DCM

  
  

11.7.1 Considerations for OracleAS Cold Failover Cluster

If you use OracleAS Cold Failover Cluster, you can use the procedures in this book to backup and recover your environment, with the following additional considerations:

• Backup Considerations for OracleAS Cold Failover Cluster

  • Oracle recommends that you locate archive logs for the Metadata Repository on the shared disk. This ensures that, when failing over from one cluster node to another in the case of media recovery, the archive logs are also failed over and available.

  • You can generate archive logs to a local filesystem, however, the same path must be available during runtime on whichever node is hosting the Infrastructure instance.

  • Proper capacity planning is required in order to ensure adequate space is available to store the desired number of archive logs.

• Recovery Considerations for OracleAS Cold Failover Cluster

  There are no special considerations for recovering OracleAS Cold Failover Cluster. As mentioned in the previous backup section, if archive logs are stored on a local filesystem, in the case of media recovery, all archive logs must be made available to the application server instance performing the recovery. Recovery can be performed on either node of the cluster.

  
  

  See Also: Oracle Application Server 10g High Availability Guide for more information on OracleAS Cold Failover Cluster

  
  

11.7.2 Considerations for OracleAS Active Failover Cluster

If you use OracleAS Active Failover Cluster (AFC), you can use the procedures in this book to backup and recover your environment, with the following additional considerations:

• Backup Considerations for OracleAS Active Failover Cluster

  • In the case of AFC where the Metadata Repository is a RAC database:

    • When you enable automatic archiving, you must perform the step on every RAC instance.

    • Enabling ARCHIVELOG mode is done at the database level. Make sure to shut down all RAC instances (the entire database), mount one instance, and then enable ARCHIVELOG mode one that instance with the ALTER SYSTEM command.

  • Ensure archive destinations are the same on all nodes.

  • Keep backups consistent across all AFC nodes. Perform configuration file backups and Metadata Repository backups using the OracleAS Backup and Recovery Tool on one node. Then perform backups of only the configuration files on the additional AFC nodes.

    Once the configuration files and Metadata Repository have been backed up on the first AFC node, ensure no administrative changes take place until the configuration files on the additional AFC nodes have been backed up. If any administrative changes occur before you have a chance to backup the additional AFC nodes, a new backup of all AFC nodes is required.

    
    

    See Also: Appendix G, "Examples of Administrative Changes" to learn more about administrative changes

    
    

• Recovery Considerations for OracleAS Active Failover Cluster

  • In case of media recovery, ensure the archive logs from all AFC nodes are available in the archive log destination on the node where recovery is taking place.

  • Complete the recovery of configuration files and the Metadata Repository on one node first. Recover only the configuration files (not the Metadata Repository) on the additional AFC nodes. In an AFC Infrastructure configuration, the Metadata Repository is shared between all nodes. Once you have recovered the Metadata Repository on one node, there is no need to recover the Metadata Repository on the additional nodes.

    
    

    See Also: Oracle Application Server 10g High Availability Guide for more information on OracleAS Active Failover Cluster

    
    

11.7.3 Considerations for OracleAS Disaster Recovery

If you are using OracleAS Disaster Recovery, refer to the OracleAS Disaster Recovery documentation for considerations on using backup and recovery in an OracleAS Disaster Recovery environment.