Oracle® Communications ASAP System Administrator's Guide
Release 7.2
E18879-01
  Go To Table Of Contents
Contents

Previous
Previous
 
Next
Next
 

5 Backing Up and Restoring ASAP Files and Data

This chapter describes Oracle Communications ASAP backup and restore strategies for the file system and the database.

About Backing Up and Restoring Files and Data

As an ASAP system administrator, you should observer the following guidelines for backing up and restoring your ASAP system and databases:

ASAP System Backup and Restore

Backup the ASAP environment, Oracle WebLogic Server, and Oracle database schemas in the following situations:

  • After you successfully install ASAP

  • Before you upgrade ASAP in case you need to rollback your upgrade

  • After you successfully upgrade ASAP

See the ASAP Installation Guide for procedures to backup your ASAP system.

In addition to these ASAP system backup scenarios, you should also follow the database backup schedule and procedures described in "Database Backup and Recovery".

See the section about rolling back your ASAP system in the ASAP Installation Guide to restore your ASAP system. These roll back procedures described in the ASAP Installation Guide will return your ASAP system to the initial installation state and post or pre upgrade state. To recover lost data, restore your database backups described in "Database Backup and Recovery".

Database Backup and Recovery

ASAP application databases must be protected in the event of corruption or failure.

The Service Activation Request Manager (SARM) and Service Request Processor (SRP) databases should be backed up daily. The Control and Network Element Processor (NEP) databases can be backed up less often since they contain only static and monitoring data. The schedule of transaction dumps is dictated by the amount of space available for the transaction logs.

The Administrative database does not need to be backed up because it only contains performance statistics.


Note:

Backup in a distributed environment is no different than in a non-distributed environment, except that tapes have to be placed in numerous machines.

Database Backup Strategy

Backup procedures must be performed periodically and should be fully automated by the System Administrator and Database Administrator. Cron scripts can be written which will dump the ASAP application databases, and associated transaction logs to disk and then to tape. In the case of Oracle, these cron scripts should backup to tape all data files, the control file, and archive logs to tape. For Oracle databases the Database Administrator should first decide whether to employ hot backups of the tablespaces or a full cold backup. It is recommended that a cold backup be done at least once a week in addition to a full database export. The backup strategy you choose will be determined primarily by the amount of data loss that can be tolerated in the event of failure.

The ASAP databases are as follows:

  • Control – Can be recreated from the data on the switches, but may be backed up if required.

  • SRP – Should be backed up daily.

  • SARM – Should be backed up daily.

  • NEP – Can be recreated from the data on the switches, but may be backed up if required.

  • Admin – Not necessary to back up because it contains only performance statistics.

Database Backup in a Distributed Environment

Backup in a distributed environment should be no different than a non-distributed environment, except that tapes may have to be placed in numerous machines.

ASAP WebLogic Server Domain Back Up

You can archive domain configurations:

  • Automatically to other media (such as tapes or disks)

  • Manually by copying files to another directory, and preferably, other machines

You should regularly back up the following:

  • Configuration data

  • Security data

  • Deployed applications

Configuration Data

Back up configuration data, including the config.xml file and the config.xml.booted file from the Domain_home/config/ directory. The config.xml.booted file is created when you successfully start the administration server and can serve as backup in the event that the config.xml file becomes unusable. You can overwrite the config.xml file with the config.xml.booted file to restore the domain to the last successful startup configuration.

Security Data

Back up the Administration Server security data for a domain. The security data that you should archive includes:

  • Security Configuration Data

  • WebLogic LDAP Repository

  • SerializedSystemIni.dat and Security Certificates

For more information on administering domains, refer to

http://download.oracle.com/docs/cd/E13222_01/wls/docs103/admin.html