Ransomware attackers specifically target and attempt to destroy backup systems to increase the probability of payment. Hardening your system is critical. Please ensure you have reviewed your platform security using the Security Hardening Checklist
Cohesity

COHESITY Documentation

Explore our documentation to get started, discover products & new features, access troubleshooting guides, register sources, platforms support.

Products
Data Security Alliance
Visit Cohesity.com
Demos
Support
Blogs
Developers
Partner Portals
Cohesity Community
© 2026 Cohesity, Inc. All Rights Reserved.
Terms of Use|
Privacy Policy|
Legal|
  1. Home
  2. Veritas NetBackup™ for Oracle Administrator's Guide
  3. Appendix B. Best practices for protecting Oracle RAC with NetBackup
  4. Example RAC configuration: Failover name is not available and backup is load balanced, simple script with manual policy failover
Veritas NetBackup™ for Oracle Administrator's Guide

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';

      Note:

      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.

SEND 'NB_ORA_CLIENT=client_name_used_by_backup';

Feedback

Was this page helpful?
Previous

Example RAC configuration: Failover name is not available, and backup is load balanced, one policy with custom script

Next

Image catalog configuration for RAC

Feedback

Was this page helpful?