Forum Stats

  • 3,741,953 Users
  • 2,248,511 Discussions
  • 7,862,086 Comments

Discussions

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Log In Register

Categories

Oracle Optimized Solution for Secure Backup and Recovery, Part 2

steph-choyer-Oracle
steph-choyer-Oracle Member Posts: 101
edited May 10, 2017 4:15AM in Optimized Solutions

by Dean Halbeisen

This article is Part 2 of a three-part series that describes how Oracle Optimized Solution for Secure Backup and Recovery delivers end-to-end data protection with high availability and security for Oracle's engineered systems and other Oracle Optimized Solutions.

Backup Best Practices

While in-depth coverage of backup best practices for each configuration of Oracle Optimized Solution for Secure Backup and Recovery is out of the scope of this document, some recommended best practices are discussed in the following sections, along with information on where to find thorough best practices for each configuration.

The articles in this series are located here:

OOS_Logo_small125.png
Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

Table of Contents
image

Best Practices for Accomplishing Recovery Time and Recovery Point Objectives

Oracle offers a complete technology stack composed of hardware and software. Tightly integrated, the multiple layers of the stack contain tools for data protection and backup and recovery. Important tools can be found at the application, database, operating system, virtualization, and storage levels, as shown in Figure 1. Following best practices and combining these tools effectively can result in an optimal solution for backing up Oracle systems. In fact, by not relying on any single tool, it is possible to create an ideal data protection environment that reduces reliance on conventional backups.

f1.png

Figure 1. Oracle offers data protection tools at various levels of the integrated stack.

Among the tools from each layer are the following:

  • Software tools: Oracle Secure Backup and third-party backup software
  • Database tools: Oracle RMAN and the following features of Oracle Database: Oracle Archive Log Mode, Data Guard, Oracle Flashback Database, and Data Recovery Advisor
  • Operating system tools: Built-in backup and recovery tools, ZFS snapshots, and alternate boot environments (a boot environment is an Oracle Solaris operating system tool)
  • Storage tools: Exadata Storage Expansion Racks, Oracle ZFS Storage Appliance systems, and StorageTek Tape storage

Using a Combination of Software Tools

The tools within the different layers of Oracle's stack can be used to help achieve diverse—and precise—recovery time and recovery point objectives. By using various tools listed below, it is possible to protect valuable enterprise data and production environments without relying on conventional—and lengthier—backup and restore operations.

  • Oracle Flashback Database and Data Guard can help IT staff recover from logical errors and database outages for recovery time objectives of 15 minutes to an hour.
  • Oracle Archive Log Mode enables the database to be rolled back to any point in time within the recovery window to meet specific recovery point objectives.
  • Oracle Enterprise Manager Ops Center enables administrators to deploy Oracle Solaris and Oracle Linux operating systems for fast operating system recovery.
  • The default file system in Oracle Solaris 11 is ZFS, which supports snapshots, cloning, and replication. ZFS provides the ability at the operating system level to utilize built-in commands for snapshots, cloning, and replication.
  • Oracle ZFS Storage Appliance systems support snapshots, cloning, and replication for specific recovery points. Administrators can take a snapshot of an iSCSI LUN on an Oracle ZFS Storage Appliance system to create a backup. Alternatively, deploying a remote Oracle ZFS Storage Appliance system enables recovery in seconds by switching from the primary to the remote appliance.

Best Practices for Backup and Recovery in Virtualized Environments or with Unstructured Data

When performing backup and recovery in virtualized environments or in environments with unstructured (nondatabase) data, traditional approaches consist of taking disks and applications offline and writing from disk to tape. In the real world, however, organizations require 24/7 availability and cannot afford to take applications offline at all. Oracle Solaris 11 uses Oracle Solaris ZFS (ZFS) as the default file system and ZFS provides features for capturing a system snapshot that can be sent to an external Oracle ZFS Storage Appliance system or stored on tape.

