1 Oracle Secure Backup Concepts

This chapter introduces concepts related to backup and recovery using Oracle Secure Backup.

This chapter contains these sections:

• Oracle Secure Backup Features

• Administrative Domains, Catalog Data and Configuration Files

• Oracle Secure Backup Daemons

• Defaults and Policies

• Backup Images and Media

• Jobs and Requests

1.1 Oracle Secure Backup Features

Oracle Secure Backup provides reliable, centralized tape backup management, protecting file-system data and Oracle Database files. The Oracle Secure Backup SBT interface enables you to use Recovery Manager (RMAN) to back up and restore Oracle Database files to and from tape. Oracle Secure Backup supports almost every tape drive and tape library in Storage Area Network (SAN) and SCSI environments.

Oracle Secure Backup enables you to do the following:

• Centrally manage tape backup and restore operations of distributed, mixed-platform environments

  You can access local and remote file systems and any tape device from any location in a network without using Network File System (NFS) or Common Internet File System (CIFS).

  See Also:

  Oracle Secure Backup Installation and Configuration Guide for information on supported computer architectures

• Back up to and restore data from Oracle Cluster File System (OCFS) on Linux and Windows

• Encrypt all stored data

  See Also:

  Chapter 10, "Managing Backup Encryption"

• Use wildcards and exclusion lists to specify what you want to back up

• Perform a multilevel incremental backup

• Duplex database backups so that the same data stream goes to multiple tape devices

  You can specify a different media family or tape device for each copy of the data.

• Create backups that span multiple volumes

  A volume is a unit of media, such as an 8mm tape.

• Optimize tape resources with automatic tape drive sharing

• Restore data rapidly

  Oracle Secure Backup uses direct-to-block positioning and direct access restore to avoid unnecessarily reading tape blocks to locate files. Oracle Secure Backup maintains a record of the tape position of all backup data in its catalog for rapid retrieval.

• Maintain security and limit the users who are authorized to perform data management operations

  By default, Secure Sockets Layer (SSL) is used for host authentication and communication in the administrative domain.

• Manage media rotation from one location to another

• Automate tape duplication with user-defined policies

1.2 Administrative Domains, Catalog Data and Configuration Files

An administrative domain is a network of hosts that you manage as a common unit to perform backup and restore operations. Oracle Secure Backup organizes information about the administrative domain as a hierarchy of files in the Oracle Secure Backup home on the administrative server. The Oracle Secure Backup home is the directory in which Oracle Secure Backup is installed.

Figure 1-1 shows the directory structure of an Oracle Secure Backup home. This directory structure is the same for all platforms, but the default Oracle Secure Backup home is /usr/local/oracle/backup for UNIX and Linux and C:\Program Files\Oracle\Backup for Windows.

Figure 1-1 Directories on the Administrative Server

Description of "Figure 1-1 Directories on the Administrative Server"

Oracle Secure Backup administrative data includes configuration data about each domain-wide entity, such as a class, a tape device, or a media family. As shown in Figure 1-1, the config directory contains several subdirectories, each of which represents an object that Oracle Secure Backup maintains. In each object directory, Oracle Secure Backup maintains files describing the characteristics of the corresponding object.

The Oracle Secure Backup catalog contains backup-related information. The admin/history/host directory contains subdirectories named after the hosts in the administrative domain. Each subdirectory has a file in which the catalog data is stored. Oracle Secure Backup supports catalog files larger than 2 GB. This support is restricted to operating systems and file systems that themselves support files of over 2 GB.

The amount of space consumed by the catalog is different for native and NDMP hosts. The sum of the following three components gives an estimate in bytes for expected growth of the catalog for a native Oracle Secure Backup backup:

• (number of new files and directories) * (43 + average file leaf name length)

• (number of modified existing files) * (27 bytes for statistics record)

• (number of unmodified existing files) * 0.5

The sum of the following three components gives an estimate in bytes for expected growth of the catalog when backing up a third-party NDMP filer:

• (number of new files and directories) * (53 + average file leaf name length)

• (number of modified existing files) * (35 bytes for statistics record)

• (number of unmodified existing files) * 0.5

An NDMP backup also consumes 16 bytes in the NDMP position file for every file backed up regardless of whether it is new, modified, or unmodified.

Note:

Oracle Secure Backup makes a temporary copy of the catalog during the processing of a backup. Planning for storage space on the Oracle Secure Backup administrative server must take that temporary copy into consideration.

Oracle Secure Backup automates the protection of the contents of the catalog and configuration files. During installation, Oracle Secure Backup schedules the necessary backup job to back up these files to tape. If the catalog data is lost, for example because a disk fails, then you can restore the most recently backed up catalog from tape and then restore the rest of your data.

In general, you should access configuration data and the catalog through obtool or the Oracle Secure Backup Web tool. Avoid accessing the files containing this data directly on the file system.

See Also:

Oracle Secure Backup Installation and Configuration Guide for details on the contents of the files and directories in the Oracle Secure Backup home

