Skip Headers
Oracle® Secure Backup Administrator's Guide
Release 10.1

Part Number B14234-02
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
View PDF

2 Backup and Restore Concepts

This chapter explains the fundamental concepts involved in Oracle Secure Backup backup and restore operations. This chapter contains the following topics:

See Also:

Oracle Secure Backup Reference for details on using the Oracle Secure Backup command-line interface

File System Backup and Restore

This section describes how Oracle Secure Backup can back up and restore the file system. It contains the following sections:

File System Backups

File system data can be defined as the collection of files and file management structures on physical or logical storage. Oracle Secure Backup can back up all types of files on the file system to tape. For example, you can use Oracle Secure Backup to back up the root directory on a host or an Oracle Database home. Backups that you initiate through Oracle Secure Backup are called file system backups.

Full and Incremental File System Backups

A full backup backs up all specified files, regardless of when they were last backed up. This option is the same as an incremental backup at level 0. You can use a level 0 backup as the base of an incremental backup strategy.

Oracle Secure Backup supports 9 different incremental backup levels. In a cumulative incremental backup, Oracle Secure Backup backs up only those files that have changed since the last backup at a lower (numerical) backup level. For example, a level 3 cumulative backup copies only that data that has changed since the most recent backup that is level 2 or lower. Figure 2-1 shows a series of cumulative backups.

Figure 2-1 Cumulative Incremental Backups

Shows that there are 9 levels of incremental backup.
Description of "Figure 2-1 Cumulative Incremental Backups"

In a differential incremental backup, Oracle Secure Backup back up files modified since the most recent incremental backup at the same or lower level (0-9). This option is the same as a level 10 incremental backup. Oracle Secure Backup does not support the level 10 backup in conjunction with some platforms, including NAS devices such as Network Appliance filers.

Oracle Secure Backup includes an offsite backup option that enables you to perform a full backup without affecting the full/incremental backup schedule. This technique is useful when you want to create an archive for offsite storage without disturbing your schedule of incremental backups.

See Also:

Backup Datasets

A dataset file defines the file system data that Oracle Secure Backup should include in and exclude from a backup. Dataset files employ a lightweight language that gives you the flexibility to build and organize the definitions of the data to be backed up.

You can find several sample dataset files in the samples subdirectory of the Oracle Secure Backup home. You can use these as templates to design your own dataset files.

The sample dataset file shown in Example 2-1 instructs Oracle Secure Backup to back up the directory /usr1/home on brhost2 (except for the directories /usr1/home/temp and /usr1/home/oldfiles) and the directory /usr2/home.

Example 2-1 Sample Dataset File

exclude name *.backup
exclude name *~
 
include host brhost2 {
    include path /usr1/home {
        exclude path /usr1/home/temp
        exclude path /usr1/home/oldfiles
    }
    include path /usr2/home
}

Dataset files are hierarchically organized into a directory structure. As shown in Figure 2-2, you can view this structure from the perspective of the operating system or the Oracle Secure Backup catalog.

Figure 2-2 Dataset Directories and Files

Shows the dataset directory structure.
Description of "Figure 2-2 Dataset Directories and Files"

From the operating system point of view, the dataset files and directories are stored in the admin/config/dataset subdirectory of the Oracle Secure Backup home. As shown on the left part of Figure 2-2, the NEW_CLIENTS directory is automatically created during installation. You can use this directory to store your dataset files.

With either obtool or the Web tool, you can execute commands to manage dataset files and directories. You can create your own dataset directories and files and organize them into a tree-like structure. As shown in Figure 2-2, the admin/config/dataset/ subdirectory on the operating system corresponds to the top-level dataset directory in the Oracle Secure Backup catalog.

See Also:

Scheduled and On-Demand Backups

You can create the following types of file system backup requests with Oracle Secure Backup:

  • Scheduled

    In backups of this type, you instruct Oracle Secure Backup to make backups according to a backup schedule, which specifies the datasets for the backup. A trigger defined in the schedule specifies when the job should execute. For example, you can instruct Oracle Secure Backup to back up the /home directory on client host brhost2 every Sunday. Note that jobs scheduled from different time zones will be synchronized with one another.

  • On-demand

    In backups of this type, you instruct Oracle Secure Backup to perform an ad hoc or one-time-only backup of the specified data. For example, you may instruct Oracle Secure Backup to back up the Oracle home on client host brhost2.

As shown in Figure 2-3, the execution of scheduled backup jobs depends on whether a backup window exists in which the jobs can run. A backup window is a time range within which Oracle Secure Backup performs scheduled backup jobs.

Figure 2-3 Backup Windows and Scheduled Backups

Shows the relation between triggers and windows.
Description of "Figure 2-3 Backup Windows and Scheduled Backups"

A single backup window can apply to all days of the week or only to specific days or dates. If the backup window is closed, or if no backup window is defined, then scheduled backups will not run, although you can still run on-demand backups.

Note:

If a job is running when the backup window closes, then it will continue to completion.

The default backup window is daily 00:00-24:00. For an example of how backup windows affect scheduled backups, assume that your only backup window opens daily from midnight to 2 a.m. If the backup schedule trigger fires at 3 a.m., then the backup will never run.

Privileged and Unprivileged Backups

When you use the Web tool or the backup command in obtool to initiate an on-demand backup, the backup runs in unprivileged or privileged mode.

As explained in "Oracle Secure Backup Users and Passwords", an unprivileged backup runs under the Linux/UNIX user identity or Windows account identity configured in the Oracle Secure Backup user profile. Access to file system data is constrained by the privileges of the Linux/UNIX or Windows account.

A privileged backup runs under the root user identity on Linux and UNIX. On Windows systems, a privileged backup runs under the same account identity as the Oracle Secure Backup service on the Windows client. You must have the perform backups as privileged user right to make privileged backups.

If you create a scheduled backup job, then it runs with the privileges of the Oracle Secure Backup scheduler, that is, as root on Linux and UNIX and as Local System on Windows.

Restartable Backups

If a file system backup fails due to an unexpected event like a network failure, power outage, unexpected system shutdown, tape media error, and so on, then Oracle Secure Backup must usually restart the backup from the beginning. Some types of backups are restartable from a mid-point, however, after such a failure occurs.

A backup is restartable if is meets the following conditions:

  • The backup client is a Network Appliance filer running Data ONTAP 6.4 or later.

  • The backup image is saved to a tape drive controlled by a server that uses NDMP version 3 or later.

  • The restartablebackups policy in the operations class is enabled (the default).

  • The backup has reached a point from which it can be restarted.

A checkpoint is a collection of state information that describes a midpoint in a backup and how to restart from it. Some information for each checkpoint resides on the Oracle Secure Backup administrative server, whereas the remainder resides on the client host.

Note:

If you use the restartable backups feature, then ensure that the /tmp directory on the administrative server is on a partition that maintains at least 1 GB of free space.

At the beginning of each backup job, Oracle Secure Backup automatically determines whether the backup can be restarted from a midpoint. If so, it periodically establishes a checkpoint that it can later use to restart the backup. After each new checkpoint is recorded, the previous checkpoint is discarded.

When considering jobs to run, the Oracle Secure Backup scheduler takes note of restartable jobs that were interrupted before completing. Upon finding a restartable job, the scheduler restarts it and uses the same volume and drive in the same library in use when the interruption occurred.

Backup Catalog

As explained in "Administrative Data", the administrative server maintains a catalog in which it stores metadata relating to backup and restore operations for the administrative domain. You can use obtool or the Web tool to browse the catalog to determine what you have backed up.

Note:

The Oracle Secure Backup catalog is integrated to share backup metadata with RMAN, but is separate from the RMAN recovery catalog. The recovery catalog is stored in an Oracle database and is maintained independently by RMAN.

When Oracle Secure Backup performs a file system backup or a database backup through the SBT interface (see "Database Backups"), it records the name and attributes of the objects it backs up. It writes this data to the catalog stored on the administrative server.

Oracle Secure Backup maintains a discrete backup catalog for every client in the administrative domain. The catalog for each host is stored in a subdirectory of admin/history/host named after the client. For example, admin/history/host/brhost2 stores the catalog for the client named brhost2. The catalog itself is a binary file named indices.cur.

To specify backups that you want to restore, you can use obtool or the Web tool to browse the contents of any client's backup catalog, providing you have necessary permissions. The class of which your Oracle Secure Backup user is a member defines your right to browse the catalog. "Oracle Secure Backup Classes and Rights" explains user rights.

When you browse the catalog, Oracle Secure Backup presents the data in the form of a file system tree as it appeared on the client from which the data was saved. At the root of the file system appears a fictitious directory, called the super-directory, that contains all files and directories saved from the top-most file system level. Oracle Secure Backup uses this directory as a starting point from which you can access every top-level file system object stored in the catalog.

Note the following features of the catalog super-directory:

  • On UNIX and Linux systems, it usually contains only the root directory, / (slash).

  • On Windows systems, it contains each top-level file system—identified by a drive letter and a colon—that you backed up.

The Oracle Secure Backup catalog contains a record of each file system object saved in each backup. So, what you would normally consider a two-dimensional representation of a file system—the inverted naming tree—now includes a third dimension, time.

Directory contents change over time; in fact, the very existence of directories is transient. The name of an object backed up yesterday as a directory may, in today's backup, refer to a file, and in tomorrow's backup, a symbolic link. Oracle Secure Backup tracks all such changes in object types properly.

Oracle Secure Backup provides two means to control how time affects the data you select when browsing backup catalogs: the data selector and the view mode.

Catalog Data Selectors

When you browse a backup catalog to select data to restore, you can choose specific instances of backed up data by using one of the data selectors shown in Table 2-1. The data selector describes, either explicitly or by inference, the identity of each backup image section containing the data of interest. "Backup Images and Media" explains backup images and sections.

Table 2-1 Data Selectors

Selector Description

latest

Shows most recent file system objects.

earliest

Shows least recent file system objects.

all

Shows all instances of file system objects.

backup-id

The instance contained in the backup section identified by the backup ID. Within a backup catalog, Oracle Secure Backup identifies each backup image section with a numerical backup ID. It assigns backup IDs without regard to the time order of backups. For example, backup ID 25 can represent the Monday backup of the root directory on a host, whereas backup ID 6 represents the Tuesday backup.

date-time

Shows the file system object as it existed in a backup no later than the given date and time.

date-range

All objects backed up exactly between two date-time values.


When applied to a file system object, a data selector yields the identity of zero or more backup image sections in which the file system object is stored.

See Also:

Oracle Secure Backup Reference for more explanation of data selectors
Using Data Selectors: Example

As an example of how Oracle Secure Backup applies data selectors to specific instances of backed up data, consider a directory called /numbers that you back up fully on each of three days at the beginning of May. The contents of /numbers changes each day. Table 2-2 shows the files that are backed up as well as the volume and image file to which they are written.

Table 2-2 Backup of the /numbers Directory

Date Contents of /numbers Backup volume and image Backup ID

5/1/05

file1.dat   file2.dat   file3.dat

volume FULL-02, file 5

20

5/2/05

file2.dat   file3.dat

volume FULL-02, file 9

30

5/3/05

file1.dat   file2.dat

volume FULL-03, file 3, section 1

40


file2.dat              file4.dat

volume FULL-04, file 3, section 2

46


In Table 2-2, the May 3 backup filled a tape while writing file2.dat. Oracle Secure Backup continued the backup on volume FULL-04 by writing the remainder of file2.dat, followed by file4.dat. Table 2-3 describes the effect of various data selectors on the file system object references.

Table 2-3 Data Selectors for Backups of the /numbers Directory

This data selector and this reference selects the data backed up in these backup image sections (backup ids)

latest

/numbers/file4.dat

FULL-04, file 3, section 2 (46)


/numbers/file2.dat

FULL-03, file 3, section 1 (40) and FULL-04, file 3, section 2 (46)


/numbers

FULL-03, file 3, section 1 (40) and FULL-04, file 3, section 2 (46)

earliest

/numbers/file1.dat

FULL-02, file 5 (20)


/numbers

FULL-02, file 5 (20)

all

/numbers

FULL-02, file 5 (20) and FULL-02, file 9 (30) and FULL-03, file 3, section 1 (40) and FULL-03, file 3, section 2 (46)


/numbers/file1.dat

FULL-02, file 5 (20) and FULL-03, file 3, section 1 (40)

20,30

/numbers/file1.dat

FULL-02, file 5, section 1 (20)


/numbers

FULL-02, file 5 (20) and FULL-02, file 9 (30)

05/05

/numbers/file1.dat

(none)


/numbers

FULL-02, file 9 (30)

05/04-05/05

/numbers/file4.dat

(none)


/numbers/file1.dat

FULL-02, file 5 (20)


/numbers

FULL-02, file 5 (20) and FULL-02, file 9 (30)


Catalog View Modes

The catalog view mode is independent of data selectors. Oracle Secure Backup consults the view mode each time it searches or displays a catalog directory. You control the view mode setting from the Oracle Secure Backup Web tool or command-line interface. There are two view modes: inclusive and exact.

When you browse a directory in inclusive mode, Oracle Secure Backup displays the name of every file system object backed up from the directory. The data selector is ignored. For example, in "Using Data Selectors: Example", a listing of the /numbers directory in inclusive mode displays file1.dat, file2.dat, file3.dat, and file4.dat.

This display behavior assumes the that you did not do the following:

  • Overwrite either backup image

  • Manually clean up the backup catalog

  • Explicitly direct Oracle Secure Backup to retire any backup catalog data

When you browse a directory in exact mode, you display only the contents of a directory identified by the data selector. Assume that in "Using Data Selectors: Example" you set the view mode to exact. In this case, the latest setting in Table 2-3 would display only file1.dat, file2.dat, and file4.dat.

File System Restore Operations

Restoring to the file system with Oracle Secure Backup is essentially the reverse of backing up to the file system. Normally, restore operations are additive. In other words, each file and directory restored from a full or an incremental backup is added to its destination directory.

Note the following differences between backup and restore operations:

  • Whereas file system backups are either scheduled or on-demand (see "Scheduled and On-Demand Backups"), all restore operations are on-demand.

  • Whereas some file system backups are restartable (see "Restartable Backups"), no restore operations are restartable.

  • File system backups use datasets to specify data (see "Backup Datasets"), whereas restore operations use one of the methods described in the following section.

File System Restore Methods

With Oracle Secure Backup, you can restore data in the following ways:

  • Catalog-based restore operation

    In this type of restore operation, you browse the catalog for the file system objects to be restored. When you have located their names and selected the instances, you can restore the objects.

    "Performing a Catalog-Based Restore Operation" explains how to restore data with a catalog.

  • Raw restore operation

    In this type of restore operation, you must have independent knowledge of the secondary storage location (volume ID and backup image file number) of a backup. You can either restore all data in the backup or specify an individual file or directory.

    "Performing a Raw Restore Operation" explains how to restore data without using a catalog.

  • obtar restore operation

    You can use the obtar command-line interface to operate directly on tape drives, outside the purview of the Oracle Secure Backup scheduler. The obtar utility is intended for advanced users only.

See Also:

Database Backup and Recovery

This section describes concepts relating to restore operations in Oracle Secure Backup.

Database Backups

RMAN is a database utility that enables you to back up an Oracle database. Oracle Secure Backup supplies an SBT interface that RMAN can use to back up database files to tape. An SBT backup initiated by RMAN is distinct from a file system backup, which is a scheduled or on-demand backup of any files on the file system (not just database files) initiated by Oracle Secure Backup.

Backup Sets and Backup Images

The backup of an Oracle database performed with RMAN results in a backup set, which is a logical grouping of backup pieces. Backup pieces are physical files.

When you use Oracle Secure Backup to store database backups on tape, each backup piece is created as one backup image. Figure 2-4 illustrates the relationship between pieces and images. As explained in "Volume Sets", a single backup image can span multiple tapes.

Figure 2-4 Backup Sets and Backup Images

Shows that one backup piece is one image.
Description of "Figure 2-4 Backup Sets and Backup Images"

Oracle Secure Backup can mix RMAN backup pieces and file system backup sections within the same volume set and even on the same volume.

Database Backup Storage Selectors

Oracle Secure Backup uses information encapsulated in database backup storage selectors to interact with RMAN when performing backup and restore operations. Oracle Secure Backup maintains storage selectors in the admin/ssel subdirectory of the Oracle Secure Backup home on the administrative server.

Database backup storage selectors contain backup and restore attributes that describe an Oracle database. For example, the storage selector identifies a database by name or DBID (unique numerical identifier), the host on which it resides, and the media family to use when backing it up. Storage selectors act as a layer between RMAN, which backs up and restore the database, and the Oracle Secure Backup software, which manages the underlying media.

When performing an Oracle database backup to devices and media managed by Oracle Secure Backup, RMAN passes the database name, content type, and copy number to Oracle Secure Backup. Using this information, Oracle Secure Backup determines the corresponding database backup storage selector. This storage selector informs Oracle Secure Backup what devices, if any, to restrict this backup to and which media family (if any) to use.

See Also:

Database Restore and Recovery

Restore operations that you initiate through RMAN are called Oracle Database restore operations. You can use the Oracle Secure Backup SBT interface in conjunction with RMAN to restore database files to tape. As explained in "Database Backup Storage Selectors", Oracle Secure Backup uses information encapsulated in storage selectors to interact with RMAN when performing restore operations.

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 2-5 shows the process by which a user can create an on-demand backup or restore job. "Scheduled and On-Demand Backups" explains the difference between on-demand and scheduled backups.

Figure 2-5 Backup and Restore Requests and Jobs

Description of Figure 2-5 follows
Description of "Figure 2-5 Backup and Restore Requests and Jobs"

The steps in the process illustrated in Figure 2-5 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 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 executes the job.

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:

  • At the beginning of the day, Oracle Secure Backup inspects the triggers defined in each backup schedule. Schedules and triggers are described in "Scheduled and On-Demand Backups". For each trigger that fires that day, Oracle Secure Backup creates one new job for each dataset listed in the schedule.

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

  • Each time you create an on-demand backup request and then use the Go button or the obtool backup --go command to send your request to the scheduler, Oracle Secure Backup creates a dataset job. It assigns the job an identifier prefixed by the name of the user who executes 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 use the Go button or the obtool restore --go command 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 execute a job has arrived, the foremost decision criterion that the scheduler uses to execute 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 execution, then Oracle Secure Backup executes the job with the lowest numeric schedule priority.

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 Web tool and obtool.

Job Transcripts

Oracle Secure Backup maintains a running transcript for each job. The transcript describes the details of the job's 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.

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 emailed

  • 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

Tape Devices

Oracle Secure Backup maintains information about tape libraries and tape drives so that you can use them for local and network backup and restore operations. You can configure devices during installation or add a new device to an existing administrative domain. When configuring devices, the basic task is to inform Oracle Secure Backup about the existence of a device and then specify which media server can communicate with this device.

This section contains the following topics:

Tape Drives

A tape drive is a device that uses precisely-controlled motors to wind a tape from one reel to the other. The tape passes a read/write head as it winds. Most magnetic tape systems use small reels that are fixed inside a cartridge to protect the tape and make handling of the tape easier.

A magnetic cassette or tape is sequential-access storage. It has a beginning and an end, which means that to access data in the middle of the tape, a device must read through the beginning part of the tape until it locates the desired data. Data must be read in this way because the tape heads are stationary.

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

Every tape drive supports a specific tape format. Common tape formats include the following:

  • 8mm

  • 4mm, or Digital Audio Tape (DAT)

  • Advanced Intelligent Tape (AIT)

  • Digital Data Storage (DDS)

  • Digital Linear Tape (DLT) and Super DLT (SDLT)

  • Linear Tape-Open (LTO), an open alternative to the proprietary DLT format

Matrixes of supported tape devices are available at the following URL:

http://www.oracle.com/technology/products/secure-backup

Tape Libraries

A tape library is a robotic storage device that accepts SCSI commands to move media between storage locations and tape drives. A library is often referred to as a robotic tape device, autochanger, or medium changer.

A library contains one or more tape drives, a number of slots to hold tape cartridges, and an automated method for loading tapes. Figure 2-6 illustrates a tape library that contains four tape drives.

Oracle Secure Backup automates the management of tape libraries, thereby enabling efficient and reliable use of their capabilities. Oracle Secure Backup controls the library robotics so that tapes can be managed easily.

Oracle Secure Backup supports the following features of tape libraries:

  • Automatic loading and unloading of volumes

    When you add a tape library to your administrative domain, the device is configured in automount mode by default. In this mode, Oracle Secure Backup sends commands to the robotic arm of the library to mount tapes for backup and restore operations. When a new volume is needed, Oracle Secure Backup scans the volumes in the library until it finds a suitable volume. If sufficient eligible tapes are contained in the library storage elements, then no operator intervention is required to load the volumes needed to store the complete backup image.

  • Barcode readers

    A barcode is a symbol code that is physically applied to volumes for identification purposes. Some libraries have an automated barcode reader. Oracle Secure Backup can use barcodes to identify tapes in a tape library.

  • Automatically cleaning tape drives in a tape library

    Oracle Secure Backup checks for cleaning requirements when a tape is loaded into or unloaded from a tape drive. If a cleaning is required, then Oracle Secure Backup loads a cleaning cartridge, waits for the cleaning cycle to complete, replaces the cleaning cartridge in its original storage element, and continues with the requested load or unload. You can also schedule a cleaning interval.

Library Elements

As shown in Figure 2-6, a library consists of a set of addressable elements, each of which can contain a tape or can be used to move a tape. Libraries can contain the following types of elements:

  • Storage Element (SE)

    This element is an internal slot in a library in which a tape cartridge can reside.

  • Data Transfer Element (DTE)

    This element represents a device capable of reading or writing the physical volume. Typically, a DTE is a tape drive used to backup or restore data on a tape.

  • Medium Transport Element (MTE)

    This element represents the robotics mechanism used to move media between other elements in the library. Typically, an MTE is a robot arm that moves tape cartridges from library slots to tape drives.

  • Import/Export Element (IEE)

    This is an element by which media can be imported to and exported from the library. Typically, an IEE is a door-like mechanism that operators use to transfer tapes into and out of the library. After the door is closed, the robotic arm transfers cartridges to internal slots in the library. Because the library itself is not opened during this procedure, a re-inventory is not required.

Many of the Oracle Secure Backup library commands require you to specify one or more library elements, in particular, storage elements and import/export elements. Except in the inventory display, media transport elements are never referenced. Data transfer elements are referenced only in the inventory display and indirectly by the drive (if any) that you select for an operation.

Oracle Secure Backup refers to elements by their abbreviation (mte, se, iee, or dte) followed by the number of the element, for example, se5, iee2, dte1. When there is more than one element of a particular type, element numbering starts at 1. When there is only one element of a type, the number can be omitted: iee1 and iee both refer to the first and only import export element. If the abbreviation is omitted, then a storage element is assumed. For example, se4 and 4 both refer to the fourth storage element. For some commands, you can specify a range of storage elements, for example, 1-5.

Library Operations

Oracle Secure Backup supports a number of library operations. The following operations are the most basic:

  • Inserting and extracting volumes

    If you manually place volumes into library storage elements, then use the insertvol command to notify Oracle Secure Backup of these volumes, their locations and their properties. Similarly, you can use the extractvol command to indicate that you are removing a volume manually from the library.

  • Loading and unloading volumes

    You can use the loadvol command to instruct the tape library to load a volume from a storage element into a tape drive in preparation for a backup. For example, you can instruct the library to load the tape in slot 3 into the drive named tape1. You can also use the unloadvol command to instruct the tape library to unload a volume from a tape drive to a particular storage element.

  • Moving volumes

    You can use the movevol command to move a volume from one storage element to another storage element. For example, you can instruct the library to move a tape from storage element 3 to 1.

  • Importing and exporting volumes

    If the tape library has an import/export element and supports the opendoor command to open the import/export door of a tape library, then you can use this method to transfer tapes into and out of the tape library. You can use the importvol command to move volumes to internal slots in the library and the exportvol command to move volumes out of the tape library.

See Also:

Device Names and Attachments

Each tape device is uniquely identified within Oracle Secure Backup by a user-defined name. Because Oracle Secure Backup manages tape drive operations, it must be able to identify the drive as well as determine whether the drive is housed in a library. Oracle Secure Backup must further determine which storage elements are available for storing tapes while not in use by the drive.

Oracle Secure Backup distinguishes a device and the means by which the device is connected to a host. To be usable by Oracle Secure Backup, each device must have at least one attachment, which describes a data path between a host and the device itself. Typically, an attachment includes the identity of a host plus a UNIX device special file name, a Windows device name, or NAS device name. In rare cases, additional information is needed for the attachment definition.

SAN-attached devices often have multiple attachments, one for each host with local access to the device through its Fibre Channel interface. SAN-attached devices are also distinguished by a World Wide Name (WWN), an internal identifier that uniquely names the device on the SAN. Systems such as Network Appliance filers permit access to SAN-attached devices through their WWN; for such systems, Oracle Secure Backup includes a reference to the WWN in the device attachment's raw device name.

Devices such as certain Quantum and SpectraLogic tape libraries appear to be connected directly to an Ethernet LAN segment and accessed through NDMP. In fact, Oracle Secure Backup views these devices as having two discrete components:

  • A host, which defines the IP address and which you configure through the Web tool Hosts page or the obtool mkhost command

  • A device, which has one attachment to the single-purpose host that serves as the front end for the device

Devices such as DinoStor TapeServer use a single host to service multiple devices.

For NDMP servers that run version 2, other data may be required to define SCSI parameters needed to access the device. These parameters are sent in an NDMP message called NDMP_SCSI_SET_TARGET. Oracle Secure Backup NDMP servers do not use this data or this message.

See Also:

  • "Configuring Tape Devices" to learn how to configure devices

  • The description of the mkdev command aspec placeholder, which describes the syntax and naming conventions for device attachments

Backup Images and Media

To understand Oracle Secure Backup, you need to understand the relationship between the physical backup files and the media on which those files are stored.

Figure 2-7 provides a graphical illustration of how backup files are related to volumes. The concepts are as follows:

Figure 2-7 Backup Images, Backup Sections, and Volumes

Shows the relation between volumes and images.
Description of "Figure 2-7 Backup Images, Backup Sections, and Volumes"

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

Figure 2-8 Volumes, Volume Sets, and Media Families

Shows the relation between volumes and images.
Description of "Figure 2-8 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.

Backup Images and Sections

When you execute a backup in Oracle Secure Backup, you generate a backup image on tape. As shown in Figure 2-9, a backup image is a file that consists of one or more backup sections.

Figure 2-9 Backup Images and Backup Sections

Illustrates a backup image.
Description of "Figure 2-9 Backup Images and Backup Sections"

Backup images are unique identified in the Oracle Secure Backup catalog by their backup IDs. Similarly, backup sections are uniquely identified in the catalog by their backup section IDs. Example 2-2 shows output from the lsbu command for a backup with the ID of 1.

Example 2-2 Backup

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

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

Example 2-3 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

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 one of ways 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 the backup images it contains in the catalog.

Backup Image and Volume Labels

A label contains data that Oracle Secure Backup uses to identify a volume or a backup image. The first block of the first backup image on a volume is referred to as the volume label. It contains the volume ID, owner name, and date and time for the volume creation. The first block of a backup image is referred to as a backup image label. It contains the backup image's file and section numbers and owner.

Backup images and volume labels, as well as the special "End of Data" and "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.

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.

Note:

All the backup images on a volume need to be either labeled or unlabeled. You cannot mix labeled and unlabeled backup images on a volume.

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.

As shown in Figure 2-10, 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 2-10 illustrates the format of a volume that contains two backup images. This figure shows the position of the labels and tape file marks.

Figure 2-10 Two Backup Images on a Volume

Shows two backup images on a volume.
Description of "Figure 2-10 Two Backup Images on a Volume"

Assume that the volume shown in Figure 2-10 is the first volume in the set. The volume label for the first backup image could look like the one in Example 2-4.

Example 2-4 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 2-5.

Example 2-5 Backup Image 2

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

After you create a backup image, Oracle Secure Backup 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 you read a backup image, the volume is positioned after the tape file mark following the backup image that you just read and before the volume label of the next backup image.

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. You can also make efficient use of media by packing backup images onto volumes.

When Oracle Secure Backup reads and writes multiple volumes, it keeps track of the proper order of volumes within the volume set by means of 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.

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

Figure 2-11 A Single Backup Image on Multiple Volumes

Shows a backup image spanning two volumes.
Description of "Figure 2-11 A Single Backup Image on Multiple Volumes"

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

Example 2-6 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 2-7.

Example 2-7 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 2-8.

Example 2-8 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 2-9.

Example 2-9 Backup Image 3, Section 1

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

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 media families to typical backup operations. For example, you could create media families specifically for onsite backups, offsite backups, and incremental backups.

Media Family Attributes

Volumes in a media family share the following attributes:

  • Volume identification sequence

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

    • The tape is written to for the first time.

    • The tape is overwritten from the beginning of tape.

    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.

  • Volume expiration policy

    A media family can have either of the following mutually exclusive volume expiration policies: 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.

    Although a volume may be unexpired and have unused tape remaining, Oracle Secure Backup will 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 new one.

  • Write window

    The beginning of the write window is the time at which Oracle Secure Backup first writes to a volume in the volume set. The write window is a user-specified period of time that applies to all volumes in the set. Oracle Secure Backup continues to append backups to the volume set until the end of this period.

    When the write window closes, Oracle Secure Backup does not allow further updates to the volume set until it expires or is relabeled, reused, unlabeled, or overwritten. Note that if a backup is writing to a tape when the write window closes, the backup completes but no further backups are written to the volume.

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 already been created in this family.

See Also:

Volume Expiration Policies

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

Figure 2-12 Volume Expiration Policies

Shows expiration policies for volumes.
Description of "Figure 2-12 Volume Expiration Policies"

Content-Managed Expiration Policies

You can make RMAN backups, but not file system backups, to volumes that use a content-managed expiration policy. A volume expires when all backup pieces on the volume have been marked as deleted. Note that 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 through the Web tool or the chmf command in obtool.

As shown in Figure 2-12, you can delete backup pieces through the RMAN or Oracle Secure Backup interfaces. Deleting backup pieces by means of 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:

Time-Managed Expiration Policies

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

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

  • The 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.

  • The write window period

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

  • The retention period

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

    The retention period begins when the write window closes for the volume set. This 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, you set the write window for a media family to 7 days. You set the retention period to 14 days, which means that the data on all volumes in the volume set is retained for 14 days from the close of the write window. Assume that 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. In this scenario, all 21 volumes in the set expire on January 22 at noon.

You can make RMAN backups to time-managed volumes. Thus, volumes with a time-managed expiration policy can contain a mixture of file system backups and RMAN backup pieces.

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.

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 new 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. Normally, the volume sequence file is located in the admin/state/general subdirectory of the Oracle Secure Backup home.

Upon defining 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_data00001. Each time Oracle Secure Backup assigns an ID to a new volume, it increments by one. That is, the next volume ID that Oracle Secure Backup assigns is new_data00002 and so on.

  • Administrative domain default volume sequence file

    This file, vol-sequence, is created during installation and 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 new volume, it increments it by one. That is, the next volume ID that Oracle Secure Backup assigns is VOL000002, and so on.

  • User-specified volume sequence file

    When you specify a volume sequence file, Oracle Secure Backup uses the named 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 or DAT to identify volumes created by different devices

    • The prefix INCR or FULL to identify volumes used for full or incremental backups

    • An operator's initials to identify the user 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.

Daemons and Services

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.

Types of Daemons

An Oracle Secure Backup administrative domain uses a variety of daemons to perform backup, restore, and configuration tasks. As explained in "Host Access Modes", these daemons run only in hosts using primary access mode; NDMP-accessed hosts do not have Oracle Secure Backup installed.

The daemon programs are located in the etc subdirectory of the Oracle Secure Backup home on Linux/UNIX, and in the bin subfolder in Windows.

This section describes the Oracle Secure Backup daemons and indicates the hosts on the domain on which they run.

Service Daemon

The observiced daemon provides a wide variety of services. The service daemon 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 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 domain, allows for remote administration of the host, handles certificate operations, and initiates Oracle database backup and restore operations. The requesting host's identity certificate is used to verify that it is permitted to invoke the operation.

On all hosts, the service daemon is normally 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.

Schedule Daemon

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

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

The scheduler policies (see "Defaults and Policies") control how the scheduler dispatches backups.

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.

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 service daemon, which itself is normally started as part of system startup.

NDMP Daemon

The obndmpd daemon implements the NDMP tape service and provides media services to remote clients. The NDMP daemon runs intermittently on a media server.

This daemon is launched by the service daemon in response to client requests to open a channel to a tape drive that is not locally connected to the client. For example, if obtar is performing a backup operation on client C and writing to a tape drive on media server M, then obtar on C directs its I/O requests to an instance of obndmpd running on M.

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 needs to interact with a 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 library, and so on. Each invocation of obrobotd manages a single library. obrobotd exits when all users of a library have closed their connections.

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, and if the associated Oracle Secure Backup user is permitted to perform RMAN backups, then the login to Oracle Secure Backup is permitted.

Daemon Interaction in a File System Backup

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

Figure 2-13 Daemons in an Administrative Domain

Description of Figure 2-13 follows
Description of "Figure 2-13 Daemons in an Administrative Domain"

The client host in Figure 2-13 shows an instance obtar, which is not itself a daemon but the application that serves as the Data Management Application (DMA). obtar is the underlying Oracle Secure Backup engine that manipulates the data and tape services during a backup or restore operation. Typically, you issue commands in obtool or the Web tool, which Oracle Secure Backup then translates internally to obtar commands.

Assume a scenario in which observiced is running on all hosts, observiced on the administrative server has invoked obscheduled and obhttpd, and a client 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 volumes required for the backup job.

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

  4. obtar on the client communicates with obndmpd on the media server until the file system data is written to tape. The client obtar is the data service, while the media server obndmpd is the NDMP tape service.

  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.

Defaults and Policies

Oracle Secure Backup defaults and policies are configuration data that control how Oracle Secure Backup operates within an administrative domain. The data is 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 are as follows:

Network Backup Security

An Oracle Secure Backup administrative domain is a network of hosts. Any such network has a level of vulnerability to malicious attacks. The task of the security administrator is to learn the types of possible attacks and how to guard against them.

An adequately secured backup system must meet the following requirements:

You can use Oracle Secure Backup to meet the preceding requirements. By default, all hosts that run Oracle Secure Backup must have their identity verified before they can join the administrative domain. Hosts within the domain use X.509 certificates for host authentication. After a Secure Sockets Layer (SSL) connection is established between hosts, control and data messages are encrypted when transmitted over the network. SSL protects the administrative domain from eavesdropping, message tampering or forgery, and replay attacks.

Network backup software such as Oracle Secure Backup is only one component of a secure backup network. Oracle Secure Backup can supplement, but not take the place of, the physical and network security provided by administrators.

This section contains the following topics:

Host Authentication and Communication

By default, Oracle Secure Backup uses the SSL protocol to establish a secure communication channel between hosts in an administrative domain. Each host has an X.509 certificate known as an identity certificate. This certificate is signed by the Certification Authority (CA) and uniquely identifies this host within the administrative domain. The identity certificate is required for authenticated SSL connections.

Note:

Currently, the NDMP protocol does not support an SSL connection to filers.

Identity Certificates and Public Key Cryptography

An identity certificate has both a body and a digital signature. The contents of a certificate include the following:

  • A public key

  • The identity of the host

  • The attributes of the host, that is, what the host is authorized to do

Every host in the domain, including the administrative server, has a private key known only to that host that is stored with the host's identity certificate. This private key corresponds to a public key that is made available to other hosts in the administrative domain.

Any host in the domain can use a public key to send an encrypted message to another host, but only the host with the corresponding private key can decrypt the message. A host can use its private key to attach a digital signature to the message. The host creates a digital signature by submitting the message as input to a cryptographic hash function and then encrypting the output hash with a private key.

The receiving host authenticates the digital signature by decrypting it with the sending host's public key. Afterwards, the receiving host decrypts the encrypted message with its private key, inputs the decrypted message to the same hash function used to create the signature, and then compares the output hash to the decrypted signature. If the two hashes match, then the message has not been tampered with.

Figure 2-14 illustrates how host B can encrypt and sign a message to host A, which can in turn decrypt the message and verify the signature.

Figure 2-14 Using Public and Private Keys to Encrypt and Sign Messages

Description of Figure 2-14 follows
Description of "Figure 2-14 Using Public and Private Keys to Encrypt and Sign Messages"

Authenticated SSL Connections

For hosts to securely exchange control messages and backup data within the domain, they must first authenticate themselves to one another. Host connections are always two-way authenticated with the exception of the initial host invitation to join a domain and communication with NDMP servers.

In two-way authentication, the hosts participate in a handshake process whereby they mutually decide on a cipher suite to use, exchange identity certificates, and validate that each other's certificate has been issued by a trusted CA. At the end of this process, a secure and trusted communication channel is established for the exchange of data.

The use of identity certificates and SSL prevents outside attackers from impersonating a client in the administrative domain and accessing backup data. For example, an outside attacker could not run an application on a non-domain host that sends messages to domain hosts that claim origin from a host within the domain.

Certification Authority

The service daemon (observiced) on the administrative server is the root CA of the administrative domain. The primary task of the CA is to issue and sign identity certificates for the hosts in the administrative domain. The CA's signing certificate, which it issues to itself and then signs, gives the CA the authority to sign identity certificates for hosts in the domain. The relationship of trust requires that all hosts in the administrative domain can trust certificates issued by the CA.

Each host stores its own identity certificate as well as a trusted certificate (or set of certificates) that establishes a chain of trust to the CA. Like other hosts in the domain, the CA stores its identity certificate. The CA also maintains a signing certificate that authorizes the CA to sign the identity certificates for the other hosts in the domain.

Automated and Manual Certificate Provisioning Mode

Oracle Secure Backup provides the following methods of initializing the security credentials for a client host that wants to join the domain:

  • An automated mode that is easy to use, but has potential (if unlikely) security vulnerabilities

  • A manual mode that is harder to use but less vulnerable to tampering

In automated certificate provisioning mode, which is the default, adding a host to the domain is transparent. The new host generates a public/private key pair and then sends the certificate request—which includes the public key—to the CA. The CA issues the host an identity certificate, which it sends to the new host along with any certificates required to establish a chain of trust to the CA.

The communication between the two hosts is over a secure but non-authenticated SSL connection. It would be conceivable, although extremely difficult, for a rogue host to insert itself into the network between the CA and the new host, thereby masquerading as the legitimate host and illegally entering the domain.

In manual certificate provisioning mode, the CA does not automatically transmit certificate responses to the new host. You must transfer the certificate as follows:

  1. Use the obcm utility to export a signed certificate from the CA.

  2. Use a secure mechanism such as a floppy disk or USB keychain drive to transfer a copy of the signed identity certificate from the CA to the new host.

  3. Use obcm on the new host to import the transferred certificate into host's wallet. The obcm utility verifies that the certificate request in the wallet matches the signed identity certificate.

You must balance security and usability to determine which certificate provisioning mode is best for your administrative domain.

Oracle Wallet

Oracle Secure Backup stores certificates in an Oracle wallet. The wallet is represented on the operating system as a password-protected, encrypted file. Each host in the administrative domain has its own wallet in which it stores its identity certificate, private key, and set of trusted certificates. Oracle Secure Backup does not share its wallets with other Oracle products.

Besides maintaining its password-protected wallet, each host in the domain maintains an obfuscated wallet. This version of the wallet does not require a password. The obfuscated wallet, which is scrambled but not encrypted, enables the Oracle Secure Backup software to run without requiring a password during system startup.

Note:

To reduce risk of unauthorized access to obfuscated wallets, Oracle Secure Backup does not back them up. The obfuscated version of a wallet is named cwallet.sso. By default, the wallet is located in /usr/etc/ob/wallet on Linux and UNIX and C:\Program Files\Oracle\Backup\db\wallet on Windows

The password for the password-protected wallet is generated by Oracle Secure Backup and not made available to the user. The password-protected wallet is not normally used after the security credentials for the host have been established because the Oracle Secure Backup daemons use the obfuscated wallet.

Figure 2-15 illustrates the relationship between the CA and other hosts in the domain.

Figure 2-15 Oracle Wallets

Description of Figure 2-15 follows
Description of "Figure 2-15 Oracle Wallets"

Web Server Authentication

As explained in "Oracle Secure Backup Interfaces", you can manage Oracle Secure Backup through the Web tool. The Apache Web server for the administrative domain runs on the administrative server as the obhttpd daemon. When you issue commands through the Web tool, obhttpd repackages them as obtool commands and passes them to an instance of obtool running on the administrative server.

The Web server requires a signed X.509 certificate and associated public and private keys to establish an SSL connection with a client Web browser. The X.509 certificate for the Web server is self-signed by the installob program when you install Oracle Secure Backup on the administrative server. Figure 2-16 shows the interaction between Web server and client.

Figure 2-16 Web Server Authentication

Description of Figure 2-16 follows
Description of "Figure 2-16 Web Server Authentication"

The Web server X.509 certificate and keys are not stored in the wallet used for host authentication in the Oracle Secure Backup administrative domain, but are stored in files in the /apache/conf subdirectory of the Oracle Secure Backup home. A single password protects the certificates and keys. This password is stored in encrypted form in the /admin/config/default/daemons file. When the Web server starts, it obtains the password by using a mechanism specified in the Web server configuration file. This password is never transmitted over the network.

Data Encryption

Figure 1-2, "Administrative Domain with Five Hosts" illustrates the control flow and data flow within an administrative domain. Control messages exchanged by hosts in the administrative domain are encrypted by SSL.

Data flow in the domain includes both file system and database backup data. To understand how backup encryption affects data, it is helpful to distinguish between data at rest, which is backup data that resides on media such as disk or tape, and data in transit, which is backup data transferred over the network.

File system backups on tape (data at rest) are not encrypted by Oracle Secure Backup. RMAN-encrypted backups made through the Oracle Secure Backup SBT interface are supported, but the encryption is provided by RMAN before the backup is provided to the SBT interface. The Oracle Secure Backup SBT is the only supported interface for making encrypted RMAN backups directly to tape.

By default, the backup data in transit within an administrative domain, both file system and database data, is encrypted through SSL. To improve performance, you can disable encryption for data in transit within the administrative domain with the encryptdataintransit security policy (see "Defaults and Policies").

Note:

If database backup data is first encrypted by RMAN, then the data is not further encrypted in transit.

Table 2-4 explains how Oracle Secure Backup handles data encryption. The table assumes that you have chosen not to disable SSL encryption for backup data in transit within the domain.

Table 2-4 Data Encryption

Type of Backup Data Encrypted at Rest Encrypted in Transit

File system

No

Yes

Database backup not encrypted by RMAN

No

Yes

Database backup encrypted by RMAN

Yes

Yes, but only because it is already encrypted: RMAN-encrypted data is not encrypted again by SSL


For example, suppose RMAN makes an encrypted backup of a database on client host C to a tape drive attached to media server S. RMAN encrypts the backup before it is provided to the SBT interface on client C. Oracle Secure Backup transfers the RMAN-encrypted data over the network to server S. Oracle Secure Backup does not apply additional encryption to the data as it passes over the network. After Oracle Secure Backup writes the data to tape, the data resides on tape in encrypted form.

Assume a different case in which you use Oracle Secure Backup to back up the file system on host C to the tape drive attached to server S. Oracle Secure Backup sends the unencrypted backup data over the network to server S. Oracle Secure Backup applies encryption to the data as it passes over the network. After Oracle Secure Backup writes the data to tape, the file system data resides in unencrypted form.

See Also:

Oracle Database Backup and Recovery Advanced User's Guide to learn about encryption of RMAN backups

Default Security Configuration

When you install Oracle Secure Backup on the administrative server, the installation program configures the administrative server as the CA automatically. By default, security for an administrative domain is configured as follows:

  • SSL is used for host authentication and message integrity.

  • The CA signs and issues the identity certificate for each domain host in automated certificate provisioning mode.

  • The size of the public and private key for every host in the domain is 1024 bits.

  • Host communications within the domain are encrypted by SSL.

When you add hosts to the administrative domain, Oracle Secure Backup creates the wallet, keys, and certificates for each host when you create the hosts in obtool or the Web tool. No additional intervention or configuration is required.

Refer to Chapter 11, "Configuring Security: Advanced Topics" if you plan change the default configuration in any of the following ways:

  • Disable SSL for inter-host authentication and communication by setting the securecomms security policy

  • Transmit identity certificates in manual certificate provisioning mode

  • Set the key size for a host to a value greater or less than the default of 1024 bits

  • Disable encryption for backup data in transit by setting the encryptdataintransit security policy

Besides explaining how to perform the preceding tasks, the advanced security chapter provides instructions for planning security in an administrative domain. The chapter also explains how Oracle Secure Backup manages certificates, keys, and wallets.