Oracle Optimized Solution for Secure Backup and Recovery is configured with an internal Oracle ZFS Storage Appliance system that can store the virtualized environments and file system snapshots. Oracle recommends the use of these snapshots to maintain application availability while obtaining a copy of vital data.

Best Practices for Backup and Recovery in Virtualized Environments and Unstructured Data with NDMP

NDMP is an open-standard protocol for network-based backup of network-attached storage (NAS) devices. It facilitates interoperation of backup software and NAS hardware. Because NAS devices are not intended to host applications such as backup software agents and clients, they cannot be set up as backup clients for software such as Oracle Secure Backup. Instead, an NDMP service is created on the NAS device, using NDMP host types to designate an Oracle ZFS Storage Appliance system as the backup target. These host types require the use of specific path names. Please refer to My Oracle Support Note 1558851.1 for examples.

Best Practices for a Secure Backup and Recovery Implementation

Backup and recovery systems cannot rely solely on perimeter security. A combination of system-wide security measures and best practices—including the rule of least privilege, strong authentication, access control, encryption, auditing, disabling of unnecessary services, antimalware protections, and configuring system services for enhanced security—should also be implemented for secure operations.

Oracle highly recommends leveraging existing recommendations and guidelines from product security guides, Center for Internet Security (CIS) benchmarks, ISACA publications, and Department of Defense (DoD) Security Technical Implementation Guides (STIGs) when designing a backup and recovery environment.

Security Technical Implementation Guides

STIGs are continually updated and currently available for many Oracle products. Here is a list of STIGs relevant to this solution:

For more STIGs, please see the STIG website.

Component-Level Security Recommendations

Oracle recommends the following component-level security guidelines.

  • Change system default passwords. Using known vendor-provided default passwords is a common way cybercriminals gain unauthorized access to infrastructure components. Changing all default passwords to stronger, custom passwords is a mandatory step during infrastructure deployment.
  • Keep component patching current. Ensure that all components are using the most recent firmware and software versions to the extent possible. This tactic ensures that each component is protected by the latest security patches and vulnerability fixes.
  • Leverage isolated, purpose-based network interfaces. Network interfaces, virtual or physical, should be used to separate architectural tiers, such as client access and management. In addition, consider using network interfaces to separate tiers within a multitier architecture. This enables per-tier security policy monitoring and enforcement mechanisms including network, application, and database firewalls as well as intrusion detection and prevention systems.
  • Enable encrypted network communications. Ensure all endpoints use encrypted network-based communications, including secure protocols, algorithms, and key lengths. For Oracle WebLogic Server, use the UCrypto provider to ensure that cryptography leverages the hardware-assist capabilities of the SPARC platform.
  • Enable encrypted data-at-rest protections.

    - Use encrypted swap, /tmp, and ZFS data sets for any locations that could potentially house sensitive or regulated data. This automatically takes advantage of cryptographic acceleration in Oracle Solaris.

    - Use tape drive encryption to protect data that must leave the data center for off-site storage. 

    - For databases, use the Transparent Data Encryption feature of Oracle Database to protect tablespaces that might store sensitive or regulated data. This feature automatically takes advantage of cryptographic acceleration in Oracle Solaris on SPARC systems.

  • Secure the database. Refer to Oracle Optimized Solution for Secure Oracle Database security best practices and recommendations.
  • Deploy application services in Oracle Solaris non-global zones. Deploying applications within Oracle Solaris non-global zones has several security advantages, such as kernel root kit prevention, prevention of direct memory and device access, and improved control over security configuration (via zonecfg(1M)). This approach also enables a higher level of assurance auditing, because audit data is not stored in the Oracle Solaris non-global zone, but rather in the Oracle Solaris global zone.
  • Implement a baseline auditing policy. Use audit logs and reports to track user activity—including individual transactions and changes to the system—and to flag events that fall out of normal parameters. These should be implemented at both the Oracle Solaris and database levels. The baseline security audit policy should include login and logout activity, administrative actions, and security actions, as well as specific command executions for Oracle Solaris. This tactic enables auditing of a core set of security-critical actions without overburdening the system or database.
  • Follow the rule of least privilege. Increase access control by granting only those privileges that a given individual needs. This should be implemented at both the enterprise resource planning (ERP) system level and the infrastructure level.
  • Use strong authentication. Many intellectual property attacks use stolen credentials. Implementing strong authentication methods, such as Kerberos, RADIUS, and SSL, can help prevent unauthorized access.
  • Leverage role-based access control. As the number of applications and users increases, user-based identity management can quickly become time-consuming and labor-intensive for IT staff. Consequentially, many users are granted inappropriate authorities. Though it requires increased efforts during the design and implementation phases, role-based access control (RBAC) is a popular option for low-maintenance, scalable access control, and it can help alleviate the burden of identity management.