1.3 Oracle Secure Backup Daemons

Oracle Secure Backup daemons are background processes that perform Oracle Secure Backup operations. Some daemons run continually, whereas others run only to perform specific work and then exit when they have finished.

Note:

On the Windows operating system, only the service daemon is a Windows service. The other Oracle Secure Backup daemons are not Windows services.

This section contains these topics:

• Types of Daemons

• Daemon Interaction in a File-System Backup

1.3.1 Types of Daemons

An Oracle Secure Backup administrative domain uses a variety of daemons to perform backup, restore, and configuration tasks. The daemon programs are located in the etc subdirectory of the Oracle Secure Backup home on Linux or UNIX, and in the bin directory on Windows. This section describes the Oracle Secure Backup daemons.

Table 1-1 lists the Oracle Secure Backup daemons and shows on which hosts they run.

Table 1-1 Oracle Secure Backup Daemons by Host Type

Daemon	Administrative Server	Media Server	Client
Service	yes	yes	yes
Schedule	yes	no	no
Index	yes	no	no
Apache Web Server	yes	no	no
NDMP	yes	yes	yes
Robot	no	yes	no
Proxy	no	no	yes

This section contains these topics:

• Service Daemon

• Schedule Daemon

• Index Daemon

• Apache Web Server Daemon

• NDMP Daemon

• Robot Daemon

• Proxy Daemon

1.3.1.1 Service Daemon

The observiced service daemon provides a wide variety of services. It runs continually on the administrative server, media server, and client.

On the administrative server, observiced runs jobs at the request of the schedule daemon, cleans up log files and transcripts, and provides access to Oracle Secure Backup configuration data to other hosts in the domain. observiced also serves as the Certification Authority (CA), accepting certificate signing requests from hosts within the administrative domain and sending signed certificates back to the requesting host. observiced starts the schedule daemon and the Apache Web server during initialization.

When running on a media server or client, observiced handles membership in a administrative domain, allows for remote administration of the host, and handles certificate operations. The identity certificate of the requesting host is used to verify that it is permitted to invoke the operation.

On all hosts, the service daemon is usually started as part of system startup. On UNIX and Linux, startup is usually performed through entries in /etc/init.d, whereas on Windows systems the service is started by the Service Control Manager.

1.3.1.2 Schedule Daemon

The obscheduled daemon is the Oracle Secure Backup scheduler. The schedule daemon runs continually on the administrative server.

The schedule daemon manages each scheduled backup, retains a list of every available tape device in the domain, and assigns backups to tape devices as they become available. The daemon receives job creation requests from obtool users and from the SBT interface in response to RMAN commands.

Scheduler policies control how a backup request is scheduled.

1.3.1.3 Index Daemon

The obixd daemon manages the backup catalog for each client. The index daemon runs intermittently on the administrative server.

The index daemon is started at the conclusion of any backup to import the index data generated by obtar into the backup catalog. In addition, obixd is started when the catalog must be accessed for restore or browsing operations.

1.3.1.4 Apache Web Server Daemon

The obhttpd daemon provides the Web tool for Oracle Secure Backup. This daemon runs continually on the administrative server.

The Web server daemon is signaled to start by the observiced daemon, which itself is normally started as part of system startup.

1.3.1.5 NDMP Daemon

The obndmpd daemon implements the NDMP tape service and provides data communication between the media server and client. This daemon runs on both the client and media server. It passes control of the data connection to a sub-process so it can remain free to respond to control messages sent by obtar.

Two instances of obndmpd run during an active backup or restore operation. If the same host is acting as both the media server and the client, then three instances of obndmpd are running: one acting as controller, one acting as the data service, and one acting as the mover.

1.3.1.6 Robot Daemon

The obrobotd daemon manipulates tapes in a tape library. This daemon runs intermittently on a media server.

When an Oracle Secure Backup component such as obtar must interact with a tape library, it asks observiced on the media server to start an instance of obrobotd. The robot daemon then fields all requests for inventory manipulations, the movement of media in the tape library, and so on. Each invocation of obrobotd manages a single tape library. obrobotd exits when all users of a tape library have closed their connections.

1.3.1.7 Proxy Daemon

The obproxyd daemon verifies user access for SBT backup and restore operations. The proxy daemon runs on the host that contains the SBT library accessed during the operations. The invocation of the proxy daemon is platform-specific.

The proxy daemon uses the operating system user identity of the process invoking the SBT library and the local host name to determine the Oracle Secure Backup account to use for the backup operation. If a preauthorization exists for this operating system user and host, then the associated Oracle Secure Backup user is permitted to perform RMAN backups and the login to Oracle Secure Backup is permitted.

1.3.2 Daemon Interaction in a File-System Backup

Figure 1-2 provides a simplified graphical illustration of the relationships among the daemons on an administrative server, media server, and client.

Figure 1-2 Daemons in an Administrative Domain

Description of "Figure 1-2 Daemons in an Administrative Domain"

The media server in Figure 1-2 shows an obtar instance, but obtar is not itself a daemon. It is the underlying Oracle Secure Backup engine that manipulates the data and tape services during a backup or restore operation. When you issue commands in obtool or the Oracle Secure Backup Web tool, Oracle Secure Backup translates them internally to obtar commands.

Imagine that observiced daemons run on all hosts, the observiced daemon on the administrative server has invoked the obscheduled and obhttpd daemons, and a client file-system backup job has been created and scheduled to run. The Oracle Secure Backup daemons interact with obtar as follows:

1. On the administrative server, obscheduled sends a request to observiced to run the backup job.

2. observiced on the administrative server sends a request to obrobotd on the media server to mount the volume required for the backup job.

3. observiced on the administrative server sends a request to observiced on the media server to invoke obtar.

4. obtar on the media server establishes a data connection between the obndmpd daemon on the client and the obndmpd daemon on the media server. Backup data is transmitted over the data connection and written to tape.

   obtar usually runs on the media server. If the media server is not running Oracle Secure Backup software, then obtar runs on the administrative server. An example of a media server not running Oracle Secure Backup is an NDMP-based filer.

5. obtar sends catalog information to obixd on the administrative server and then terminates.

6. On the administrative server, observiced sends a job status update to obscheduled.

1.4 Defaults and Policies

Oracle Secure Backup defaults and policies control how Oracle Secure Backup operates within an administrative domain. Policy settings are maintained on the administrative server.

Oracle Secure Backup policies are grouped into several policy classes. Each policy class contains policies that describe a particular area of Oracle Secure Backup operations. The policy classes related to managing Oracle Secure Backup backup and restore functions are as follows:

• Backup encryption policies

  These policies control the encryption of backups written to tape. For example, you can specify whether encryption of backups to tape is mandatory, key size, and aspects of key management.

• Daemon policies

  These policies control aspects of the behavior of daemons and services. For example, you can specify whether logins should be audited and control how the index daemon updates the catalog.

• Device policies

  These policies control how tape devices are automatically detected during device discovery.

• Index policies

  These policies control how Oracle Secure Backup generates and manages the catalog. For example, you can specify the amount of elapsed time between catalog cleanups.

• Log policies

  These policies control historical logging in the administrative domain. For example, you can specify which events should be recorded in the activity log on the administrative server: all, backups only, restore operations only, and so on.

• Media policies

  These policies control domain-wide media management. For example, you can specify a retention period for tapes that are members of the null media family.

• NDMP policies

  These policies specify NDMP defaults. For example, you can specify a password used to authenticate Oracle Secure Backup to each NDMP server.

  The practice of supplying a password in clear text on a command line or in a command script is not recommended by Oracle. It is a security vulnerability. The recommended procedure is to have the Oracle Secure Backup user be prompted for the password.

• Operations policies

  These policies control various backup and restore operations. For example, you can set the amount of time that an RMAN backup job waits in the Oracle Secure Backup scheduler queue for the required resources to become available.

• Security policies

  These policies control domain security.

• Scheduler policies

  These policies control the behavior of the scheduler. For example, you can specify a frequency at which the scheduler attempts to dispatch backup jobs.

• Vaulting policies

  These policies control the rotation of tapes from one location to another as part of a data protection strategy.

• Volume duplication policies

  These policies control how Oracle Secure Backup performs volume duplication. For example, you can control whether duplication should be performed over the network or only on one local host.

See Also:

Oracle Secure Backup Reference for more information on Oracle Secure Backup policies

1.5 Backup Images and Media

To understand Oracle Secure Backup, you must understand the relationship between the physical backup files and the media on which those files are stored. Figure 1-3 provides a graphical illustration of how backup files are related to volumes. The concepts are as follows:

• A data block is the amount of data written to media in each write operation.

• A volume is a unit of media, such as an 8mm tape.

• A backup section is the part of a backup image that fits on one physical volume.

• A backup image is the product of a backup operation.

Figure 1-3 Backup Images, Backup Sections, and Volumes

Description of "Figure 1-3 Backup Images, Backup Sections, and Volumes"

Figure 1-4 provides a graphical illustration of how a volume set is related to a media family. The concepts are as follows:

• A volume set is a logical grouping of one or more physical volumes spanned by a backup image.

• A media family is a logical classification of volumes that share common attributes. For example, volumes in a media family share a common naming pattern and policies used to write and keep data.

Figure 1-4 Volumes, Volume Sets, and Media Families

Description of "Figure 1-4 Volumes, Volume Sets, and Media Families"

When you back up files with Oracle Secure Backup, you generate a volume set that has some common characteristics defined by the corresponding media family associated with your backup.

This section contains these topics:

• Data Blocks and Blocking Factors

• Backup Images and Sections

• Volumes

• Volume Sets

• Media Families

1.5.1 Data Blocks and Blocking Factors

