• No results found

Proxy Backups and Restores

Product features 25

VMware support

NMO 4.5 provided support for regular backups and restores of an Oracle database installed on a VMware Virtual Machine (VM) on an ESX server.

NMO 5.0 extends this support with the support for the following advanced features of a VMware ESX server:

VMotion — The VMotion feature enables migration of virtual machines from one ESX server to another while the servers are on. The migration is seamless to the applications running on the virtual machines, and a user does not experience any disconnection. If a migration occurs during an NMO backup or restore, the backup or restore is not interrupted. VMware documentation provides details on the VM requirements for VMotion.

Distributed Resource Scheduler (DRS) — The DRS feature enables dynamic balancing and allocation of resources across multiple ESX servers. Depending on the DRS policies set by the user, the DRS can migrate or recommend that users migrate a virtual machine to a different ESX server by using VMotion. DRS can also start (at boot-up time) a virtual machine on a different ESX server. Since this feature uses VMotion, if a migration occurs during an NMO backup or restore, the backup or restore is not interrupted.

The NetWorker Module for Oracle release notes provides details on the NetWorker requirements for the support of VMware features.

Archived redo log backups

Archived redo log backups enable recovery of the database to its predisaster state.

Without archived redo log backups, the database can be recovered only to the time of the last consistent Oracle backup. In this case, transactions that occurred between the time of the last consistent backup and the time of the database corruption will be lost.

Archived redo logs can be backed up by using the appropriate option of the RMAN backup command. Ensure that the NMO backups of archived redo logs are enabled.

“Backing up all archived logs from each node” on page 147 provides a sample script to back up the archived redo log files in a RAC system.

The appropriate Oracle backup and recovery documentation provides more information on setting up and running archived redo log backups.

Control file autobackup

RMAN performs a control file autobackup after each RMAN backup command if the control file autobackup has been enabled with the configure controlfile autobackup on command. Use this feature to restore the backup entries contained in the control file when the control file is lost and the Recovery Catalog is not available.

Specify persistent settings for the control file autobackups with the configure controlfile autobackup command. For example, enable control file autobackup and specify the persistent setting for the format of the control file autobackup name with the following commands:

configure controlfile autobackup on

configure controlfile autobackup format for device type ’sbt_tape’ to

’/NMO_%f/’

If the control file autobackup is set to on and the RMAN backup is performed with NMO, the control file autobackup will also be performed with NMO. As a result, one or more channels of device type sbt_tape must be allocated for the restore.

Note: Oracle also supports autobackup of the current server parameter file together with control file autobackup.

Automatic channel allocation

RMAN supports automatic channel allocation. This feature enables the configuration of persistent settings for automatic channels, for use in all RMAN sessions.

IMPORTANT

!

Manual and automatic channels are mutually exclusive and cannot be mixed in an RMAN session. The format of an automatic channel name of the device type for NMO backups and restores is ORA_SBT_n or ORA_SBT_TAPE_n, where n is the channel number. Do not use this name format for manual channel allocation for NMO. Otherwise, RMAN reports an error.

With automatic channel allocation, specification of the send command before the backup or restore command causes the following error:

RMAN-06422: no channels found for SEND command

You must use the configure channel...parms... command to set the NSR* parameters for automatic channels for an NMO backup. Do not use the send command or option to set the NSR* parameters for automatic channels if you plan to use scheduled backups.

Table 10 on page 201 lists all the NSR* parameters and their requirements.

Example 1 Using the configure channel command with parms option for automatic channels Automatic channels are configured for NMO backups with the NetWorker server server1.emc.com by typing the following configure channel...parms... command:

configure channel device type ’sbt_tape’ parms

’ENV=(NSR_SERVER=server1.emc.com)’

This command sets the default parameters for all the automatic channels.

Example 2 Specifying parameter values per automatic channel

Specific NSR* parameter values can be set for different channels (for example, a separate setting of parameter NSR_GROUP for each channel) by typing the configure channel n device type...parms... command, where n represents a channel number.

An NMO debug file is specified for the second automatic channel by typing the following configure channel command:

configure channel 2 device type ’sbt_tape’ parms

’ENV=(NSR_DEBUG_FILE=/db/logs/backup.log)’

Backup and restore optimization

If backup optimization is enabled with the configure backup optimization on

Product features 27 Note:

- To force a backup that would otherwise be skipped due to backup optimization, use the force option in the backup command.

- When RMAN skips a backup due to backup optimization, it does not produce an error message. However, RMAN does issue a warning message similar to the following:

skipping archive log file...

IMPORTANT

!

When using Oracle backup optimization with NMO backups and restores, run the crosscheck command regularly to synchronize the Recovery Catalog and

NetWorker indexes. This ensures that backups expired by the NetWorker server are also marked as expired in the Recovery Catalog and RMAN does not skip a backup when a referenced backup has already expired in NetWorker.

The restore optimization function prevents RMAN from restoring a file if the original file is already in the correct location and contains the expected information.

Note: To force a restore that would otherwise be skipped due to restore optimization, use the force option in the restore command.

Backup copies

IMPORTANT

!

If more than one RMAN channel is used for backup copies of an NMO backup, parameter values set with the send command or option are passed by RMAN to the first backup channel only. Due to this send command limitation, NMO does not support the use of RMAN backup copies commands during scheduled backups.

NMO supports backup copies with manual backups only.

Use the RMAN commands for backup copies only during manual backups when the parameters NSR_SERVER, NSR_DATA_VOLUME_POOL,

NSR_DATA_VOLUME_POOL1, NSR_DATA_VOLUME_POOL2, and

NSR_DATA_VOLUME_POOL3 are set with the parms option, not with the send command or option.

The set duplex command is deprecated (no longer supported by Oracle, but still functional in some Oracle releases). The Oracle documentation provides more details.

Despite the fact that RMAN provides different commands for duplexing backups, the rules for duplexing through NMO remain the same as with the set duplex command.

Separate NetWorker pools must still be defined for each copy. “The set duplex command” on page 215 provides more information on the set duplex command and setting up NetWorker pools for each copy.

Manual backups can be duplexed (up to four copies) by using one of the following commands:

The configure...backup copies for device type sbt_tape to... command specifies persistent settings for duplexing backups through NMO.

For example, specify persistent settings for duplex copies of datafiles and archived redo logs (respectively) in NMO backups with the following types of configure commands:

configure datafile backup copies for device type ’sbt_tape’ to 2 configure archivelog backup copies for device type ’sbt_tape’ to 2

The backup command with the copies option applies to objects within the backup command. The backup...copies setting takes precedence over the persistent settings in the configure...backup copies command.

The set backup copies command applies to all backup objects in the same run job.

In the following examples, the parms option is used to configure the channel and set the required parameters. These sample scripts must be invoked manually with RMAN, for example, by using the following command:

rman cmdfile script_name

Example 3 Using the set backup copies command in the RMAN script

The following RMAN script uses the set backup copies command to generate the backup copies. The parameters are set with the parms option, as required. The RMAN script must be invoked for a manual backup, not a scheduled backup:

run {

set backup copies 4;

allocate channel ch1 parms ’ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmo1, NSR_DATA_VOLUME_POOL1=nmo2, NSR_DATA_VOLUME_POOL2=nmo3, NSR_DATA_VOLUME_POOL3=nmo4)’;

backup format '%d_%U' tag tag_name

(tablespace 'SYSTEM' );

release channel ch1;

}

Example 4 Using automatic channels for backup copies

The following configure commands are used to configure RMAN automatic

channels. (The configure commands could also be included in the RMAN script.) The configure...backup copies command generates the backup copies. The parameters are set with the parms option, as required. The RMAN script must be invoked for a manual backup, not a scheduled backup:

configure default device type to ’sbt_tape’;

configure datafile backup copies for device type ’sbt_tape’ to 4;

configure channel device type ’sbt_tape’ parms

’ENV=(NSR_SERVER=server_name, NSR_DATA_VOLUME_POOL=nmo1, NSR_DATA_VOLUME_POOL1=nmo2, NSR_DATA_VOLUME_POOL2=nmo3, NSR_DATA_VOLUME_POOL3=nmo4)’;

Product features 29

The RMAN script invoked for the manual backup is as follows:

connect target sys/oracle@test;

RMAN supports the backup of backup sets. If Oracle data has been backed up with device type disk, NMO can be used to back up these backup sets from disk to NetWorker volumes.

For example, to back up all backup sets from disk to NetWorker volumes in a tape device, use the following command:

backup device type sbt backupset all

The backup set on disk can also be deleted with the delete input option in the backup device type sbt backupset... command. For example, to back up the backup sets that were created on disk more than a week ago and then remove the backup sets from disk, use the following command:

backup device type sbt backupset completed before sysdate-7 delete input

Cluster and RAC backups and restores

The NMO software supports backups and restores of cluster and Real Application Cluster (RAC) systems for high availability and parallelism.

A cluster system typically includes multiple nodes connected by a shared SCSI bus to which common storage is attached. Cluster services such as disk services can be defined and assigned their own IP addresses and names (virtual hosts). The services and their associated storage can migrate for failover between the physical nodes in the cluster.

After a cluster service is configured as a NetWorker client, NMO can be used with NetWorker server software to back up and restore an Oracle database associated with the service, independent of the actual node that provides the service.

A RAC system enables multiple Oracle instances across multiples nodes to access the same Oracle database at the same time. Oracle RAC is based on a cluster software infrastructure that provides concurrent access to the same storage and the same set of datafiles from all nodes in the cluster. All the database files reside on cluster-aware shared disks.

After RAC and the associated cluster system are properly configured, NMO enables Oracle backups on either a single node or several nodes of the RAC system. A parallel Oracle backup uses Oracle instances running in parallel on multiple nodes of the cluster.

NMO software supports restores of the Oracle data to any physical node in the cluster, regardless of which physical node originally performed the backup.

Chapter 6, “Cluster and RAC Systems,” provides more information on cluster and RAC systems and how to configure the systems for Oracle backup and restore operations that use the NMO software.

Configuration wizards

NMO 5.0 software supports new backup and recovery configuration wizards that are integrated with the NetWorker Management Console (NMC). The configuration wizards used in NMO release 4.5 or earlier are replaced by the NMC-based wizards in NMO release 5.0.

Configuration wizard plug-in components are installed with the NMO software on the NMO client host. NMC loads the NMO wizard plug-in at run time. You can run the NMO wizards from the NetWorker Console Administration window, which you can start on any supported host by using a web browser session and specifying the Console server URL.

The NetWorker Module for Oracle release notes provides details on the NetWorker requirements for the support of the NMC-based configuration wizards.

Main features of the wizards

The configuration wizards can be used to configure the following for an NMO client:

Scheduled Oracle backups (either typical or customized).

“Configuring a backup with the NMC wizard” on page 72 provides details on using the backup configuration wizard.

RMAN scripts for Oracle data restores to the original host.

RMAN scripts for Oracle database duplication to either a local or remote host.

“Recovery configuration wizard” on page 118 provides details on the recovery configuration wizard.

The configuration wizards support NetWorker servers and clients in a stand-alone or cluster environment.

The new wizards provide improved security and ease of management for backup and recovery configurations, compared to the wizards from NMO release 4.5 or earlier.

Features of the backup configuration wizard

The backup configuration wizard can perform the following:

Configure a new NetWorker Client resource for an NMO backup.

Configure a new or use an existing NetWorker Group resource for the backup Client resource.

Configure new or use existing browse and retention policies for the backup Client resource.

Optionally save a copy of the configuration settings from the Client resource to a nsrnmo script or RMAN script.

Modify a backup configuration that was created with the NMC-based NMO configuration wizard.

Modify a backup configuration that was created either with the wizard from NMO release 4.5 or earlier, or with the legacy method, but only after the configuration has been migrated according to “Migration of configurations for the wizard” on page 32.

Product features 31 Note: NMO 5.0 still supports the legacy method of backup configuration whereby you manually create a nsrnmo script and RMAN script, set any required parameters in the NWORA resource file, and configure the NetWorker resources with NMC (without the wizard). “Configuring a backup with the NMC legacy method” on page 75 describes the legacy configuration method.