The following are Oracle SuperCluster security recommendations:

And here is the full list of relevant component security recommendations:

Best Practices for Backup and Recovery of Operating Systems

Operating system backups are critical and should be made before and after every significant change to the Oracle SuperCluster software. This includes performing backups before and after completing the following procedures:

  • Installation or reconfiguration of significant Oracle or non-Oracle software
  • Reconfiguration of significant operating parameters
  • Applying each quarterly full stack download patch (QFSDP) for Oracle SuperCluster

Oracle Solaris 11

The conventional method for backing up an operating system is to install backup and recovery software and perform backups of the operating system to disk or tape, potentially an inefficient approach in 24/7 environments. In Oracle Solaris 10 and Oracle Solaris 11, the ZFS file system enables bare-metal recovery of the operating system using ZFS snapshots, the ZFS commands zfs send and zfs receive, and ZFS stream files. A ZFS stream file is an image of an entire ZFS file system placed into a file on an NFS share. The zfs send command creates a stream representation of a ZFS snapshot that is written either to a file or to a different system using standard output. The zfs receive command creates a snapshot whose contents are specified in the stream that is provided on standard input. If a full stream is received, a new file system is created as well. This functionality enables administrators to send and receive ZFS snapshot data and file systems using these commands.

Here is a high-level outline of the steps used to perform a backup and bare-metal recovery of the operating system. For details and commands, please see the Oracle SuperCluster Administrator's Guide, or My Oracle Support Note 1558851.1.

To perform a backup, do the following:

  1. To start, create an NFS share on an Oracle ZFS Storage Appliance system on which to store the snapshots.
  2. Take a ZFS snapshot of the operating system and send it to a stream file using the zfs send command.

To perform a restore of the snapshot, boot from the Oracle Solaris boot media, as follows:

  1. Create a new root pool, or rpool (a ZFS storage pool that contains a bootable ZFS root file system), on the replacement disks.
  2. Mount the NFS share.
  3. To restore, issue a cat command on the stream file, piping it to the newly created pool name on the local disk with the zfs receive command.

This procedure restores the zfs send file from the ZFS stream file back to the new ZFS pool. Using zfs send and zfs receive is the preferred method for restoring a bare-metal operating system. The previously recommended method—using a deployment system—takes approximately eight hours contrasted with 45 minutes when using the ZFS stream file method.

Backing Up Domains

The physical resources within Oracle servers can be virtualized for greater agility and utilization. Two different methods can be used for virtualization. The first method creates domains, partitioning the hardware to use specified physical resources and then physically or logically isolating one domain from another. The second virtualization method uses Oracle Solaris Zones, where each zone is a virtualized operating system environment created within a single instance of Oracle Solaris. Implementing zones enables the installation of multiple versions of Oracle Solaris 10 and Oracle Solaris 11 on a single system.

Various domain configurations and implementations are supported on Oracle servers. Domain configurations can have different layouts due to the ability to install the domains on different disks. Disk resources can be allocated and shared among domains, while some domains might not own any disks. Disks can be shared from other file systems and appear to users as local hard drives. Single-domain systems are typically fairly simple, as are two-domain configurations.

When backing up domains, the backup methods are the same as for the operating system. The restoration procedures vary, depending on what devices are installed with the domains, what disks are designated as targets, and where the rpool is created to receive the restore.