In a typical format, a tape drive writes data to a tape in blocks. The tape drive writes each block in a single operation, leaving gaps between the blocks. The tape runs continuously during the write operation.

The block size of a block of data is just the size of the block in bytes as it was written to tape. All blocks read or written during a given backup or restore operation have the same block size. The blocking factor of a block of data expresses the number of 512-byte records that are contained in that block. So, for example, the Oracle Secure Backup default blocking factor (128) results in a tape block size of 128*512 bytes or 64KB.

The maximum blocking factor is an upper limit on the blocking factor that Oracle Secure Backup uses. This limit comes into play particularly during restores, when Oracle Secure Backup must pick an initial block size to use without knowing the actual block size on the tape. The maximum blocking factor limits this initial block size to a value that is acceptable to both the tape device and the underlying operating system.

When Oracle Secure Backup starts a backup, it decides what block size to use based on several factors. Listed in order of precedence, these factors are:

• Blocking factor specified using the obtar -b option

  This option can also be specified as part of the operations/backupoptions policy. If this option is specified, then it overrides all other factors.

  See Also:

  Oracle Secure Backup Reference for more information on the obtar -b option and the operations/backupoptions policy

• Configuration of the tape drive to be used

  You can specify what blocking factor, maximum blocking factor, or both that Oracle Secure Backup should use for a particular tape drive when you configure that drive. You might want to do this if you have tape drives with very different block size limits.

  See Also:

  Oracle Secure Backup Installation and Configuration Guide for more information on configuring a tape drive

• Domain-wide blocking factors, maximum blocking factors, or both that the media/blockingfactor and media/maxblockingfactor policies set.

  See Also:

  Oracle Secure Backup Reference for more information on the media/blockingfactor and media/maxblockingfactor policies

• The default blocking factor (128) and maximum blocking factor (128), resulting in a block size of 64 KB

When a blocking factor has been nominated by one or another of these factors, it must pass the following tests:

• The block size must be less than or equal to the maximum block size (blocking factor) in effect from applying whatever policies or tape drive configuration attributes are in force.

• The block size must be supported by the tape drive and attach point in question.

  Sometimes a tape drive, device driver, or kernel operating system has a limitation that supersedes all other considerations.

When Oracle Secure Backup begins a restore operation, it does not know what block size was used to write a given tape. Because issuing a read for a too-small block would result in an error condition and a required tape reposition, Oracle Secure Backup always starts a restore operation by reading the largest possible block size. This is either the current setting of the media/maxblockingfactor policy or the tape drive configuration attribute. The maximum blocking factor, therefore, must always be greater than or equal to the largest block size you ever want to restore.

After the first read from the backup image, Oracle Secure Backup compares the amount of data requested to the actual size of the block and adjusts the size of subsequent reads to match what is on the tape.

1.5.2 Backup Images and Sections

When you run a backup operation in Oracle Secure Backup, you generate a backup image on tape. As shown in Figure 1-5, a backup image is a file that consists of at least one backup section.

Figure 1-5 Backup Images and Backup Sections

Description of "Figure 1-5 Backup Images and Backup Sections"

A backup image is uniquely identified in the Oracle Secure Backup catalog by its backup ID. Similarly, a backup section is uniquely identified in the catalog by its backup section ID. Example 1-1 shows output from the lsbu command for a backup with the ID of 1.

Example 1-1 Backup

ob> lsbu 1
      Backup       Backup  Volume            Volume          File Sect Backup
   Date and Time       ID  ID                Tag                #    #  Level
2008/07/13.11:56:58     1  VOL000003              ADE203        1    1      0

Example 1-2 shows output from the lssection command for the backup section belonging to the backup shown in Example 1-1.

Example 1-2 Backup Section

ob> lssection --vid VOL000003 --file 1
   BSOID  Volume         File Sect  Level  Client        Created     Attributes
     107  VOL000003         1 1         0  brhost2       07/13.11:56 never expires

See Also:

Oracle Secure Backup Reference for complete syntax and semantics for the lsbu and lssection commands.

1.5.3 Volumes

A volume is a physical piece of media such as a tape. Oracle Secure Backup identifies each volume with a unique volume ID. Oracle Secure Backup obtains the volume ID in a way described in "Volumes in a Media Family".

In addition to volume IDs, volumes can have tags. A volume tag is an alphanumeric string, up to 31 characters in length, that is typically obtained from a UPC barcode label affixed to the tape cartridge. Many libraries are equipped with barcode readers, which enables Oracle Secure Backup to determine the identity of a tape without having to load it and read the volume label. Oracle Secure Backup remembers the relationship between a volume tag and each backup image it contains in the catalog.

1.5.3.1 Backup Image and Volume Labels

In Oracle Secure Backup, a volume label typically contains a volume ID—for example, lev0-0001—and a volume tag, which is a barcode. These two attributes uniquely identify a tape. Oracle Secure Backup usually creates a volume label when it first writes to a tape. The first block of a backup image is referred to as a backup image label. It contains the file number, section number, and owner of the backup image.

When a label is displayed, volume-related information is displayed with the header Volume label and backup image-related information is displayed with the header Backup Image label. These are actually different parts of a single label.

For volumes generated by the Oracle Secure Backup scheduling system, you might see entries such as media family and volume expiration.

Oracle Secure Backup backup images adhere to the IEEE POSIX.1 data archiving format. Oracle Secure Backup numbers each backup image on a labeled volume set with a backup image file number, starting from 1.

When Oracle Secure Backup writes multiple backup images on a volume, it places a tape file mark after each backup image. After the last image, Oracle Secure Backup writes a tape file mark, then an end-of data (EOD) label, and then two more tape file marks. Figure 1-6 illustrates the format of a volume that contains two backup images. This figure shows the position of the labels and tape file marks.

Figure 1-6 Two Backup Images on a Volume

Description of "Figure 1-6 Two Backup Images on a Volume"

Backup images, volume labels, and the special End of Data/End of Volume labels share a common format and include both volume and backup image data. The volume label serves a dual role, being both the label for the volume and the label of the first backup image on the volume. Similarly, a backup image label contains information about the following backup image and a copy of the volume information from the volume label. Thus, Oracle Secure Backup can obtain volume information without having to rewind the tape to read the volume label.

Assume that the volume shown in Figure 1-6 is the first volume in the set. The volume label for the first backup image could look like the one in Example 1-3.

Example 1-3 Backup Image 1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       1
 Section:           1
 Sequence number:   1
...

The volume label for the second backup image could look like the one in Example 1-4.

Example 1-4 Backup Image 2

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           1
 Sequence number:   1
...

After Oracle Secure Backup creates a backup image, it positions the volume just before the EOD label. The EOD label contains a copy of the data in the preceding backup image label, except that the image file number is incremented by one. Oracle Secure Backup uses the EOD label to provide a volume ID, backup image file number, and sequence number for the next backup image without rewinding the volume.

After Oracle Secure Backup reads a backup image, it positions the volume after the tape file mark following the backup image that it just read and before the volume label of the next backup image.

1.5.4 Volume Sets

Oracle Secure Backup enables a single backup image to span multiple volumes. A volume set is a set of one or more tape volumes in which the first volume is continued onto the second, the second is continued onto the third, and so on.

Each volume in a volume set has a volume sequence number that is one greater than the sequence number of the previous volume. Consequently, you can back up or restore large amounts of data in a single session.

When Oracle Secure Backup reads and writes multiple volumes, it keeps track of the proper order of volumes within the volume set with the following data:

• EOV labels

  If a backup image extends beyond the end of one volume and continues onto a subsequent volume, then Oracle Secure Backup ends the first volume with a special EOV label. This label contains the volume ID of the next volume in the set. In a volume set, every volume except the last ends with an EOV label. The last ends with an EOD label.

• Sequence numbers

  A sequence number, which is recorded in the volume label, indicates the order of volumes in a volume set. The first volume in a set has sequence number 1.

• Section numbers

  A section number, which is recorded in the volume label, indicates the order of the parts of a backup image that spans multiple volumes.

  Note:

  The section number is always 1 unless the backup image spans volumes

Figure 1-7 illustrates a volume set that contains three backup images. Backup image 2 spans two volumes.

Figure 1-7 A Single Backup Image on Multiple Volumes

Description of "Figure 1-7 A Single Backup Image on Multiple Volumes"

A partial volume label for the first backup image could look like the one shown in Example 1-5.

Example 1-5 Backup Image 1, Section 1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       1
 Section:           1
 Sequence number:   1

The partial volume label for the first section of the second backup image could look like the one shown in Example 1-6.

Example 1-6 Backup Image 2, Section 1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           1
 Sequence number:   1

The partial volume label for the second section of the second backup image could look like the one shown in Example 1-7.

Example 1-7 Backup Image 2, Section 2

Volume label:
 Volume ID:         VOL000015
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           2
 Sequence number:   2

The partial volume label for the second section of the second backup image could look like the one shown in Example 1-8.

Example 1-8 Backup Image 3, Section 1

Volume label:
 Volume ID:         VOL000015
 Owner:             jane
 Host:              chicago
 File number:       3
 Section:           1
 Sequence number:   2

1.5.5 Media Families

A media family is a named classification of volume sets. This classification ensures that volumes created at different times share characteristics. In this way, you can map a media family to a typical backup operation. Media families define the retention methodology, write window, and retention time as appropriate.

1.5.5.1 Media Family Attributes

Every volume in a media family shares the following attributes:

• Volume identification sequence

  Oracle Secure Backup writes a unique identifier on each tape volume whenever one of these occurs:

  • Oracle Secure Backup writes to the tape for the first time.

  • Oracle Secure Backup overwrites the tape from the beginning.

  The volume ID consists of a fixed portion, usually the name of a media family, followed by a sequence number assigned and updated by Oracle Secure Backup. For example, if the media family is full_backup, then a volume ID might be full_backup-000029. By default the sequence number of the first volume in the media family is 1. The sequence number is incremented by 1 for each successive volume in the media family. However, if a media family is deleted and another is created using the same name, then the volume sequence number is reset to 1.

