Backing up BIP Environment

This chapter describes recommended backup strategies for Oracle Fusion Middleware and the procedures for backing up Oracle Fusion Middleware.

Overview of Backing up Environment

Please use following recommended strategy for backing up your Oracle Fusion Middleware environment:

If you are performing an online backup, do not make any configuration changes until the backup is completed. To ensure that no changes are made in the Weblogic Server domain, lock the Weblogic Server configuration

Before you make configuration changes, lock the domain configuration, so you can make changes to the configuration while preventing other accounts from making changes during your edit session. To lock the domain configuration: 1. Locate the Change Center in the upper left of the Administration Console screen. 2. Click Lock & Edit to lock the configuration edit hierarchy for the domain. As you make configuration changes using the Administration Console, you click Save (or in some cases Finish) on the appropriate pages. This does not cause the changes to take effect immediately. The changes take effect when you click Activate Changes in the Change Center. At that point, the configuration changes are distributed to each of the servers in the domain. If the changes are acceptable to each of the servers, then they take effect. If any server cannot accept a change, then all of the changes are rolled back from all of the servers in the domain. The changes are left in a pending state; you can then either edit the pending changes to resolve the problem or revert to the previous configuration.

Perform a full offline backup immediately after you install Oracle Fusion Middleware. Perform backups of run-time artifacts after every administrative change and on a regular basis. Oracle recommends that you back up run-time artifacts nightly. Perform a new full backup after a major change, such as any upgrade or patch, or if any of the following files are modified:
MW_HOME/wlserver_n/common/bin/nodemanager.properties MW_HOME/wlserver_n/common/bin/wlsifconfig.sh MW_HOME/wlserver_n/common/bin/setPatchEnv.sh MW_HOME/wlserver_n/common/bin/commEnvg.sh

Create a record of your Oracle Fusion Middleware environment. When you create the backup, name the archive file with a unique name. Consider appending the date and time to the name. For example mwhome_backup_22Jan2013.tar

Limitations and Restrictions for Backing up Data

LDAP backups: If you use the built-in LDAP, do not update the configuration of a security provider while a backup of LDAP data is in progress. If a change is made (for example, if an administrator adds a user, while you are backing up the ldap directory tree), the backups in the ldapfiles subdirectory could become inconsistent. Refer to Weblogic Server Managing Server Startup and Shutdown for detailed LDAP backup procedures. Persistent stores: A persistent store provides a built-in, high-performance storage solution for weblogic Server subsystems and services that require persistence. For example, it can store persistent JMS (Java Messaging Service) messages or durable subscriber information, as well as temporarily store messages sent to an unavailable destination using the Store-and-Forward feature. The persistent store supports persistence to a file-based store (File Store) or to a JDBC-enabled database (JDBC Store). The default store maintains its data in the data\store\default directory inside the server name subdirectory of a domain's root directory. It is currently not possible to take consistent backup of persistent stores for a system that uses JMS and transaction logs. This is because the transaction logs can only be file-based and the JMS can be either file-based or it can reside in the database. For highest reliability, use a highly available, fault-tolerant storage (for example, SAN) for JMS and transaction log file stores. For clustered servers, Oracle Weblogic Server enables you to migrate a failing server, including the Transaction Recovery Service, to a new system. When the server migrates to another system, it must be able to locate the transaction log records to complete or recover transactions. Transaction log records are stored in the default persistent store for the server. If you plan to migrate clustered servers in the event of a failure, you must set up the default persistent store so that it stores records in a shared storage system that is accessible to any potential system to which a failed migratable server might be migrated. For highest reliability, use a shared storage solution (for example, SAN) or an Oracle database that is highly available and supports a point-in-time recovery. This solution is also recommended for all the JMS modules.

Audit Framework: If you have configured Oracle Fusion Middleware Audit Framework to write data to a database, you should not back up the local files in the bus stop. (Auditable events from each component are stored in a repository known as a bus stop; each Oracle Weblogic Server has its own bus-stop. Data can be persisted in this file, or uploaded to a central repository at which point the records are available for viewing and reporting.) If you back up the local files, duplicate records are uploaded to the database. That is, they are uploaded to the database when the bus stop is created and then are uploaded again when you restore the files.

The default locations for bus stop local files are:

o o o o

For Java components:

DOMAIN_HOME/servers/server_name/logs/auditlogs/component_type

For system components, such as Oracle HTTP Server or Oracle Internet Directory:
ORACLE_INSTANCE/auditlogs/component_type/component_name

Performing a Backup
We can perform backups in two ways:

Full offline backup. Online or offline backup of run-time artifacts.

Full Offline Backup

Copy the directories that contain Oracle Fusion Middleware files.

Archive and compress the source Middleware home, using your preferred tool for archiving. Ensure that the tool you are using preserves the permissions of the files. For online backups on Windows, use copy; for offline backups on Windows, use copy, xcopy, or jar. Note that for some versions of Windows, any file name with more than 256 characters will fail. You can use the xcopy command with the following switches to work around this issue:
xcopy /s/e "C:\Temp\*.*" "C:\copy"

Do not use Winzip because it does not work with long filenames or extensions. For Linux and UNIX, use tar. The following example shows how to archive and compress the source on UNIX:
cd $MW_HOME tar cf - * | gzip > mwhome_backup_22Jan2013.tar.gz

The tar utility may issue warnings if the sticky bit is set on some files. You can safely ignore these warnings. Do not use the jar utility to archive and compress the file system. This avoids warnings or errors from the zip tool about zipping open files (for example, the ORACLE_HOME/jdk files). Take the following steps: 1. Shut down all processes in the Middleware home. For example, shut down the Managed Servers, the Administration Server, and any Oracle instances running in the Middleware home. 2. Back up the Middleware home (MW_HOME) on all hosts. For example:
3. tar -cf mw_home_backup_032010.tar MW_HOME/*

4. If the domain is not located within the Middleware home, back up the Administration Server domain separately. This backs up Java components such as Oracle SOA Suite and Oracle WebCenter. For example:
tar -cf domain_home_backup_22Jan2013.tar domain_name/*

In most cases, you do not need to back up the Managed Server directories separately, because the Administration Server domain contains information about the Managed Servers in its domain. 5. If the Oracle instance home is not located within the Middleware home, back up the Oracle instance home. The Oracle instance home contains configuration information about system components, such as Oracle HTTP Server or Oracle Internet Directory For example:
tar -cf sc_home_backup_22Jan2013.tar ORACLE_INSTANCE/*

6. If a Managed Server is not located within the domain, back up the Managed Server directory. For example:
7. tar -cf mg1_home_backup_22Jan2012.tar server_name/*

8. Back up the OraInventory directory. For example:

9. tar -cf Inven_home_backup_22Jan2013.tar /scratch/oracle/OraInventory

10. Back up oraInst.loc and oratab files, which are located in the following directory:
11. /etc 12. Back

up the database repositories using the Oracle Recovery Manager (RMAN) 13. On Windows, export the following registry key:
14. HKEY_LOCAL_MACHINE\Software\oracle

In addition, for system components, such as Oracle Web Cache, export the following Windows Registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services

To export a key, use the following command:

regedit /E FileName Key

For example:
regedit /E C:\oracleregistry.reg HKEY_LOCAL_MACHINE/oracle

You can also use the Registry Editor to export the key. Create a record of your Oracle Fusion Middleware environment.

Performing an Online Backup of Run-Time Artifacts

To back up run-time artifacts: 1. To avoid an inconsistent backup, do not make any configuration changes until the backup is completed. To ensure that no changes are made in the Weblogic Server domain, lock the Weblogic Server configuration. 2. Back up the Administration Server domain directories. This backs up Java components such as Oracle SOA Suite and Oracle WebCenter. For example:
3. tar -cf domain_home_backup_22Jan2013.tar MW_HOME/user_projects/domains/domain_name/*

For Oracle Portal, Oracle Reports, Oracle Forms Services, and Oracle Business Intelligence Discoverer, you must back up the Managed Server directories, in addition to the Administration Server domain directories. 4. Back up the Oracle instance home. This backs up the system components, such as Oracle HTTP Server. For example:
5. tar -cf sc_home_backup_22Jan2013.tar ORACLE_INSTANCE/*

6. Back up the database repositories using the Oracle Recovery Manager (RMAN).
Creating a Record of Oracle Fusion Middleware Configuration
In the event that you need to restore and recover your Oracle Fusion Middleware environment, it is important to have all the necessary information at your disposal. This is especially true in the event of a hardware loss that requires you to reconstruct all or part of your Oracle Fusion Middleware environment on a new disk or host. You should maintain an up-to-date record of your Oracle Fusion Middleware environment that includes the information listed in this section. You should keep this information both in hardcopy and electronic form. The electronic form should be stored on a host or e-mail system that is completely separate from your Oracle Fusion Middleware environment. Your Oracle Fusion Middleware hardware and software configuration record should include:

The following information for each host in your environment: o Host name o Virtual host name (if any) o Domain name o IP address o Hardware platform o Operating system release level and patch information The following information for each Oracle Fusion Middleware installation in your environment: o Installation type (for example, Oracle SOA Suite) o Host on which the installation resides o User name, userid number, group name, groupid number, environment profile, and type of shell for the operating system user that owns the Oracle home (/etc/passwd and /etc/group entries) o Directory structure, mount points, and full path for the Middleware home, Oracle Common home, Oracle homes, Oracle Weblogic Server domain home (if it does not reside in the user_projects directory in the Middleware home), and the Oracle instance home o Amount of disk space used by the installation o Port numbers used by the installation The following information for the database containing the metadata for components: o Host name o Database version and patch level o Base language o Character set o Global database name o SID

Recommended Backup Strategy

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

Perform an offline full back up at the following times:

o o o

Immediately after you install Oracle Fusion Middleware Immediately after an operating system software upgrade Immediately after upgrading or patching Oracle Fusion Middleware

Perform an online backup of run-time artifacts:

Backing up the run-time artifacts enables you to restore your environment to a consistent state as of the time of your most recent configuration and metadata backup. To avoid an

inconsistent backup, do not make any configuration changes until backup completes. Perform an online backup of run-time artifacts at the following times:
o o o o o

On a regular basis. Oracle recommends that you back up run-time artifacts nightly. Prior to making configuration changes to a component or cluster. After making configuration changes to a component or cluster. Prior to deploying a custom Java EE application to a Managed Server or cluster. After a major change to the deployment architecture, such as creating servers or clusters.

Perform an offline backup of static files and directories:

Perform an offline backup of static files and directories at the following times:
o o

After patching your Oracle Fusion Middleware environment. This backup serves as the basis for subsequent online backups. After upgrading your Oracle Fusion Middleware environment. This backup serves as the basis for subsequent online backups.

Backup and Recovery Recommendations for Oracle BI Enterprise Edition

This section describes the Oracle BI Enterprise Edition data that must be backed up and restored. Configuration Files
ORACLE_INSTANCE/bifoundation/OracleBIApplication ORACLE_INSTANCE/bifoundation/OracleBIClusterControllerComponent ORACLE_INSTANCE/bifoundation/OracleBIJavaHostComponent ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent ORACLE_INSTANCE/bifoundation/OracleBISchedulerComponent ORACLE_INSTANCE/bifoundation/OracleBIServerComponent ORACLE_INSTANCE/bifoundation/OracleBIODBCComponent ORACLE_INSTANCE/config/OracleBIApplication ORACLE_INSTANCE/config/OracleBIClusterControllerComponent ORACLE_INSTANCE/config/OracleBIJavaHostComponent ORACLE_INSTANCE/config/OracleBIPresentationServicesComponent ORACLE_INSTANCE/config/OracleBISchedulerComponent ORACLE_INSTANCE/config/OracleBIServerComponent ORACLE_INSTANCE/config/OracleBIODBCComponent ORACLE_INSTANCE/diagnostics/logs/OracleBIApplication ORACLE_INSTANCE/diagnostics/logs/OracleBIClusterControllerComponent ORACLE_INSTANCE/diagnostics/logs/OracleBIJavaHostComponent ORACLE_INSTANCE/diagnostics/logs/OracleBIPresentationServicesComponent ORACLE_INSTANCE/diagnostics/logs/OracleBISchedulerComponent ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent ORACLE_INSTANCE/diagnostics/logs/OracleBIODBCComponent

In addition, the following files in a file-based repository:

ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/comp_instance name/repository/*.rpd ORACLE_INSTANCE/bifoundation/OracleBIPresentationServicesComponent/comp _instance name/catalog/catalog-name

The NQSConfig.INI configuration file points to the Repository Publishing Directory (RPD) name. The NQSConfig.INI file must exist in the following location:
ORACLE_INSTANCE/bifoundation/OracleBIServerComponent/comp_instance name/repository/

Database Repository Dependencies UserStats, SCHEDULER, and BIPUBLISHER schemas Backup Recommendations Back up the Middleware home, the domain home, and Oracle instance containing the Oracle BI EE components. Back up the database containing the Oracle BI EE schemas. Note: Before you perform a backup, you must lock the Oracle BI Presentation Catalogs so that the catalog and RPD will stay synchronized. Run the following script:
MW_HOME/instances/instance1/bifoundation/OracleBIPresentationServicesCo mponent/coreapplication_obips1/catalogmanager/runcat.sh

Use the following command:

./runcat.sh -cmd maintenanceMode -on -online BIP_URL -login username pwd password

Recovering BIP Environment

Recovering the Domain
To recover an Oracle WebLogic Server domain that was corrupted or deleted from the file system: 1. Stop all relevant processes. That is, stop all processes that are related to the domain, such as the Administration Server and Managed Servers. For example, stop the Administration Server:
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

2. Recover the domain directory from backup:

cd DOMAIN_HOME (UNIX) tar -xf domain_backup_22Jan2013.tar (Windows) jar xtf domain_backup_22Jan2013.jar

3. Start all relevant processes. That is, start all processes that are related to the domain. For example, start the Administration Server:
DOMAIN_HOME/bin/startWebLogic.sh Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true

If you cannot start the Administration Server, recover it, as below

1. Stop all processes, including the Administration Server, Managed Servers, and Node Manager, if they are started. For example, to stop the Administration Server:
DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

2. Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
DOMAIN_HOME/config

3. Start the Administration Server. For example:

DOMAIN_HOME/bin/startWebLogic.sh Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true -

4. Verify that the Administration Server starts properly and is accessible.

To recover a Managed Server when it cannot be started:

1. If the Managed Server fails to start or if the file system is lost, take the following steps: 1. Recover the Middleware home from the backup, if required. For example:
tar -xf mw_home_backup_22Jan2013.tar

2. Create a domain template jar file for the Administration Server, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/domain_name -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log managed=true

Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option. 3. Unpack the domain template jar file, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar -domain=MW_HOME/user_projects/domains/domain_name -log=/scratch/logs/new.log -log_priority=info

4. Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server. Start the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

The Managed Server connects to the Administration Server and updates its configuration changes.

Recovering a Managed Server When It Does Not Function Correctly

In this scenario, the Managed Server is running, but the file system for the Managed Server has been lost or corrupted. To recover the Managed Server: 1. Stop the Managed Server. For example:
DOMAIN_HOME/bin/stopManagedWeblogic.sh username password managed_server_name admin_url

2. Recover the Middleware home from the backup, if required:

tar -xf mw_home_backup_22Jan2013.tar

3. Create a domain template jar file for the Administration Server, using the pack utility. For example:
pack.sh -domain=MW_HOME/user_projects/domains/WLS_SOAWC -template=/scratch/temp.jar -template_name=test_install -template_author=myname -log=/scratch/logs/my.log -managed=true

Specifying the -managed=true option packs up only the Managed Servers. If you want to pack the entire domain, omit this option. Unpack the domain template jar file, using the unpack utility:
unpack.sh -template=/scratch/aime1/ms.jar -domain=MW_HOME/user_projects/domains/WLS_SOAWC -log=/scratch/logs/new.log -log_priority=info

4. Ensure that the application artifacts are accessible from the Managed Server host. That is, if the application artifacts are not on the same server as the Managed Server, they must be in a location accessible by the Managed Server. 5. Restart the Managed Server. For example:
DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

Recovering an Oracle SOA Suite Managed Server That Has a Separate Directory
When Oracle SOA Suite is configured in a domain and no Managed Servers share the domain directory with the Administration Server, you must restore the Managed Server directory. For example, a domain contains two Managed Servers, one of which contains Oracle SOA Suite, but neither of the Managed Server's directories are in the same directory structure as the Administration Server. In this case, you must restore the Managed Server from backup: 1. Restore the Managed Server from backup:
cd ManagedServer_Home tar -xf managed_server_backup_032010.tar

2. Restart the Managed Server:

DOMAIN_HOME/bin/startManagedWebLogic.sh managed_server_name admin_url

Recovering an Oracle Home

To recover your Oracle home for a particular component: 1. Recover the Oracle home to the original directory from a backup file. For example:
2. cd ORACLE_HOME 3. tar -xf Oracle_home_backup_22Jan2013.tar

4. Restart the Managed Server to which applications are deployed, using the WLST start command. For example:
5. wls:/mydomain/serverConfig> start('myserver','Server')

Recovering an Oracle Instance Home

An Oracle instance home contains configuration information for system components, such as Oracle HTTP Server or Oracle Internet Directory

Recovering After Oracle Instance Home Deleted from File System

To recover an Oracle instance home that was corrupted or deleted from the file system: 1. Stop all relevant processes. That is, kill all processes that are related to that Oracle instance. 2. Recover the Oracle instance home directory from a backup file. For example:
cd ORACLE_INSTANCE (UNIX) tar -xf sc_home_backup_22Jan2013.tar (Windows) jar xtf sc_home_backup_22Jan2013.jar

3. Start all relevant processes. That is, start all processes that are related to that Oracle instance:
4. opmnctl startall

Recovering After Oracle Instance Home Deregistered

To recover an Oracle instance home that was deregistered from the domain: 1. Recover the Oracle instance home directory from a backup file. For example, on Linux:
cd ORACLE_INSTANCE tar -xf Instance_home_backup_22Jan2013.tar

2. Register the Oracle instance, along with all of its components, with the Administration Server, using the opmnctl registerinstance command. For example:
opmnctl registerinstance -adminHost admin_server_host -adminPort admin_server_port -adminUsername username -adminPassword password -oracleInstance ORACLE_INSTANCE_dir -oracleHome ORACLE_HOME_dir

-instanceName Instance_name -wlserverHome Middleware_Home

Recovering the Administration Server Configuration

If the Administration Server configuration has been lost because of file deletion or file system corruption, the Administration Server console continues to function if it was already started when the problem occurred. The Administration Server directory is regenerated automatically, except for security information. As a result, whenever you start the Administration Server, it prompts for a user name and password. To prevent this, you can recover the configuration. To recover the Administration Server configuration: 1. Stop all processes, including the Administration Server, Managed Servers, and Node Manager, if they are started. For example, to stop the Administration Server:
2. DOMAIN_HOME/bin/stopWeblogic.sh username password [admin_url]

3. Recover the Administration Server configuration by recovering the domain home backup to a temporary location. Then, restore the config directory to the following location:
4. DOMAIN_HOME/config

5. Start the Administration Server. For example:

6. DOMAIN_HOME/bin/startWebLogic.sh Dweblogic.management.username=username -Dweblogic.management.password=password -Dweblogic.system.StoreBootIdentity=true -

7. Verify that the Administration Server starts properly and is accessible.

Backup or Export Security Realm(Security Migration)

Exporting users and groups from WebLogic Security Realm. Login into the WebLogic Administration console ,navigate to Security Realm -> MyRealm

Click on the myrealm and Navigate to Migration tab

In the Migration tab click on the Export tab and in Export Directory on Server text box specify the location where the security realm data needs to be exported.

Click on the save button and go back to the physical location of the export directory mentioned above and verify whether 5 files are created as mentioned in the below screen shot.

1. 2. 3. 4. 5.

DefaultAuthenticator.dat DefaultCredentialMapper.dat exportIndex.dat XACMLAuthorizer.dat XACMLRoleMapper.dat

The users and groups from the realm are successfully exported now.

NOTE: If you are exporting for the first time then no need to select Overwrite option. If you are exporting for second time or later then you need to definitely select the Overwrite Option else weblogic will throw an error saying previous data exists. If you dont want to overwrite the previous exported data then you need to mention different directory path for exporting.

Recovery or Import Security Realm

For importing the Users and Groups into an existing realm, follow the below steps

1. Login into the WebLogic Administration console ,navigate to Security Realm -> MyRealm

Click on the myrealm and Navigate to Migration tab

In the Migration tab click on the Import tab and in Import Directory on Server text box specify the location where the security realm data exported earlier to import and click on the Save button.

Security Realm data is imported successfully. Check the Users and Groups tab under Security Realms MyRealms, you will see the users and groups are imported. It would not import the duplicate entries.