Domains also can be backed up with block-level backups using NDMP and an Oracle ZFS Storage Appliance system. Note, however, that this method is limited to backing up entire data sets, and does not offer the ability to restore single files. Single-file backup and recovery can be accomplished by installing Oracle Secure Backup in a zone to back up the zone as a regular backup and recovery client.

Backing Up Oracle Solaris Zones

Backup and recovery of applications is supported in NFS, and backup and recovery procedures remain the same for snapshots and replication of NFS shares, as well as for tape using NDMP. To back up NFS shares, use an Oracle ZFS Storage Appliance system with NDMP. NDMP, sometimes referred to as dump mode, provides high-performance, block-level backups. Note, however, that the ZFS NDMP functionality does not permit restoration of individual files, so in order to restore a single file, the entire data set must be restored. For more information on using NDMP with Oracle ZFS Storage Appliance systems, refer to the Oracle white paper "NDMP Implementation Guide for the Sun ZFS Storage Appliance."

Oracle Solaris Zones typically contain applications and databases for different use cases. Oracle Solaris Zones can be installed on internal server drives or on external iSCSI LUNs.

Zones stored on iSCSI LUNs cannot be backed up at the dump level with an Oracle ZFS Storage Appliance system—they must be backed up in ZFS block mode. This is a high-performance method that works well for restoring the entire zone. The ZFS block mode method does not support restoration of single files or directories; the entire data set must be restored. Single-file backup and recovery can be accomplished by installing Oracle Secure Backup software in a zone to back up the zone as a regular backup and recovery client.

For disk-only environments, zones can be backed up through the creation of snapshots, clones, or replication to another Oracle ZFS Storage Appliance system.

Best Practices for Database Backups (Oracle Database 11g Release 2 or Higher)

The following sections outline database backup best practices designed for high availability, optimal performance, and maximum data protection. These best practices should be followed for instances of Oracle Database running on Oracle SuperCluster, Oracle Exadata, or Oracle Optimized Solutions.

Oracle Optimized Solution for Secure Backup and Recovery provides a choice of tape-based and disk-based backup methods for protecting databases. This section includes general best practices for database backup as well as recommendations for both disk-based and tape-based database backups.

For disk-based backups, this solution includes both Oracle ZFS Storage Appliance systems and Zero Data Loss Recovery Appliance. The different configurations are designed to meet a variety of backup solution requirements. In general, Zero Data Loss Recovery Appliance provides the highest performance and serviceability, while an appliance from the Oracle ZFS Storage Appliance family provides flexibility and a lower-cost option.

Recommended Database Backup Schedule

Oracle recommends the following schedule for backups of Oracle Database:

  • Perform weekly Oracle RMAN level 0 (full) backups of the database.
  • Perform daily cumulative Oracle RMAN incremental level 1 backups of the database and use block change tracking.
  • Roll incremental backups into a full backup and delay by 24 hours.
  • Perform daily backups of the Oracle RMAN catalogs.

Always Use a Fast Recovery Area

One vital database backup and recovery best practice is to deploy Oracle Database with a Fast Recovery Area (FRA), which is the location where the database stores all of its information for Oracle Flashback technologies, snapshots, database backups, rollbacks, and more. The FRA enables the database to protect itself, by enabling the database to be rolled back to a certain point in time and restored within a matter of seconds instead of minutes or hours using conventional backup and recovery methods. Consequently, database recovery time is limited by the speed of the device on which the FRA resides, and it should be located on the fastest performing storage possible. Oracle engineered systems are designed with the FRA built in, because placing the FRA on anything but Oracle Exadata internal storage or an external Exadata Storage Expansion Rack will lengthen the amount of time it takes for recovery. Exadata Storage Expansion Racks can be used for extra space for the FRA, as needed.

Database backups can, if desired, be excluded from the FRA and stored instead on Oracle ZFS Storage Appliance system. In this case, the FRA on Oracle Exadata can be configured to be much smaller, because space for the full and incremental backups is not required in the FRA. This configuration can provide cost savings, because lower-cost storage can be used for database backups, without sacrificing system performance.

Additional Database Configuration Best Practices

There are other configuration parameters for Oracle Database that must be set in order to ensure optimal backup performance:

  • Set the initialization parameter _file_size_increase_increment=2143289344 to optimize the space used when incremental (level 1) backups are taken on the FRA.
  • Reset or remove the initialization parameters _backup_ksfq_bufsz and _backup_ksfq_bufcnt on systems running Oracle Database release 11.2.0.2 or later releases.
  • Use a backup Net service to run against all database servers in the cluster for better performance and high availability. The Oracle RMAN BACKUP command uses the service to automatically spread the backup load evenly among target the instances offering the service.
  • Set DB_RECOVERY_FILE_DEST_SIZE to bound space in the FRA. It is important that the value of this parameter be set to less than the total free space in the disk group, which must take account of at least one disk failure and preferably one Oracle Exadata Storage Server failure. If multiple databases are sharing the FRA, ensure that the sum of the space allocated to the different databases is less than the free space in the disk group.
  • Consider using the Resource Manager feature of Oracle Database to manage system resources, particularly I/O, on Oracle SuperCluster.

Oracle RMAN Configuration Best Practices

Best practices for Oracle RMAN configuration include the following:

  • Parallelize backups across all database nodes, allowing all the disks, network connections, and system CPUs to be leveraged for increased performance. Follow configuration instructions according to whether the backup targets are disks or tapes.
  • Use Oracle RMAN backup scripts to automate weekly and daily backups.
  • Use two to eight Oracle RMAN channels per instance when performing backups to disks. When performing backups to tape, configure one Oracle RMAN channel per tape drive and add tape drives to scale backup rates.
  • Use Oracle RMAN incremental backups and block change tracking.

    To reduce backup time and resources, perform nightly incremental backups to the FRA and merge them into the image copy backup on a regular basis. If recovery is needed, then the copies can be directly used as normal data files and recovered to a consistent point, without the need for a restore operation, thus significantly reducing overall recovery time.

    Enable Oracle RMAN block change tracking for fast incremental backups. This allows Oracle RMAN to avoid scanning blocks that have not changed when creating incremental backups. Oracle Exadata Storage Server also offloads block inspection from the database servers. Block change tracking is of greatest benefit for databases where fewer than 20 percent of the blocks are changed daily. For block change rates greater than 20 percent, testing is recommended to ensure that backup times are reduced.

  • Set the Oracle RMAN configuration setting FILESPERSET=1 when performing incremental backups to specify the maximum number of files in each backup set. A setting of 1 will allow for a faster single-file database restore operation.
  • Use an external Oracle RMAN recovery catalog repository as long as it is located on a system that is configured to be highly redundant.

Restore and Recovery Best Practices

Oracle engineers performing testing in Oracle labs have discovered that optimum restore performance depends on proper management of the backup chunk size. While the chunk size setting is not important during backups, the restore operation must have Oracle RMAN backups broken into the best-performing chunk sizes for individual environments or performance can suffer. Oracle recommends running tests in each individual environment—with the actual data—to verify that the chunk size to be used for Oracle RMAN restores is going to provide optimal performance.

The layout of each individual database determines performance. In addition, to increase recovery rate performance, create a restore service that runs across all available database nodes. The service is used by the Oracle RMAN restore command. Oracle RMAN automatically balances the restore load among the targeted instances.

Best Practices for Performing Local Disk-Based Backups with Oracle RAC

Scale backup rates written to local disk in the FRA on an Oracle Database Appliance system by using an Oracle RAC configuration.

  • Use multiple instances and start with one Oracle RMAN channel per instance.
  • Continue to add Oracle RMAN channels for performance per instance. Optimal backup rates have been observed by Oracle engineers with all Oracle RAC instances and one to four Oracle RMAN channels.

Best Practices for Performing Local Disk-Based Backups with Oracle RAC One Node