• Volume expiration policy

  An expiration policy defines when volumes in a media family are eligible to be overwritten and recycled. A media family can have either of the following mutually exclusive volume expiration policy types:

  • Content-managed

    Determines volume expiration by using RMAN retention parameters that are associated with the Oracle Database. Content-managed media families can only store Oracle Database backups.

    See Also:

    "Content-Managed Expiration Policies"

  • Time-managed

    Determines volume expiration by leveraging a user-defined retention that is associated with the media family. Time-managed media families can store both Oracle Database and file-system backups.

    See Also:

    "Time-Managed Expiration Policies"

  For file system backups, if no media family is designated, then the null media family is used as the default. For RMAN backups, if no media family is designated, the RMAN-DEFAULT media family is used as the default.

  When Oracle Secure Backup first writes to a volume, the media family associated with the backup operation is assigned to the volume. It is possible for a volume to be unexpired and still have unused tape remaining. Only backups of the same media family can be appended to this tape. Every backup tries to append to the most recent volume in the media family. If this volume is full or closed, then it writes to a different volume. Oracle Secure Backup can also select a recyclable volume to be used for the backup.

  When a volume set is expired, Oracle Secure Backup automatically considers each volume in the set eligible to be overwritten and recycled. If the volume set is content-managed, then an individual volume of the set can expire before the remainder of the set.

• Write window

  The write window is the period for which a volume set remains open for updates, usually by appending another backup image. The write window opens at the volume creation time for the first volume in the set and closes after the write window period has elapsed.

  If a backup is writing to a tape when the write window closes, then the backup completes but no further backups are written to the volume. After the write window close time, Oracle Secure Backup does not allow further updates to the volume set until it expires (as determined by its expiration policy), or until it is manually unlabeled.

• Rotation policy

  A rotation policy defines the physical management of backup media throughout the media life cycle. It determines in what sequence and at which times each volume moves from the initial active location where it is written, to another location, and so on, until it is reused.

  See Also:

  Chapter 9, "Vaulting" for more information on rotation policies

Attributes in a media family are applied to a volume in the media family at volume creation time. The media family attributes are part of the volume's attributes. After data is first written to the volume, you cannot change the volume attributes other than by rewriting the volume. If you change the media family attributes, then these changes do not apply to any volumes that have been created in this family.

See Also:

• "Configuring Media Families" to learn how to create media families

• Oracle Secure Backup Reference for a description of the media family commands

1.5.5.2 Volumes in a Media Family

When you create a media family, you specify how to generate volume IDs that become part of the volume label.

When Oracle Secure Backup labels a tape volume, it assigns it a volume ID based upon the contents of a volume sequence file. This file resides on the administrative server. Its location is defined by the media family of the volume. The volume sequence file is usually located in the admin/state/general subdirectory of the Oracle Secure Backup home.

When you define a media family, you direct Oracle Secure Backup how to assign a volume ID. You can direct Oracle Secure Backup in the following ways:

• Media family default volume sequence file

  In most cases, you should use this file. Volume sequence files for each media family are located in the admin/state/family/family_name directory. For example, if you define a media family with the name new_data, then files are located in the admin/state/family/new_data directory.

  Oracle Secure Backup constructs each volume ID by starting with the media family name, appending a dash, then appending a 6-digit sequence number, the first of which is 000001. For example, if you define a media family called new_data, then Oracle Secure Backup creates a volume sequence file on the administrative server called .vid.new_data. The first volume ID in this file is new_data000001. Each time Oracle Secure Backup assigns an ID to a volume, it increments by one. That is, the next volume ID that Oracle Secure Backup assigns is new_data000002 and so on.

• User-specified volume sequence file

  Oracle Secure Backup creates a default volume sequence file during installation. It resides in the admin/state/general subdirectory on the administrative server. The first volume ID in this file is VOL000001. Each time Oracle Secure Backup assigns an ID to a volume, it increments it by one. That is, the next volume ID that Oracle Secure Backup assigns is VOL000002, and so on.

  If you specify your own volume sequence file, then Oracle Secure Backup ignores the default volume sequence file and instead uses your file for obtaining volume IDs. You can enter a full path name to specify where this file should be created later. Oracle Secure Backup does not create this file automatically. You must do so manually. You can use a text editor to customize the volume ID prefix.

  Each volume ID file can contain a single volume ID. The maximum length of the volume ID is 31 characters. You can use the first few characters to help classify your volumes. For example, you could create volume IDs that begin with:

  • The prefix 8mm to identify volumes created by one tape device and DAT to identify volumes created by a different tape device

  • The prefix INCR or FULL to identify volumes used for a full backup or an incremental backup

  • The initials of the operator who performs the backup, for example, la

  If you do not include any digits in the sequence number you create, then Oracle Secure Backup appends a 1 to the sequence number and increments that number by 1 each time the sequence number is used.

• User-specified volume ID

  You can use the --vidunique option on the mkmf command to specify an explicit volume ID. For example, you can create your own volume ID if you previously created a tape that is partially unreadable. You can perform the backup again and use the --vidunique option, specifying a volume ID that keeps your volume IDs in sequence.

  You can also use the --vid option on the restore command to ensure that the volume being read is the correct one.

  See Also:

  Oracle Secure Backup Reference for complete syntax and semantics for the mkmf and restore commands

1.5.5.3 Volume Expiration Policies

When you create a media family, you specify a volume expiration policy that determines when volumes in a media family are eligible to be overwritten and recycled. As shown in Figure 1-8, volumes in a media family use either a content-managed expiration policy or time-managed expiration policy.

Figure 1-8 Volume Expiration Policies

Description of "Figure 1-8 Volume Expiration Policies"

1.5.5.3.1 Content-Managed Expiration Policies

You can make an RMAN backup, but not a file-system backup, to a volume that uses a content-managed expiration policy. The expiration of a content-managed volume is determined based on the attribute associated with the backup pieces stored on the volume. When each backup piece on the volume has been marked as deleted, the volume is eligible to be recycled. A volume in a content-managed volume set can expire even though the other volumes in the set are not yet expired.

Since content-managed volumes adhere to user-defined RMAN retention settings, RMAN instructs Oracle Secure Backup when to mark an backup piece as deleted.The actual backup piece is not deleted from the volume, only the value of the attribute in the Oracle Secure Backup catalog is updated.

When you install Oracle Secure Backup, the software includes a default content-managed media family named RMAN-DEFAULT. You cannot delete or rename this media family, although you can modify certain attributes of it through the Oracle Secure Backup Web tool or the chmf command in obtool.

As shown in Figure 1-8, you can delete backup pieces through the RMAN or Oracle Secure Backup interfaces. Deleting backup pieces with Oracle Secure Backup tools leaves the metadata in the RMAN repository inconsistent with the contents of your tapes. If RMAN backups are deleted from tape at the Oracle Secure Backup level, or if RMAN backups on tape are unavailable or lost for other reasons, then you should immediately use the RMAN CROSSCHECK command to update the RMAN repository.

See Also:

• Oracle Database Backup and Recovery User's Guide to learn about deleting or crosschecking backups

• Oracle Secure Backup Reference to learn about the chmf command

1.5.5.3.2 Time-Managed Expiration Policies

Volumes in a time-managed media family expire when they reach their volume expiration time. At this point Oracle Secure Backup automatically considers each volume in the volume set eligible to be overwritten.

As shown in Figure 1-8, Oracle Secure Backup computes the volume expiration time by adding the following:

• Volume creation time for the first volume in the set

  This is the time at which Oracle Secure Backup wrote backup image file number 1 to the first volume in the volume set.

• Write window period

  This is the user-specified period during which volumes in a media family can be written to. All volumes in a volume set share the same write window.

• Retention period

  This is the user-specified period during which volumes in a media family are not eligible to be overwritten. All volumes in a volume set share the same retention period.

  If no write window is configured, then the retention period begins with the first tape write. If a write window is configured, then the retention period begins when the write window closes for the volume set.

  The retention period setting prevents you from overwriting any volume in this media family until the specified amount of time has passed. If one volume becomes full, and if Oracle Secure Backup continues the backup onto subsequent volumes, then it assigns each volume the same retention period.

For example, if you set the write window for a media family to 7 days and the retention period to 14 days, then the data on all volumes in the volume set is retained for 14 days from the close of the write window. If Oracle Secure Backup first wrote to the first volume in the set on January 1 at noon and subsequently wrote data on 20 more volumes in the set, then all 21 volumes in the set expire on January 22 at noon.

You can make both a file-system backup and an RMAN backup to a time-managed volume. Thus, a volume with a time-managed expiration policy can contain a mixture of file-system backups and RMAN backup pieces. If you make an RMAN backup to a time-managed volume, then the time-managed expiration policy overrides any retention settings set in RMAN.

Caution:

If you make RMAN backups to time-managed volumes, then it is possible for a volume to expire and be recycled while the RMAN repository reports the backup pieces as available. In this case, you must use the CROSSCHECK command in RMAN to resolve the discrepancy.

1.6 Jobs and Requests

In Oracle Secure Backup, a backup or restore request is distinct from a job. A request is a locally-stored specification of a backup or restore operation that is not yet eligible to run. A job is a request that has been forwarded to the Oracle Secure Backup scheduler and is eligible to be run.

The scheduler policies, which are described in "Defaults and Policies", determine how the scheduler handles backup and restore jobs. You should familiarize yourself with these settings because they determine the frequency with which the scheduler dispatches jobs.

Note:

This section describes file-system backup and restore jobs. To learn about database backup and restore jobs, see "How RMAN Accesses Oracle Secure Backup".

Figure 1-9 shows the process by which an Oracle Secure Backup user can create an on-demand backup or restore job.

See Also:

"On-Demand Backups"

Figure 1-9 Backup and Restore Requests and Jobs

Description of "Figure 1-9 Backup and Restore Requests and Jobs"

The steps in the process illustrated in Figure 1-9 are as follows:

1. A user creates a file-system backup or restore request. For example, the user submits a request for a backup of the /home directory of client host brhost2.

   Oracle Secure Backup maintains a queue of backup and restore requests in the user's Oracle Secure Backup Web tool or obtool session. The user can review or modify this queue. When the user terminates the session, requests that are not yet sent to the scheduler are lost.

2. If necessary, the user modifies the requests in the queue. For example, the user can delete a job request.

3. The user sends the backup request to the scheduler (obscheduled) running on the administrative server.

   When a user sends a file-system backup or restore request to the Oracle Secure Backup scheduler, the request becomes a job. Oracle Secure Backup assigns each job a name that is unique among all jobs in the administrative domain.

4. At the scheduled time, the service daemon runs the job.

1.6.1 Job Creation

This section provides a more detailed explanation of how on-demand and scheduled file-system backup and restore jobs are created. The following events cause Oracle Secure Backup to create jobs:

• Oracle Secure Backup inspects each trigger defined in each backup schedule every five minutes by default. For each trigger that fires that day, Oracle Secure Backup creates one job for each dataset listed in the schedule.

  Note:

  You can change the frequency with which the scheduler inspects triggers by specifying a different value for the scheduler applybackupsfrequency policy.

  See Also:

  • "Configuring Triggers"

  • Oracle Secure Backup Reference for information on scheduler defaults and policies

  In job descriptions, Oracle Secure Backup identifies this as a dataset job. It assigns the scheduled dataset job a numeric job identifier such as 15.

• Each time you create an on-demand request and then click Go or use the backup --go command in obtool to send your request to the scheduler, Oracle Secure Backup creates a dataset job. It assigns the job an identifier prefixed by the user who runs the command, for example, admin/15.

• At the scheduled start time for a dataset job, Oracle Secure Backup reads the dataset and then creates one subordinate job for each host it includes.

  In job descriptions, Oracle Secure Backup calls this a backup job. Oracle Secure Backup assigns each backup job an identifier whose prefix is the parent (dataset) job id, followed by a dot (.), then followed by a unique small number. For example, 15.1 could be a subordinate job for scheduled job 15.

• Each time you explicitly request that Oracle Secure Backup restore data and then click Go or use the restore --go command in obtool to send your request to the scheduler, Oracle Secure Backup creates a restore job for each backup image that must be read to initiate the restore operation. Oracle Secure Backup assigns each job an identifier such as admin/15.

  If Oracle Secure Backup creates multiple jobs to satisfy one restore request, then it marks each job except the first as dependent on the success of the previous job. The effect of this notation is that, given the failure of a job on which a later job is dependent, that later job is also marked as failed.

After the earliest time to run a job has arrived, the foremost decision criterion that the scheduler uses to run a job is the user-assigned schedule priority. The scheduler dispatches higher priority jobs over lower priority ones, providing all resources required to run the job are available. For example, if twenty jobs are in the scheduler and ready for processing, then Oracle Secure Backup runs the job with the lowest numeric schedule priority.

See Also:

"Performing On-Demand File-System Backups" and "Configuring Backup Schedules"

1.6.2 Job Logs

Oracle Secure Backup keeps a log for each job. This log describes high level events such as the creation, dispatch, and completion times of the job. You can view the log through both the Oracle Secure Backup Web tool and obtool.

See Also:

"Displaying Job Properties"

1.6.3 Job Transcripts

Oracle Secure Backup maintains a running transcript for each job. The transcript of a job describes the details of its operation. Oracle Secure Backup creates this transcript when dispatching the job for the first time and updates it as the job progresses. When a job requires operator assistance, Oracle Secure Backup prompts for assistance using the transcript.

See Also:

"Displaying Job Transcripts"

1.6.4 Job Summaries

A job summary is a text file report produced by Oracle Secure Backup that describes the status of selected file-system backup and restore jobs. Each report contains four sections, distinguished by job status:

• Jobs eligible to be performed now (but not yet started)

• Jobs running now

• Jobs completed successfully

• Jobs canceled, superseded, or failed

You can create a job summary schedule, which enables Oracle Secure Backup to generate multiple summary reports, each covering different time periods or activities. When you create a job summary schedule, you can choose the following options:

• A unique name for the job summary

• The dates on which Oracle Secure Backup produces the job summary

• Users to whom the job summary is e-mailed

• The beginning of the time period spanned by the job summary

  The end time is always the summary generation time.

• The contents of the job summary

See Also:

"Configuring Job Summary Schedules"