Veritas NetBackup™ for Oracle Administrator's Guide
- NetBackup for Oracle QuickStart
- Installing NetBackup for Oracle
- About linking Oracle RMAN with NetBackup for UNIX
- Linking Oracle RMAN with NetBackup on UNIX platforms
- Oracle policy configuration
- Preparing for NetBackup for Oracle configuration
- Instance management for an Oracle Intelligent Policy
- About Oracle Intelligent Policies (OIP)
- About script- or template-based Oracle policies
- About adding backup selections to an Oracle policy
- About configuring the run-time environment
- About creating templates and shell scripts
- About creating RMAN scripts manually
- Performing backups and restores of Oracle
- About NetBackup for Oracle backups
- About NetBackup for Oracle restores
- Redirecting a restore to a different client
- Using NetBackup for Oracle in a Microsoft Windows cluster environment
- Guided Recovery
- Troubleshooting Guided Recovery
- NetBackup for Oracle with Snapshot Client
- About NetBackup for Oracle with Snapshot Client
- How NetBackup for Oracle with Snapshot Client works
- About configuring Snapshot Client with NetBackup for Oracle
- Restoring NetBackup for Oracle from a snapshot backup
- About NetBackup for Oracle restores of volumes and file systems using snapshot rollback
- About configuring NetBackup for Oracle block-level incremental backups on UNIX
- About Snapshot Client effects
- About Oracle support for Replication Director
- Troubleshooting RMAN backup or restore errors
- Appendix A. Real Application Clusters
- Appendix B. Best practices for protecting Oracle RAC with NetBackup
- Appendix C. Deduplication best practices
- Appendix D. Snapshot Client support of SFRAC
- Appendix E. Script-based block-level incremental (BLI) backups without RMAN on UNIX and Linux systems
- Verifying installation requirements for BLI backups without RMAN
- Creating NetBackup policies for script-based BLI backup
- Creating notify scripts for BLI backups
- Performing backups and restores
- About troubleshooting backup or restore errors
- Appendix F. XML Archiver
- NetBackup for Oracle XML export and XML import
- About XML export templates and shell scripts
- Performing an XML export archive
- Restoring an XML export archive
- About redirecting a restore of an XML export archive to a different client
- Troubleshooting XML export or XML import errors
- Appendix G. Register authorized locations
Example RAC configuration: Failover name exists and backup is load balanced
In this configuration, the NetBackup master server can always use the failover name to reach an active host to run the backup script. However, because RMAN allocates channels on both hosts, the NetBackup media server must connect back to the correct host to obtain the data for each request. Hence, the backup images are stored under two different client names which must differ from the failover name that is used to execute the script.
Set up the policy to specify the failover name as the client name. Thus, the Automatic schedule executes the backup script on a host that is currently operational.
The backup script or an identical copy must be accessible to all hosts in the cluster. The clustered file system is a good location.
Do not configure the backup script to send a single value for NB_ORA_CLIENT. The NetBackup media server must connect back to the correct host, which depends on which host originated the user-directed backup request. Select one of the following three methods to accomplish this task:
Configure the backup to provide a host-specific client name with each backup request using one of the following three options:
Configure RMAN to bind specific channels to specific instances and provide the associated client names on each channel for backup image storage. Also, configure RMAN for connect-back to the requesting host for the data transfer. Do not use the failover name, because it is active on only one of the hosts.
ALLOCATE CHANNEL 1 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 2 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2'; ALLOCATE CHANNEL 3 ... PARMS='ENV=(NB_ORA_CLIENT=vipname1)' CONNECT='sys/passwd@vipname1'; ALLOCATE CHANNEL 4 ... PARMS='ENV=(NB_ORA_CLIENT=vipname2)' CONNECT='sys/passwd@vipname2';
If one or more of these nodes are down, these allocation operations fail which causes the backup to fail.
Alternatively, configure Oracle to bind specific channels to specific hosts.
CONFIGURE CHANNEL 1 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 2 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)"; CONFIGURE CHANNEL 3 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname1' PARMS "ENV=(NB_ORA_CLIENT=vipname1)"; CONFIGURE CHANNEL 4 DEVICE TYPE 'SBT_TAPE' CONNECT 'sys/passwd@vipname2' PARMS "ENV=(NB_ORA_CLIENT=vipname2)";
Alternatively and by default, the backup uses the client names which should be distinct for each host and is typically the physical host name.
Because CLIENT_NAME or NB_ORA_CLIENT values must differ from the failover name in the policy, the NetBackup master server cannot accept the user-directed backup request. You must implement one of the following options.
: Modify the existing policy and the backup script to handle multiple client names.
Add both VIP names or both host names to the policy, in addition to the failover name.
Modify the script so that it exits with status 0 if the client name is not the failover name.
: Alternatively, use a separate policy to accept the backup requests.
Create a second policy to receive the backup requests from RMAN.
Set the policy type to be Oracle.
Set the policy to contain the NB_ORA_CLIENT or client names as configured in the previous information.
The Application Backup schedule must have an open window to accept the backups.
The policy does not need a backup script or an automatic schedule.
Configure the backup script to provide the name of this policy with each user-directed backup request:
ALLOCATE CHANNEL...PARMS='ENV=(NB_ORA_POLICY=<second_policy_name>)'; or SEND 'NB_ORA_POLICY=<second_policy_name>';
The NetBackup master server configuration must allow the physical host names access to the backup images. The images are stored under the VIP names or host names as follows:
cd /usr/openv/netbackup/db/altnames echo "failover_name" >> hostname1 echo "hostname1" >> hostname1 echo "vipname1" >> hostname1 echo "hostname2" >> hostname1 echo "vipname2" >> hostname1 cp hostname1 hostname2
You can use Preferred Network or another means to force NetBackup to use the IP addresses associated with the VIP names for outbound user-directed requests. If you use this method then you must allow the VIP names to access all of the backup images.
cd /usr/openv/netbackup/db/altnames cp hostname1 vipname1 cp hostname1 vipname2
: The NetBackup scheduler starts three automatic jobs, and each runs the backup script (two of them on the host that currently hosts the failover name). The two executions of the backup script that receive the VIP names or host names exit immediately with status 0. The reason immediate exit is done is to avoid a redundant backup and any retries. The third execution of the backup script that receives the failover name, starts RMAN. RMAN then sends the data for backup by using the appropriate client name for the instance or host for the channel. NetBackup stores the backup images under the initiating policy using both client names.
: The first policy runs the backup script by using the failover name. RMAN sends the name of the second policy and the configured client names for each channel with the user-directed request from each host. The second policy stores the backup images using both client names.
Either client can initiate a restore. RMAN must be configured with 'SET AUTOLOCATE ON;' to request the backup pieces from the appropriate instance-host that performed the backup. Alternatively, you can restore from either host or instance if you configure each restore request to include the correct client name. This name is the client name used at the time the backup piece was transferred to storage.