“Configuring a backup with the NMC wizard” on page 72 provides information on using the wizard to create or modify a backup configuration.

Features of the recovery configuration wizard

“Features of the recovery configuration wizard” on page 119 provides information on the features of the recovery configuration wizard.

Backup configuration storage with the wizard

The backup configuration wizard stores the configuration information in a new hidden attribute named Backup Config in the NetWorker Client resource. Do not modify the new attribute manually. If you use the wizard to create a backup configuration, you must use the wizard to modify the configuration.

In a backup configuration created with the wizard, the Client resource stores the parameters and RMAN commands (except for sensitive data, such as passwords) that would have been stored in the nsrnmo and RMAN scripts and NWORA resource file in NMO release 4.5 or earlier.

Note: The backup configuration wizard stores sensitive data securely by using NetWorker lockbox services.

The wizard does not automatically generate a nsrnmo script and RMAN script, but provides an option to save configuration settings to a nsrnmo script or RMAN script on disk. These scripts are meant for reference use only.

When you run a backup that was configured through the wizard, the backup does not access any nsrnmo or RMAN script file that the wizard saved to disk. Instead, the backup accesses the configuration information that the wizard stored in the Client resource.

The wizards do not store any database connection passwords in any RMAN scripts that are saved to disk.

The backup configuration wizard also sets the following values in the Client resource:

Backup Command attribute is set to:

nsrnmostart -C [-c virtual_client]

Save Set attribute is set to:

RMAN:/<database_Net_service_name>_level[/<name_of_first_tablespace _or_datafile>]

where:

• database_Net_service_name is the the name of the Oracle database to be backed up.

• level is the Oracle backup level (full, incr_differential, or incr_cumulative).

• name_of_first_tablespace_or_datafile is the name of the first tablespace or datafile in the backup list. This name is included in Save Set attribute only if a partial database (subset of the entire database) is selected for backup.

Features not supported with the wizards

The configuration wizards cannot perform the following:

Configure backups or restores in a RAC environment.

Configure proxy backups or restores that require a PowerSnap Module.

Proxy backups and restores must be configured without the wizard, as described in Chapter 7, “Proxy Backups and Restores.”

Configure two different database backups in the same Client resource.

A separate Client resource must be created for each database to be backed up on the same client host.

Modify a backup configuration that was created either with the wizard from NMO 4.5 or earlier, or with the legacy method, unless the configuration has been migrated according to “Migration of configurations for the wizard” on page 32.

Migration of configurations for the wizard

The backup configuration wizard stores the scheduled backup configuration in the Client resource by using a configuration storage framework that is incompatible with the configurations created either through the wizard from NMO release 4.5 or earlier, or through a legacy method (without a wizard).

The backup configuration wizard can modify only the following types of backup configurations:

Configurations created with the new wizard.

Configurations migrated to the configuration storage framework that is supported by the new wizard.

If you have a backup configuration that was created with the wizard from NMO release 4.5 or earlier, or with a legacy configuration method, you must migrate the configuration before you can use the new wizard to modify it. The recommended migration method is to use the nsrnmoadmin command, as described in “Migrating a legacy configuration with the nsrnmoadmin command” on page 69.

Note: Migration of a proxy backup configuration is not supported. “Requirements for using the nsrnmoadmin command for migration” on page 70 describes the requirements and limitations of migration with the nsrnmoadmin command.

Migration converts legacy configuration files and resources (the nsrnmo script, RMAN script, NWORA resource file, and Client resource) to the configuration storage framework used by the new wizard. Migration with the nsrnmoadmin command does not create a new Client resource; the migration modifies an existing Client resource, such that you can then use the wizard to modify it.

The migration process stores the following in a hidden attribute in the Client resource:

Environment variable settings extracted from the nsrnmo script. (Any scripting commands in the nsrnmo script are ignored.)

RMAN commands and options extracted from the RMAN script.

RMAN commands and options extracted from the RMAN script.

Related documents