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
Image catalog configuration for RAC
If the RAC backup used a failover name as the NB_ORA_CLIENT, then the backup images from all nodes are stored under that single client name. Because the backup images are stored under a single client name, the image catalog does not need any special configuration.
However, if a failover name was not used, then the backup images for individual clients are stored in uniquely named image directories. This configuration can cause complications when an operation such as crosscheck or restore are performed from an alternate cluster or an alternate node within the cluster
This technique works best when you use the VIP names for the instances as the racclient names. If you use physical host names, the backup images from file system backups are stored with the Oracle backup images within a single image directory. This situation can result in two potential problems. First, if the same file name exists on both hosts but with different content, care must be used to select the correct backup image from which to restore. The selection confusion can be eliminated by configuring the file system backup to specify a policy keyword. The keyword is specific to the host from which each file system backup is taken. Then use the host-specific keyword to constrain the image search when performing browse and restore. Second, either host can restore the files that were backed up from the other host. Being part of the same cluster, this restore technique is normally not a concern. But be aware in case there are special considerations for permissions and security restrictions at your site.
The following procedure can be used to centralize storage of the backup images from all nodes in the cluster under one client name. That single client name can then be used for maintenance and restore operations.
In the following procedure, all steps are performed on the master server unless otherwise noted. Also, the procedure uses two examples of network host names that are routable:
In this procedure, the logical name for the cluster is racname. If there is a failover name that is always active on a node in the cluster, then it could be used as the racname. Alternatively, the racname can temporarily be added as a host name alias for racclient1 or racclient2 to complete the initial configuration and then be removed.
To centralize storage of the backup images from all nodes in the cluster under one client name
- On both the master and the media server, confirm that the RAC client names are resolvable, network routable, and reverse resolve accurately:
bpclntcmd - hn racclient1 bpclntcmd - hn racclient2 ping racclient1 ping racclient2 bpclntcmd - ip <ip_address_for_racclient1> bpclntcmd - ip <ip_address_for_racclient2>
Fix any host name forward and reverse resolution inconsistencies, and any network routing problems. Be sure to clear the NetBackup host cache and wait 10 seconds after making any name resolution changes:
bpclntcmd - clear_host_cache
- On the master server, check if image directories or client aliases already exist for either of the racclients or the logical name for the cluster:
dir install_path\Veritas\NetBackup\db\images\racclient1 dir install_path\Veritas\NetBackup\db\images\racclient2 dir install_path\Veritas\NetBackup\db\images\racname
ls -ld /usr/openv/netbackup/db/images/racclient1 ls -ld /usr/openv/netbackup/db/images/racclient2 ls -ld /usr/openv/netbackup/db/images/racname
Windows or UNIX:
bpclient - client racclient1 - list_all_aliases bpclient - client racclient2 - list_all_aliases bpclient - client racname - list_all_aliases
Do not continue this procedure if either of the client names already have image directories or are aliases to a client name other than the racname.
Instead of using this procedure, consider merging the existing image directories and client names per the following Veritas knowledge base article.
Alternatively, create new network resolvable and network routable host names for the RAC clients and return to step 1.
- If the logical cluster name already had an image directory and is an alias for itself, then skip to step 5.
- Run a backup using the logical cluster name as a NetBackup client name.
If the racname is not a resolvable host name, temporarily make it a host name alias for the host name of one of the RAC client names. Changing the host name alias is most easily done my modifying the hosts file.
The backup should be a file system backup using a new or an existing policy, it can be a backup of only one file.
Afterward, make sure the racname has an image directory and client alias per the checks in step 2. Then remove any temporary host name alias or policy that was created.
- Direct future backups and image searches for racclient1 and racclient2 to the logical cluster name.
Create the client aliases for the cluster and confirm:
bpclient - client racname - add_alias racclient1 bpclient - client racname - add_alias racclient2
bpclient - client racname - list_all_aliases bpclient - client racclient1 - list_all_aliases bpclient - client racclient2 - list_all_aliases
If problems are encountered, refer to the following tech note:
- Create or modify an Oracle policy for the RAC, specify racclient1 and racclient2 as the clients.
For more information on policy and RMAN configuration techniques,
- Ensure that the policy is active and run a backup of the RAC using the policy.
- Allow the client hosts to use NB_ORA_CLIENT=racname during crosscheck and restore operations. These altname files are created on the master server. The peername is the host name to which the master server resolves the source IP address from which each client connects to the master. The peername is easily determined when you run bpclntcmd -pn on each client host.
cd install_path\Veritas\NetBackup\db\altnames echo racname >> peername_racclient1 echo racname >> peername_racclient2
cd /usr/openv/netbackup/db/altnames echo racname >> peername_racclient1 echo racname >> peername_racclient2
From racclient1, the peername is 'racclient1.com':
$ bpclntcmd -pn expecting response from server mymaster racclient1.com racclient1 192.168.0.11 60108
For more information about client alias best practices, refer to the following tech note: