Veritas NetBackup™ for Oracle Administrator's Guide
- Introduction
- What's new about NetBackup for Oracle
- About NetBackup for Oracle
- NetBackup for Oracle features
- NetBackup for Oracle terminology
- NetBackup for Oracle operation using the Oracle Intelligent Policy
- Logging the RMAN input and output on a client
- NetBackup for Oracle operation using a script- or template-based policy
- About Oracle RMAN
- About the Oracle recovery catalog
- NetBackup for Oracle QuickStart
- Installing NetBackup for Oracle
- Verifying the operating system and platform compatibility
- NetBackup server and client requirements
- Requirements for using NetBackup for Oracle in a NetBackup cluster
- About the license for NetBackup for Oracle
- About linking Oracle RMAN with NetBackup for UNIX
- Oracle policy configuration
- Preparing for NetBackup for Oracle configuration
- Instance management for an Oracle Intelligent Policy
- About the NetBackup Discovery Service
- Viewing the Oracle database instance repository
- Manually adding an Oracle database instance to the repository
- Registering an Oracle database instance
- About Oracle database instance groups
- Adding an instance to an instance group
- Automatic Registration of an instance group
- About instance actions
- About Oracle Intelligent Policies (OIP)
- Creating an Oracle Intelligent Policy (OIP)
- Oracle database upgrade effect on Oracle Intelligent Policies
- Configuring NetBackup for Oracle automatic backup schedules
- About NetBackup for Oracle schedule properties using Oracle Intelligent Policy
- Oracle Intelligent Policy - Storage and Retention
- About Oracle Intelligent Policy master server behavior
- Instances and Databases tab
- Backup Selections tab
- Oracle tab
- About using a NetBackup appliance share for Oracle backups (Copilot)
- Configuring an OIP using a share on the NetBackup appliance (Copilot)
- About script- or template-based Oracle policies
- Adding a new script- or template-based Oracle policy
- About policy attributes
- About backup schedules, templates, and scripts
- About schedule properties
- Script- or template-based policy - Storage and Retention
- Adding clients to a policy
- About adding backup selections to an Oracle policy
- About configuring the run-time environment
- About creating templates and shell scripts
- Starting the NetBackup Backup, Archive, and Restore interface
- RMAN templates and shell scripts
- Creating RMAN templates using the NetBackup for Oracle RMAN template generation wizard
- Creating an RMAN script from a template
- About creating RMAN scripts manually
- About storing templates
- About storing shell scripts
- Configuring the logon account for the NetBackup Client Service for NetBackup for Oracle
- Testing configuration settings for NetBackup for Oracle
- Performing backups and restores of Oracle
- Overview of using NetBackup for Oracle
- Maintaining the RMAN repository
- Querying the RMAN repository
- About NetBackup for Oracle backups
- Browsing backups using the bplist command
- Managing expired backup images
- About NetBackup for Oracle restores
- Using NetBackup for Oracle in a Microsoft Windows cluster environment
- Creating an instant recovery point from an Oracle Copilot image
- Deleting an instant recovery point for Oracle Copilot instant recovery
- Cleaning up the Copilot share after point in time restore of database
- Single-step restore to ASM storage from a Copilot recovery point
- About restoring from a data file copy to ASM storage using RMAN
- Guided Recovery
- About OpsCenter Guided Recovery
- Setting up for Guided Recovery cloning
- Guided Recovery cloning pre-operation checks
- Performing a Guided Recovery cloning operation
- Select a Master Server dialog
- Select Source Database panel
- Select Control File Backup panel
- Destination host and login panel
- Destination Parameters panel
- Selection summary panel
- Pre-clone check panel
- Job Details panel
- Guided Recovery post-clone operations
- 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 the NetBackup for Oracle backup and restore operations
- Database objects supported by advanced backup methods
- About NetBackup multistreaming
- RMAN multiple channels
- Restoring data files to a new location
- Redirecting a restore to a different client
- Symbolic links and raw data files (UNIX)
- Quick I/O data files (UNIX)
- RMAN incremental backups
- Proxy backup examples
- About configuring Snapshot Client with NetBackup for Oracle
- Restoring NetBackup for Oracle from a snapshot backup
- About configuring NetBackup for Oracle block-level incremental backups on UNIX
- About Snapshot Client effects
- About Oracle support for Replication Director
- Troubleshooting
- About troubleshooting NetBackup for Oracle
- About NetBackup for Oracle troubleshooting steps
- NetBackup debug logs and reports
- Enabling the debug logs manually (Windows)
- Enabling the debug logs manually (UNIX)
- About the NetBackup for Oracle log files
- Setting the debug level on a Windows client
- Setting the debug level on a UNIX client
- About RMAN utility logs
- Troubleshooting RMAN backup or restore errors
- Troubleshooting the UNIX browser interface and wizards
- Troubleshooting NetBackup for Oracle with Snapshot Client
- Minimizing timeout failures on large database restores
- Minimizing the loading and unloading of tapes for database backups
- Delays in backup job transfer and completion
- Appendix A. Real Application Clusters
- Appendix B. Best practices for protecting Oracle RAC with NetBackup
- Oracle RAC with NetBackup best practices
- About using Templates and Oracle Intelligent Policy (OIP) with RAC
- About NetBackup for Oracle operations
- Example RAC configuration: Failover name exists and backup is not load balanced
- Example RAC configuration: Failover name exists and backup is load balanced
- Example RAC configuration: Failover name is not available and backup is not load balanced
- Example RAC configuration: Failover name is not available, and backup is load balanced, one policy with custom script
- Example RAC configuration: Failover name is not available and backup is load balanced, simple script with manual policy failover
- Image catalog configuration for RAC
- Configuring the appliance within a RAC environment
- 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
- About script-based block-level incremental (BLI) backups without RMAN
- About BLI backup and restore operations
- Verifying installation requirements for BLI backups without RMAN
- Creating NetBackup policies for script-based BLI backup
- Number of policies required for BLI backup
- About BLI policy attributes
- About the BLI client list
- Backup selections list for BLI backups
- About schedules for BLI backup policies
- Example Oracle BLI backup policy
- Setting the maximum jobs per client global attribute
- About BLI backup methods
- 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 the environment variables set by a user in the XML export parameter file
- About XML export templates and shell scripts
- Performing an XML export archive
- Browsing XML export archives using bporaimp parameters
- Browsing XML export archives using bplist
- Restoring an XML export archive
- Troubleshooting XML export or XML import errors
- Additional XML export and import logs
- 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
Note:
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:
racclient1
racclient2
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:
Windows:
dir install_path\Veritas\NetBackup\db\images\racclient1 dir install_path\Veritas\NetBackup\db\images\racclient2 dir install_path\Veritas\NetBackup\db\images\racname
UNIX:
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
Note:
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.
https://www.veritas.com/docs/000018409
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.
Windows:
cd install_path\Veritas\NetBackup\db\altnames echo racname >> peername_racclient1 echo racname >> peername_racclient2
UNIX:
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: