|Oracle® Secure Backup Administrator's Guide
Part Number E12834-04
This chapter introduces concepts related to backup and recovery using Oracle Secure Backup.
This chapter contains these sections:
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
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
Manage media rotation from one location to another
Automate tape duplication with user-defined policies
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.
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.
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
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:
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.
|Daemon||Administrative Server||Media Server||Client|
Apache Web Server
This section contains these topics:
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.
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.
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.
The Web server daemon is signaled to start by the
observiced daemon, which itself is normally started as part of system startup.
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
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.
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.
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.
Figure 1-2 provides a simplified graphical illustration of the relationships among the daemons on an administrative server, media server, and client.
The client host 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
observiced daemons run on all hosts, the
observiced daemon on the administrative server has invoked the
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:
On the administrative server,
obscheduled sends a request to
observiced to run the backup job.
observiced on the administrative server sends a request to
obrobotd on the media server to mount the each volume required for the backup job.
observiced on the administrative server sends a request to
observiced on the media server to invoke
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.
obtar sends catalog information to
obixd on the administrative server and then terminates.
On the administrative server,
observiced sends a job status update to
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:
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.
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.
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.
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.
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.
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.
These policies control the behavior of the scheduler. For example, you can specify a frequency at which the scheduler attempts to dispatch backup jobs.
Storage 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.
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
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.
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.
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:
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
This option can also be specified as part of the
operations/backupoptions policy. If this option is specified, then it overrides all other factors.
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/maxblockingfactor policies set.
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.
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
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
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
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.
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
label and backup image-related information is displayed with the header
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.
Backup images, volume labels, and the special
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.
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.
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.
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:
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.
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.
A partial volume label for the first backup image could look like the one shown in Example 1-5.
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.
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.
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.
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.
Every volume in a media family shares the following attributes:
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.
A media family can have either of the following mutually exclusive volume expiration policy types: content-managed, which is the default, or time-managed. 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.
As a general rule, although a volume might be unexpired and have unused tape remaining, Oracle Secure Backup does not write to a volume whose sequence number is lower than the most recent volume sequence number for the media family. Every backup tries to append to the most recent volume in the media family. If this volume is full, then it writes to a different one.
There is an exception to this general rule. If you are having problems with a media family, then you might choose to delete it and create a different one with the same name, rather than modifying the existing media family. Each time a media family is re-created, the volume sequence number resets to zero. In this exceptional case, you can end up writing to a volume with a lower sequence number.
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.
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.
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:
In most cases, you should use this file. Volume sequence files for each media family are located in the
family_name directory. For example, if you define a media family with the name
new_data, then files are located in the
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.
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:
8mm to identify volumes created by one tape device and
DAT to identify volumes created by a different tape device
The initials of the operator who performs the backup, for example,
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.
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.
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.
You can make an RMAN backup, but not a file-system backup, to a volume that uses a content-managed expiration policy. A content-managed volume expires when each backup piece on the volume have been marked as deleted. A volume in a content-managed volume set can expire even though the other volumes in the set are not yet expired.
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
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.
Oracle Database Backup and Recovery User's Guide to learn about deleting or crosschecking backups
Oracle Secure Backup Reference to learn about the
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.
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
CROSSCHECKcommand in RMAN to resolve the discrepancy.
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".
See Also:"On-Demand Backups"
The steps in the process illustrated in Figure 1-9 are as follows:
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.
If necessary, the user modifies the requests in the queue. For example, the user can delete a job request.
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.
At the scheduled time, the service daemon runs the job.
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
In job descriptions, Oracle Secure Backup identifies this as a dataset job. It assigns the scheduled dataset job a numeric job identifier such as
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,
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
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
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.
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
See Also:"Displaying Job Properties"
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"
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"