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 is not available and backup is load balanced, simple script with manual policy failover
Some implementations of RAC (Linux/Windows) do not include a failover name. Also, some sites do not need a robust backup script that determines the active instance in real time. If this scenario is the case, use the following configuration to manually initiate a backup from the secondary host when the primary host is down.
Create a first Oracle policy with an Application Backup schedule to receive the backup images from both hosts. Configure both VIP names or the host names as clients in the policy. Do not configure an Automatic Backup schedule or a backup selection (script).
Create a second Oracle policy to execute the backup script on the primary host. Configure the VIP name or host name of the primary host in the policy. Configure the pathname to the backup script in the policy. Create an Automatic Backup schedule with an open window in the policy.
Create a third Oracle policy that can be used to manually execute the backup script on the secondary host when the primary host is unavailable. Configure the VIP name or host name of the secondary host in the policy. Configure the pathname to the backup script in the policy. Create an Automatic Backup schedule without an open window in the policy.
The backup script must be accessible to both hosts in the cluster, the clustered file system makes a good location.
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.
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.
Configure the NetBackup master server to allow the physical host names access to all of the backup images.
cd /usr/opnv/netbackup/db/altnames echo "hostname1" >> hostname1 echo "vipname1" >> hostname1 echo "hostname2" >> hostname1 echo "vipname2" >> hostname1 cp hostname1 hostname2
Although not recommended, 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 second policy executes the backup script on the primary host when it is scheduled. RMAN starts the backup process on all of the hosts, and they send back the appropriate NB_ORA_CLIENT or CLIENT_NAME for that host. If the primary is down, initiate the third policy manually from the NetBackup master server and perform a similar backup.
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.