Scale backup rates written to local disk in the FRA on an Oracle Database Appliance system by using a single-instance and Oracle RAC One Node configuration.

  • Start with one Oracle RMAN channel.
  • Continue to add Oracle RMAN channels to the single database instance to increase performance. Optimal backup rates were observed with two to four Oracle RMAN channels.

Database Best Practices for Disk-Based Backups

Disk-only backups provide faster recovery times for data and logical corruptions and some tablespace point-in-time recovery (TSPITR) scenarios. Backups to disk also provide the ability to use backups directly—with no restore needed—by switching to a copy of the database, tablespace, or data file. Best practices for disk-based backup configurations include the following.

Scale backup rates for disk:

  • Use all instances and start with two Oracle RMAN channels per instance.
  • Continue to add another two more Oracle RMAN channels for performance.
  • For better performance, use the automatic configuration of the Oracle Exadata Storage Server grid disk group layout during deployment. This approach assigns the faster (outer) 40 percent of the disk to the DATA area and the slower (inner) 60 percent of the disk to the fast recovery area (RECO) area.
  • An alternative strategy is to purchase additional SATA Oracle Exadata storage specifically for storing the FRA. This allows the applications to leverage the full Oracle SuperCluster storage grid, allows the use of lower-cost storage for backups, and provides better failure isolation by using separate backup hardware. To reserve more space and bandwidth for the DATA disk group, Oracle recommends using a tape-based backup solution, or at the very least, a hybrid approach where full database backups are written to tape and incremental disk backups are written to the FRA.
  • Configure a high-redundancy DATA disk group to contain the Oracle Cluster Registry file (which is part of Oracle Clusterware), the Oracle Cluster voting disk (also part of Oracle Clusterware), spfiles, data files, redo log groups, and control files for any disk-based backup solution.

Database Best Practices for Tape-Based Backups

In addition to the general best practices for Oracle Database backups mentioned above, best practices for tape based backups include the following:

  • Perform daily backups of the Oracle Secure Backup or third-party backup and recovery software catalogs.
  • Keep the number of archive logs to a minimum to avoid adversely impacting backup rates.
  • Remember that heavy loads on an active database and fully consumed CPUs will affect backup rates.
  • Use Oracle Secure Backup for fast, low-cost tape backups. Oracle Secure Backup provides the fastest database backup to tape due to its tight integration with Oracle RMAN.
  • Be aware that using Oracle Secure Backup enables the unused-block optimization capability. However, if the backup is made directly to tape using a third-party media management product, then this does not have any effect because the unused-block optimization is available only with Oracle Secure Backup.
  • Configure the Network Time Protocol (NTP) daemon on Oracle Secure Backup servers. This step ensures that the NTP daemon service on the Oracle Secure Backup administration and media servers are running and configured to use the same time source as the Oracle engineered system.
  • Configure the Preferred Network Interface (PNI) to direct the Oracle Secure Backup traffic over the InfiniBand network interface. This parameter must be set when using a dedicated backup network.
  • Configure one Oracle RMAN channel per tape drive and add tape drives to scale backup rates. Backup performance scales when more tape drives and Oracle RMAN channels are added, assuming there is available throughput on the media server.
  • Configure dedicated 1 GbE, 10 GbE, or InfiniBand interfaces. Using a dedicated interface for the transport eliminates the impact on the client access network. Use InfiniBand for the best backup rates, especially for larger databases that require fast backup rates and low CPU overhead. When not using InfiniBand, use 1 GbE for smaller databases and 10 GbE for larger databases.
  • Configure an Oracle RAC service for backups running on all database instances. This step reduces CPU utilization on the database and media server nodes and load balances the backups.
  • Use Oracle SQL*Net Connect service load balancing to distribute Oracle RMAN channels evenly among the allocated instances.
  • Tune the network communication when using a third-party media management vendor, and check with the vendor—the vendor should be able to provide configuration best practices.

Best Practices for Tape-Based Backups

In addition to the database best practices for tape-based backups mentioned above, there are some additional general best practices to consider when performing tape-based backups.

Network Configuration Best Practices

Care must be taken when configuring the network connections for tape-based backups. The following two sections detail configurations for connecting the media servers to the network.

Best Practices for Connecting Media Servers to the InfiniBand Network

When connecting media servers to the InfiniBand network for tape-based backups, do the following:

  • Directly connect media servers to the InfiniBand fabric by adding an InfiniBand Quad Data Rate (QDR) host channel adapter (HCA) to the media server.
  • Connect the HCA to two different Oracle SuperCluster InfiniBand switches to eliminate the switch as a single point of failure and to provide high availability. This configuration ensures transparent failover if connectivity is lost to one of the ports.
  • Configure bonding or IP network multipathing (IPMP) for the InfiniBand interfaces on the media server.
  • Update OpenFabrics Enterprise Distribution (open source software for RDMA and kernel bypass applications) on the media server.
  • Configure IP over InfiniBand (IPoIB) connected mode for best performance.
  • Configure MTU Size=65520 on InfiniBand for faster data transmission.
  • Configure the media server to use the InfiniBand network.

Best Practices for Connecting Media Servers to1 GbE or 10 GbE Ports

The media servers for tape-based backups can be connected with one or more Ethernet ports that are either 1 GbE or 10 GbE.

  • Oracle Solaris enables link aggregation control protocol (LACP) bonding of interfaces for higher network performance. Alternatively, administrators can use Oracle Solaris to configure two interfaces with IP network multipathing (IPMP) for higher availability. LACP bonding requires a switch that can support LACP and enables the connection of multiple Ethernet ports to different switches that have the same Ethernet address.
  • IPMP supports multiple interfaces on the same IP link, connected to a single switch. This is a highly redundant configuration and increases availability, but does not provide high performance. This functionality is offered only by Oracle Solaris.
  • Configure the switch configuration, using 1 GbE or 10 GbE on the database server, to create either a dual-port 1 GbE or 10 GbE configuration that supports higher backup rates.
  • Configure 1 GbE or 10 GbE on the media server.

Configure Persistent Bindings for Tape Devices

It is very important that the environment maintains consistent device addresses. In SAN environments running Oracle Linux, persistent bindings must be configured so that the device addresses do not change. If a device's address changes, the media servers cannot access the device until the device configuration within Oracle Secure Backup is updated. Please see My Oracle Support Note 971386.1 for an example of creating persistent bindings for device attachments.

Back Up the Oracle Secure Backup Catalog

The Oracle Secure Backup catalog maintains backup metadata, scheduling, and configuration details for the backup domain. Just as it is important to protect the Oracle RMAN catalog or control file, the Oracle Secure Backup catalog should be backed up on a regular basis. In Oracle Secure Backup, the catalog backup has been preconfigured as follows:

  • Media family: OSB_Catalog_MF writes all catalog backups to the same tape or tapes.
  • Job summary: OSB-CATALOG-SUM sends email showing a daily report status of the catalog backup to users.
  • Data set: OSB-CATALOG-DS defines all directories and files to back up for file system backups.
  • Schedule: OSB-CATALOG-SCHED shows the schedule for the catalog backup.

The primary catalog backup configuration settings have been preconfigured, so only one step remains, which requires user intervention:

  • Edit the OSB-CATALOG-SCHED triggers to specify when to perform the backup.

For detailed and up-to-date information, please refer to My Oracle Support Note 1558851.1.

See Also

For additional information, please see the following:

About the Author

Dean Halbeisen is a solutions manager at Oracle. He has over 20 years of IT experience and is an expert in enterprise computing solutions, most recently applying these practices to next-generation data center solutions, integrated systems, and Oracle engineered systems. In his current role, he is responsible for solution architecture and development around Oracle Optimized Solutions, including communicating about Oracle's systems, solutions, and technology strategies and roadmaps to customers, partners, and internal stakeholders.

Tagged:
· Share on TwitterShare on Facebook
Sign In or Register to comment.