Oracle® Secure Backup Administrator's Guide Release 10.1 Part Number B14234-02 |
|
|
View PDF |
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 interfaceThis section describes how Oracle Secure Backup can back up and restore the file system. It contains the following sections:
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.
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
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:
Oracle Secure Backup Reference for a description of the obtool
backup commands
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.
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:
Oracle Secure Backup Reference for a description of the Oracle Secure Backup dataset language
Oracle Secure Backup Reference for a description of the obtool
dataset commands
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
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.
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.
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.
See Also:
"Managing Checkpoints"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.
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
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 selectorsAs 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 |
|
FULL-04, file 3, section 2 (46) |
|
FULL-03, file 3, section 1 (40) and FULL-04, file 3, section 2 (46) |
|
|
FULL-03, file 3, section 1 (40) and FULL-04, file 3, section 2 (46) |
|
earliest |
|
FULL-02, file 5 (20) |
|
FULL-02, file 5 (20) |
|
all |
|
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) |
|
FULL-02, file 5 (20) and FULL-03, file 3, section 1 (40) |
|
20,30 |
|
FULL-02, file 5, section 1 (20) |
|
FULL-02, file 5 (20) and FULL-02, file 9 (30) |
|
05/05 |
|
(none) |
|
FULL-02, file 9 (30) |
|
05/04-05/05 |
|
(none) |
|
FULL-02, file 5 (20) |
|
|
FULL-02, file 5 (20) and FULL-02, file 9 (30) |
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
.
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.
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:
"Backup Catalog" for an overview of the Oracle Secure Backup catalog
"Volumes" for an explanation of volume IDs and backup images
Chapter 12, "Using obtar" to learn how to use obtar
This section describes concepts relating to restore operations in Oracle Secure Backup.
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.
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.
Oracle Secure Backup can mix RMAN backup pieces and file system backup sections within the same volume set and even on the same volume.
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:
Oracle Secure Backup Reference to learn about database backup storage selector commands in obtool
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.
See Also:
Oracle Secure Backup Reference to learn about the obtool
host commands
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
The steps in the process illustrated in Figure 2-5 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 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 executes the job.
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.
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
.
See Also:
"Displaying Job Properties"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.
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 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
See Also:
"Configuring Job Summary Schedules"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:
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:
Matrixes of supported tape devices are available at the following URL:
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.
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:
This element is an internal slot in a library in which a tape cartridge can reside.
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.
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
.
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:
"Executing Library Commands" for a complete list of supported library commands
Oracle Secure Backup Reference for a description of the library commands that you can execute in obtool
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
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:
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 is a single unit of media, such as an 8mm tape.
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:
A volume set is a logical grouping of one or more physical volumes spanned by a backup image. As shown in Figure 2-7, a backup section is the part of a backup image that fits on a single volume.
A media family is a logical classification of volumes that share common attributes. For example, volumes in a media family share a common naming pattern and policies used to write and keep data.
Figure 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.
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
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.
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.
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
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.
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
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.
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.
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:
"Configuring Media Families" to learn how to create media families
Oracle Secure Backup Reference for a description of the media family commands
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.
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:
Oracle Database Backup and Recovery Basics to learn about crosschecking backups
Oracle Database Backup and Recovery Basics to learn about deleting RMAN backups
Oracle Secure Backup Reference to learn about the chmf
command
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.
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.
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.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.
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.
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.
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.
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.
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.
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.
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.
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
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:
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 volumes required for the backup job.
observiced
on the administrative server sends a request to observiced
on the client to invoke obtar
.
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.
obtar
sends catalog information to obixd
on the administrative server and then terminates.
On the administrative server, observiced
sends a job status update to obscheduled
.
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:
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 devices are automatically detected during device discovery as well as when device write warnings are generated.
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.
This policy specifies a WINS server for the administrative domain.
These policies specify NDMP Data Management Agent (DMA) defaults. For example, you can specify a password used to authenticate Oracle Secure Backup to each NDMP server.
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.
These policies control aspects of domain security. For example, you can specify the key size to be used when creating the public/private key pair used in identity certificates in the administrative domain.
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:
Software components must not expose the hosts they run on to attack. For example, a daemon should be prevented from listening on a well-known port and performing arbitrary privileged operations.
Data managed by the backup software must not be viewable, erasable, or modifiable by unauthorized users. Conversely, the backup software must permit authorized users to perform these tasks.
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:
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.
An identity certificate has both a body and a digital signature. The contents of a certificate include the following:
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
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.
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.
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:
Use the obcm
utility to export a signed certificate from the CA.
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.
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.
See Also:
"Managing Certificates with obcm"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 namedcwallet.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 WindowsThe 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.
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.
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.
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 backupsWhen 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.