The following sections describe how to backup and restore WebLogic Network Gatekeeper installations:
In addition to the domain-level configuration backups described in Backing Up the Domain Configuration, you must backup the WebLogic Network Gatekeeper database (generally named slee_db
). The slee_db
maintains certain configuration information for Network Gatekeeper core services, such as routes defined for backwards compatible plug-ins, SLAs, and PRM data. The slee_db
also stores the alarm configuration and generated alarms.
Although your RDBMS server software should maintain a replicated database for a production installation, BEA recommends backing up the full slee_db
once daily, to an offline location. This provides an extra layer of protection against losing the domain-wide configuration stored in the database. Keep in mind that should you need to restore the slee_db
from a backup, you will lose any changes made to the configuration since the last scheduled backup. Because Network tier servers cache certain information from the slee_db
tables, restoring the system from a backup of slee_db
requires a full restart of the Network tier cluster to avoid inconsistencies between the cache and database tables.
The procedures for backing up the slee_db
database are specific to the type of database you have deployed: a MySQL system is backed up differently than an Oracle 10g system. To a certain extent, system backup procedures also vary depending on the type of base system and specific configurations, such as additional equipment connected to the system, and so on. The sections that follow give general recommendations about performing backups, and provide information about the tools used to support these procedures.
The sections that follow describe how to backup a single-instance Oracle 10g database. If you use an Oracle RAC database, see Backing Up An Oracle 10g RAC Database.
Use Oracle RMAN to perform the backup. Different approaches to making a backup are described in the document Oracle® Database Backup and Recovery Basics, 10g Release 1 (10.1). The backup and recovery scenarios below are based on the section, “Performing Disaster Recovery on Oracle Single instance using RMAN.”
To configure Oracle for backup, the user performing the configuration must be logged in with database administrator privileges.
To make an efficient backup, the database must:
In addition, the RMAN option CONTROLFILE AUTOBACKUP should be set to ON. The sections that follow provide more details.
The database must be running in ARCHIVELOG Mode. This makes it possible to perform on-line backups of the database. See the section “Setting the Initial Database Archiving Mode” in chapter “Managing Archived Redo Logs” in Oracle® Database Administrator's Guide 10g Release 1 (10.1).
The database should be configured to use the Flash Recovery Area. It will be used to store most of the backup and recovery-related files. See the section “Setting Up a Flash Recovery Area for RMAN” in chapter “Setting Up and Configuring Backup and Recovery” in Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1).
The RMAN configuration option, CONTROLFILE AUTOBACKUP, should be set to ON. This enables RMAN to make backups of the database Control File and Server Parameter File. See the section ‘Configuring Control File and Server Parameter File Autobackup” in chapter “Setting Up and Configuring Backup and Recovery” in Oracle® Database Backup and Recovery Basics 10g Release 1 (10.1).
rman
command.connect target
command.backup database plus archivelog
;This command returns a database identifier (DBID).
The sections that follow describe how to backup an Oracle 10g RAC database. If you use an Oracle single instance database instead, see Backing Up An Oracle 10g Single Instance Database.
Use Oracle RMAN to perform the backup. Different approaches to making backups are described in the document, Oracle® Real Application Clusters Administrator’s Guide 10g Release 1 (10.1). The backup and recovery scenarios described here are based on Oracle® Real Application Clusters Administrator’s Guide 10g Release 1 (10.1).
To configure Oracle for backup, the user performing the configuration must be logged in with database administrator privileges.
The sections that follow provide more details about these procedures.
Configure the location of the snapshot control file using the instructions given in section “Configuring the RMAN Snapshot Control File Location” in chapter “Configuring Recovery Manager and Archiving” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1).
Configure the RMAN Control file Autobackup feature according to section “Configuring the RMAN Control File Autobackup Feature” in chapter “Configuring Recovery Manager and Archiving” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1).
Configure the archive redo log according to the following sections in the chapter “Configuring Recovery Manager and Archiving” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1):
Configure the database to use a Flash Recovery Area. This area will be used to store most of the backup and recovery-related files. See the section “Using a Flash Recovery Area in Real Application Clusters” in chapter “Managing Backup and Recovery” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1).
Follow the instructions given in section “Instance Recovery in Real Application Clusters” and section “RMAN Backup Scenarios for Real Application Clusters” in chapter “Managing Backup and Recovery” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1).
Use operating system-specific tools to copy the Oracle configuration files and password files to your permanent back-up storage location.
Keep a record of the database identifier, because it is required for performing the recovery procedure.
To backup the MySQL database, first prepare the database by:
After preparing the database, use one of the available MySQL backup scripts, such as mysqldump or mysqlhotcopy, to create an offline copy of the database. The exact tool and procedure you use depends on the type of database you have created (InnoDB, MyISAM, ISAM). See Backup and Recovery in the MySQL Developer Zone to determine which backup utility and strategy best meets your needs.
You may also consider using the --log-bin
option when starting MySQL to record database updates in a binary log file. The binary log acts as an incremental backup, and it can be applied to the a full database backup to restore the database to a more recent point in time.
The procedures for database restoration depend on whether the installation uses Oracle or MySQL as a database. If the installation uses Oracle see Restoring a single instance Oracle 10g database for a single instance database or Restoring an Oracle 10g RAC database for a RAC configuration.
Although there are a number of options for restoring an Oracle database, RMAN is the preferred option for WebLogic Network Gatekeeper, as it is also the preferred option for making backups.
Note: | This section does not describe how to restore the Oracle software. Refer to the Oracle documentation for information on how to re-install the database. It is important that the database be restored to the same host (the same DNS name or IP-address) arranged with the same directory structure as the original. |
rman
connect target
SET DBID <DBID_RECORDED_DURING_BACKUP>
Use the value recorded during the backup procedure.STARTUP NOMOUNT
RESTORE SPFILE FROM '<PATH_TO_AUTOBACKUP_OF_SPFILE>';
RESTORE CONTROLFILE FROM AUTOBACKUP;
shutdown
STARTUP MOUNT
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
At this point, the database is restored, and you can restart Network tier instances.
Although there are a number of options for restoring an Oracle database, RMAN is the preferred option for WebLogic Network Gatekeeper, as it is also the preferred option for making backups. Read the instructions given in chapter “Managing Backup and Recovery” in Oracle® Real Application Clusters Administrator's Guide 10g Release 1 (10.1).
Note: | This section does not describe how to restore the Oracle software. Refer to the Oracle documentation for information on how to re-install the database. It is important that the database be restored to the same host (the same DNS name or IP-address) arranged with the same directory structure as the original. |
Below is a summary of the steps to take when performing the restoration:
connect target
SET DBID <DBID_RECORDED_DURING_BACKUP>
Use the value recorded during the backup procedure.STARTUP NOMOUNT
RESTORE SPFILE FROM '<PATH_TO_AUTOBACKUP_OF_SPFILE>';
RESTORE CONTROLFILE FROM AUTOBACKUP;
shutdown
STARTUP MOUNT
RESTORE DATABASE;
RECOVER DATABASE;
ALTER DATABASE OPEN RESETLOGS;
At this point, the database is restored, and you can restart Network tier instances.
The tools and procedures used for backing up a MySQL database vary depending on the type of database you installed. For this reason, the instructions below provide only general guidelines for restoring a database. See Backup and Recovery in the MySQL Developer Zone for more detailed instructions and examples.
Before restoring a MySQL database, shut down all Network tier server instances. Do not restart the servers until the procedure has been performed.
Begin the restoration process by deleting any existing data files and reinstalling MySQL, if necessary. A MySQL backup file generally consists of a series of SQL statements used to re-create the database at a specific point in time. Simply start the MySQL process and apply the statements from the backup file. Alternately, your backup may consist of file system-level copies of the MySQL data files. In this case, restore the files to their original location (for example, /usr/local/mysql/data
) before restarting the server.
After restoring from a backup and restarting the server, apply any incremental backups obtained from binary log files to bring the database up-to-date.
At this point, the database is restored and you can restart Network tier server instances.