1 Oracle Secure Backup Concepts

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

This chapter contains these sections:

• Overview of Oracle Secure Backup Features

• Overview of Oracle Secure Backup Administrative Concepts

• Overview of Oracle Secure Backup Media Concepts

Overview of Oracle Secure Backup Features

Oracle Secure Backup is a centralized, network based backup management application that backs up both Oracle Databases and file-system data across most popular Linux, Unix, and Windows operating systems. Oracle Secure Backup acts as a SBT interface for use with Recovery Manager (RMAN). Oracle Secure Backup has ongoing support added for most major brand tape drives and libraries in Storage Area Network (SAN) and SCSI environments. A current list of supported hardware is available at the following URL:

http://www.oracle.com/technetwork/database/database-technologies/secure-backup/learnmore/index.html

Oracle Secure Backup enables you to do the following:

• Centrally manage backup and restore operations of distributed, mixed-platform environments to tape, disk pool, and cloud storage devices.

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

  See Also:

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

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

• Enables efficient utilization of storage resources

  You can initially store your backups to disk and periodically move them to tape devices thus reducing contention caused by writing backups only to tape devices.

• Encrypt all stored data

  See Also:

  Managing Backup Encryption

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

• Perform a multilevel incremental backup

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

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

• Create backups that span multiple volumes

  A volume is a unit of media, such as an LTO5 tape cartridge.

• Optimize tape resources with automatic tape drive sharing

• Restore data rapidly

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

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

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

• Manage media rotation from one location to another

• Automate tape duplication with user-defined policies

• Temporarily use a disk pool as an interim container for a backup image that is ultimately destined to be written to another container, usually tape. See Copying or Moving Backup Image Instances.

• Back up data to Oracle Cloud Infrastructure Object Storage Classic by configuring individual containers as cloud storage devices. See Oracle Secure Backup Installation and Configuration Guide.

• Compress backup data, choosing from various levels of compression based on the desired compression ratio, backup speed, and computing resources available. Compression requirements can be set at the backup job level, host level, or domain level. For more information, see Oracle Secure Backup Reference for a description of the --compression option of the backup command.

Overview of Oracle Secure Backup Administrative Concepts

Oracle Secure Backup manages the backup and restore operations for heterogeneous environments by organizing the host computers into an administrative domain. The administrative domain consists of one administrative server, one or more media servers, and one or more clients.

After you create a request for a backup or restore operation, Oracle Secure Backup creates a job corresponding to this request when the request is eligible to run. Information about each job in maintained job logs, job transcripts, and job summaries.

You can use configuration settings called policies to manage the operations in the administrative domain. Policies are maintained on the administrative server. Defaults enable you to provide default values for a configuration setting.

Oracle Secure Backup maintains a consistent user identity across the administrative domain by storing information about users, rights, and classes. You can grant individual rights to users or assign a class, which is a named set of rights. Oracle Secure Backup provides a set of preconfigured classes.

This section contains the following topics:

• About the Administrative Domain

• About the Oracle Secure Backup Catalog

• About Configuration Files

• About Defaults and Policies

• About Jobs and Requests

• About Users and Classes

• About Oracle Secure Backup Daemons

About the Administrative Domain

The administrative domain is a network of hosts that are managed as a common unit to perform backup and restore operations. Each host in the administrative domain must be assigned one of the following roles:

• Administrative server

  The administrative server contains configuration information about all hosts in the domain. It also stores the backup catalog that contains metadata about the backup and restore operations. You can have only one administrative server in an administrative domain.

• Media server

  A media server is a host that has secondary storage devices attached to it. It manages the movement of data to and from the secondary storage devices. Media servers can be directly attached to SAN-attached disk pools or tape drives that are either standalone or contained in tape libraries.

• Client

  Any host in the administrative domain containing data that needs to be backed up is referred to as a client. Clients can include Oracle Databases and file-system data, they can be NDMP NAS servers, Linux, Unix, or Windows hosts. The administrative server can also act as a client if it's data is backed up.

Hosts can be assigned multiple roles in an administrative domain. A media server can also act as a client because it contains an Oracle Database that needs to be backed up. Data that needs to be backed up can exist either on the client or on media servers.

See Also:

Oracle Secure Backup Installation and Configuration Guide for more information about and examples of the administrative domain

Oracle Secure Backup Home: Directory Structure

Oracle Secure Backup organizes information about the administrative domain as a hierarchy of files in the Oracle Secure Backup home on the administrative server. The Oracle Secure Backup Home directory is the install location for the software. The files which define the administrative domain, are organized in a structured hierarchy on the administrative server in the Oracle Secure Backup Home directory.

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

Figure 1-1 Directories on the Administrative Server

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

About the Oracle Secure Backup Catalog

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 review what you have backed up and search for items to restore.

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

When Oracle Secure Backup performs a file-system backup or a database backup through the SBT, it records the name and attributes of the objects it backs up. It writes this data to the catalog stored on the administrative server. It also stores information about the backup image instances that are associated with each backup image.

See Also:

"Database Backups"

Backup Catalog: Directory Structure

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.

When Oracle Secure Backup acts in the role of the SBT media manager for RMAN backups, piece data is stored in database files located in the directory admin/state/general/ called sbtpiece.dat and sbtpiece.idx.

See Also:

"Overview of Oracle Secure Backup Classes and Rights" for more information about 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.

The catalog super-directory usually contains only the root directory on UNIX and Linux systems. On Windows systems, it contains each top-level file system that you backed up, each identified by a drive letter and a colon.

The Oracle Secure Backup catalog contains a record of each file-system object saved in each backup. Directories come and go and their contents change over time. For example, the name of an object backed up yesterday as a directory might refer to a file in a backup today and a symbolic link in a backup tomorrow. Oracle Secure Backup tracks all such changes in object types properly.

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

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

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

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

• (number of unmodified existing files) * 0.5

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

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

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

• (number of unmodified existing files) * 0.5

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

Note:

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

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

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

See Also:

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

About Importing Backup Catalog Data from Tape

Oracle Secure Backup supports importing and cataloging backups from tape using the importvol and obtar commands. The catalog on tape feature makes this process more efficient.

As of Oracle Secure Backup 12.1, you can import and catalog backups from tape into your Oracle Secure Backup domain through a much faster process. As a result, you can browse the Oracle Secure Backup catalog and select files for restore from volumes that were previously not known to the current administrative domain. Example 1-1 explains how to import and catalog a volume.

As a result of cataloging the volume, you can now view the information about the backup as though it had been originally created in the current domain.

See Also:

• Oracle Secure Backup Reference for more information about the importvol and obtar commands

• "Managing Catalog Imports" for more information about how to import and catalog backups

About Catalog Import Encryption

As a part of import catalog, you can import file information from tape into the Oracle Secure Backup domain without an encryption key. However, it is mandatory to have an encryption key while performing the restore operation.

To obtain the encryption key for a new Oracle Secure Backup domain, you must specify the passphrase option while performing restore. This option stores the restore passphrase for all future restore operations.

See Also:

Oracle Secure Backup Reference for more information about the restore command options

Example 1-1 Cataloging a Volume

In this example, Oracle Secure Backup scans the tape drive vt1 and catalogs the volume with the volume ID VOL000001. This example assumes that all volumes in the volume set are a part of the Oracle Secure Backup volumes database.

ob> catalog --vid VOL000001 --drive vt1
Info: catalog import request 1 submitted; job id is admin/21.

About Configuration Files

Oracle Secure Backup administrative data includes domain-wide entities related to backups. These include users, classes, tape devices, disk pools and media families. Figure 1-1 shows the config directory which contains several subdirectories, each of which represents an object that defines the administrative domain. Each object directory contains Oracle Secure Backup files describing the object's characteristics.

About Defaults and Policies

Oracle Secure Backup defaults and policies are configuration settings that determine the way an Oracle Secure Backup operates administrative domain will function. Policy settings are maintained on the administrative server. The policy defaults are set conservatively and are sufficient to maintain security and protect data on most corporate networks. But if you have special requirements, environments, or backup strategies, then it is recommended that you review these settings during install to confirm that they meet your requirements.

Oracle Secure Backup policies are grouped into several classes. Each policy class contains parameters related to a particular aspect of Oracle Secure Backup operations.

Note:

Do not confuse policy classes, which are only an organizational convenience, with user classes.

Classification of Policy Classes

Policy classes related to managing Oracle Secure Backup backup and restore functions are as follows:

• Backup compression Policies

  These policies, if set, control the compression related settings of file system backups on Oracle Secure Backup clients if compression is not set at the host or job level.

• Backup encryption policies

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

• Cloud Policies

  These policies control the behavior of various operations when the target is a cloud storage device.

• Copy backup image instance policies

  These policies control how backup image instance copies are created. For example, you can specify a default priority for copy instance jobs.

• Daemon policies

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

• Device Policies

  These policies control how backup containers are automatically detected during device discovery. They also control when tape device write warnings are generated.

• Duplication policies

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

• Index policies

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

• Log policies

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

• Media policies

  These policies control media management for the administrative domain. For example, you can choose whether tapes are required to have barcode labels and set the retention period and write window for volumes in the default media family.

• Naming policies

  This class contains one policy which specifies the IP address of an Windows Internet Name Service (WINS) Server for the administrative domain.

• NDMP policies

  These policies control settings applicable to hosts that use NDMP access mode and specify NDMP defaults. For example, you can configure backup environment variables, specify a user name for authentication, or specify a password used to authenticate Oracle Secure Backup to each NDMP server.

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

• Operations policies

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

• Scheduler policies

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

• Security policies

  These policies control aspects of administrative domain security. For example, you can enable SSL encryption for backup data in transit or set the host identity certificate key size. Oracle Secure Backup Installation and Configuration Guide explains how to change the default security policies.

• Staging policies

  These policies control aspects of stagescan jobs.

• Vaulting policies

  These policies control media management, which includes the rotation of tapes from one location to another as part of a data protection strategy.

See Also:

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

About 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.

Scheduler policies determine how the scheduler handles backup and restore jobs. You should familiarize yourself with these settings because they determine the frequency with which the scheduler dispatches jobs.

Note:

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

See Also:

• About Defaults and Policies for a description of scheduler policies.

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

Figure 1-2 Backup and Restore Requests and Jobs

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

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

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

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

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

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

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

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

About Job Creation

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

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

  Note:

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

  See Also:

  • "Configuring Triggers"

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

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

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

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

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

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

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

After the earliest time to run a job has arrived, the next criterion used by the scheduler to determine which job to run next is the user-assigned schedule priority. The scheduler dispatches jobs in order of their priority to all available resources and then waits for resources to become available and continues to dispatch the jobs. The job with the lowest numeric schedule priority corresponds with the highest actual job priority and will be dispatched first.

See Also:

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

About Job Logs

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

See Also:

"Displaying Job Properties"

About Job Transcripts

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

See Also:

"Displaying Job Transcripts"

About Job Summaries

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

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

• Jobs running now

• Jobs completed successfully

• Jobs canceled, superseded, or failed

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

• A unique name for the job summary

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

• Users to whom the job summary is e-mailed

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

  The end time is always the summary generation time.

• The contents of the job summary

See Also:

"Configuring Job Summary Schedules"

About Users and Classes

Oracle Secure Backup provides user-level access control through users and classes. Information about users and classes is stored on the administrative server. An Oracle Secure Backup user is an entity who has the same identify across the administrative domain. You can use classes to grant the privileges that the user requires to perform backup, recovery, or administrative operations. A class is a named collection of rights that can be granted to Oracle Secure Backup users.

Oracle Secure Backup contains a set of predefined classes. When you install Oracle Secure Backup, the admin user is automatically created and is assigned the predefined admin class. You can create additional Oracle Secure Backup users and assign the required classes or operating system privileges to users. You can also define your own class and assign rights to this class.

See Also:

Managing Users and Classes

About Oracle Secure Backup Daemons

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

Note:

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

This section contains these topics:

• Types of Daemons

• Daemon Interaction in a File-System Backup

Types of Daemons

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

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

Table 1-1 Oracle Secure Backup Daemons by Host Type

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

This section contains these topics:

• Service Daemon

• Schedule Daemon

• Index Daemon

• Apache Web Server Daemon

• NDMP Daemon

• Robot Daemon

• Pool Manager Daemon

• Proxy Daemon

Service Daemon

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

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

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

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

Schedule Daemon

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

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

Scheduler policies control how a backup request is scheduled.

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

NDMP Daemon

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

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

Robot Daemon

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

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

Pool Manager Daemon

The obpoolmgr daemon manages the contents of disk pools. It runs continuously on the administrative server.

The obpoolmgr daemon deletes expired backup image instances, monitors disk pool space usage, and interacts with obtar when the disk pool runs out of space during a backup operation. Backup image instances are not deleted at the time they expire. They are deleted when the free space in the disk pool falls to below the threshold specified for the disk pool.

Proxy Daemon

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

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

Daemon Interaction in a File-System Backup

The following figure provides a simplified graphical illustration of the relationships among the daemons on an administrative server, media server, and client.

Figure 1-3 Daemons in an Administrative Domain

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

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

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

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

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

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

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

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

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

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

Overview of Backup Images and Backup Image Instances

A backup image is a set of data that comprises the product of one backup operation. A backup image instance contains the actual backup data.

When a backup operation is started, Oracle Secure Backup creates the following:

• backup image

  A backup image stores basic information about the backup that is not specific to the backup container in which the backup data is stored.

  See Also:

  "Backup Images"

• backup image instance

  A backup image instance contains the backup data and certain additional information about the backup. Oracle Secure Backup creates one backup image instance based on the parameters specified during the backup operation. For example, if you specified that the backup must be created using the tape drive my_drv, a backup image instance is created using the volume in this tape drive.

  See Also:

  "Backup Image Instances"

You can create additional backup image instances, on different backup containers, if required.

Backup Images

A backup image is a set of metadata that describes a backup. It contains information about the backup such as the backup name, type of backup, creation date, size, backup level, and backup UUID. Each backup operation creates exactly one backup image. Oracle Secure Backup assigns a backup UUID to each backup image. The backup image UUID is unique across the administrative domain.

See Also:

Oracle Secure Backup Reference for information about the format used for backup image names

When you perform a backup operation, you can specify a name for the backup image. Each backup image name must be unique within the Oracle Secure Backup catalog. If you do not specify a date in the name, then a six-digit date in the —yymmdd format is automatically appended to the backup image name. If you do nott include a time in the name, a six-digit time in the -hhmmss format is automatically appended to the backup image name. If you do not add a date or time in the name, then both values in the -yymmdd-hhmmss format are automatically appended to the backup image name. If you do not specify a name, then Oracle Secure Backup generates a name comprised of the host name, timestamp, and a system-generated sequence number.

Backup images can contain the following types of data:

• File-system data from a host in the Oracle Secure Backup domain

• RMAN-generated backup piece containing part of an Oracle Database backup

• Data generated by a backup operation from an NDMP data service

Backup Image Instances

Oracle Secure Backup can write backup data to multiple backup containers. A backup image instance is a complete representation of a backup image that is stored in a particular backup container. Backup image instances contain the actual data that is backed up. There can be multiple backup image instances for a particular backup image, with each instance being stored in a different backup container.

For example, when you perform a file-system backup, Oracle Secure Backup creates a backup image and a backup image instance. Assume that this backup image instance is created on a tape drive drive1. Subsequently, you can create other instances of this backup image on a tape drive drive2 and a disk pool my_disk. The backup data contained in all the backup image instances is the same. However, because they are stored on different media, some properties such as the media family and encryption type may be different.

Oracle Secure Backup assigns a UUID to each backup image instance. This UUID is unique across the administrative domain. Each backup image instance is also assigned a name that is unique across the administrative domain. Oracle Secure Backup generates the name of the backup image instance based on the name of its associated backup image. For example, for a backup image called daily_db_bk, the first backup image instance created is called daily_db_bk.1, the next instance created is called daily_db_bk.2 and so on.

See Also:

Oracle Secure Backup Reference for information about the format that can be used for backup image names

While storing backups on tape, each backup image instance is followed by backup catalog data. During an import catalog operation, the backup catalog data provides the information which rebuilds that backup image instance, within the Oracle Secure Backup catalog file, on the current Oracle Secure Backup domain. By default, this function catalogs information about all the backup image instances stored within a volume set.

Relationship Between Backup Images and Backup Image Instances

Figure 1-4 illustrates the relationship between backup images and backup image instances. When a backup operation completes, Oracle Secure Backup creates the backup image MY_BKUP and the backup image instance MY_BKUP.1. This instance is created in the tape volume VOL0001. Subsequently, another backup image instance is created on the disk pool MY_DP. The name of the backup image is MY_BKUP.2. Each backup image instance has its own unique UUID.

Figure 1-4 Backup Images and Backup Image Instances

Description of "Figure 1-4 Backup Images and Backup Image Instances"

Backup Image Instances and Catalog Data

When backup image instances are written to a backup container, Oracle Secure Backup stores the catalog data for this backup along with the backup image instance. This catalog data enables you to quickly update the catalog when a backup container is imported into another administrative domain. Storing the catalog data along with the backup image instance also helps in disaster recovery scenarios. If the Oracle Secure Backup catalog information has been damaged and no backup copy of the catalog is available, this information can be used to recreate the catalog.

Overview of Oracle Secure Backup Media Concepts

Oracle Secure Backup stores the backups created as part of your data protection strategy on the specified storage media. This section provides an overview of the storage media and describes how backups are stored on different storage media.

This section contains the following topics:

• About Backup Containers

• About Backup Sections

• About Volumes

• About Volume Sets

• About Disk Pools

• About Backup Image Instances and Tape Volumes

• About Data Blocks and Blocking Factors

• About Media Families

• About Cloud Storage Devices

About Backup Containers

A backup container is the physical media on which backup image instances are stored. When you perform a backup operation, you can specify the backup container in which the backup should be stored. You can also copy or move backup image instances from one backup container to another.

Oracle Secure Backup supports the following types of backup containers:

• Disk pools

  A disk pool is a file-system directory that is a repository for backup image instances. The contents of the file-system directory are managed by Oracle Secure Backup.

  See Also:

  "About Disk Pools"

• Tape volumes

  A tape volume is a physical piece of media such as the LTO5 tape cartridge. Tape volumes are physical cartridges that have been assigned a volume ID by Oracle Secure Backup. This volume ID is referenced by the catalog for performing restores. These volumes can reside in tape drives, libraries, vaulted or stored elsewhere at the system administrator's discretion.

  See Also:

  "About Volumes"

• Cloud storage devices

  Cloud storage devices store data in:

  • Oracle Cloud Infrastructure Object Storage Classic

  • Oracle Cloud Infrastructure Archive Storage Classic

  • Oracle Cloud Infrastructure Standard Object Storage

  • Oracle Cloud Infrastructure Archive Object Storage

  • Oracle Cloud Infrastructure Infrequent Access Object Storage

  Oracle Secure Backup creates a new container in the Oracle Cloud for each cloud storage device configured. All data backed up to a cloud storage device is stored in its associated container in the cloud.

  See Also:

  • "About Cloud Storage Devices"

  • The obtool commands "mkdev"and "lsdev"for more information about Cloud storage class options

Default Backup Container for Backup and Restore Operations

By default, Oracle Secure Backup stores backup image instances on tape. Backup image instances will be stored on disk pool if any of the following conditions are met:

• No tape devices are configured in the Oracle Secure Backup domain

• The backup job (on-demand or scheduled) has the disk pool configured as a device restriction

Oracle Secure Backup does not use cloud storage devices as targets for any job by default. It backs up data to a cloud storage device only if the cloud storage device is specified as a restriction in a job command.

While restoring data, Oracle Secure Backup first attempts to restore data from any available, online disk pool. If the required data is not available on disk pool, then Oracle Secure Backup restores it from tape. If the data is not available on tape, then it is restored from cloud storage.

About Backup Sections

A backup image instance can consist of one or more backup sections. A backup section is a portion of a backup image instance that is stored contiguously in a backup container. Each backup section is identified by a unique backup section ID that is generated by Oracle Secure Backup when the backup section is created.

When a backup image instance spans multiple tape volumes, the number of backup sections is the same as the number of tape volumes on which the backup image instance resides.

When a backup image is written to a disk pool, the entire backup image instance consists of exactly one backup section.

See Also:

"Backup Image Instances and Backup Sections"

About Volumes

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

In addition to volume IDs, volumes can have tags. A volume tag is an alphanumeric string, up to 31 characters in length, that is typically obtained from a UPC barcode label affixed to the tape cartridge. Most libraries are equipped with barcode readers. This enables Oracle Secure Backup to determine the identity of a tape without having to load it and read the volume label. Oracle Secure Backup correlates volume tags with volume IDs and remembers what backup image instances they contain for use during backup and restore operations.

Backup Image Instances and Volume Labels

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

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

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

Oracle Secure Backup numbers each backup image instance on a labeled volume set with a backup image file number, starting from 1.

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

Figure 1-5 Two Backup Image Instances on a Volume

Description of "Figure 1-5 Two Backup Image Instances on a Volume"

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

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

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

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

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

Example 1-2 Backup Image Instance 1

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

Example 1-3 Backup Image Instance 2

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

About Volume Sets

Oracle Secure Backup enables a single backup image instance to span multiple volumes. A volume set is a group 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 greater than the sequence number of the previous volume. Consequently, you can back up or restore large amounts of data in a single session. Oracle Secure Backup always attempts to continue onto the next number in sequence with the current volume but in some cases this isn't possible. In this scenario, we will write to the next available volume ID in the same media family that has not been yet written to. Oracle Secure Backup will not allow any tape other than the first tape in the volume set to append to an existing Oracle Secure Backup volume, subsequent tapes will always write to a new volume using the next available volume ID in the sequence. For instance, if the first tape in a volume set was VOL00005, but volumes VOL00006 and VOL00007 have already been written to with other backups, then the second tape in VOL00005's volume set will be VOL00008.

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

• EOV labels

  If a backup image instance 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 instance that spans multiple volumes.

  Note:

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

Figure 1-6 illustrates a volume set that contains three backup image instances. Backup image instance 2 spans two volumes.

Figure 1-6 A Single Backup Image Instance on Multiple Volumes

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

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

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

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

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

Example 1-4 Backup Image Instance 1, Section 1

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

Example 1-5 Backup Image Instance 2, Section 1

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

Example 1-6 Backup Image Instance 2, Section 2

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

Example 1-7 Backup Image Instance 3, Section 1

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

About Disk Pools

A disk pool is a file-system directory that acts as a repository for backup image instances. Each disk pool is associated with a file-system directory path and the contents of this directory are managed by Oracle Secure Backup. Disk pools can store file-system backups, RMAN backups of Oracle Databases, and backups created by NDMP filers. Disk pools can be accessed concurrently by multiple backup and restore operations thus providing improved performance for backup and restore jobs.

Each disk pool is represented as a device in Oracle Secure Backup. A disk pool can belong to only one Oracle Secure Backup administrative domain. It cannot be shared between multiple Oracle Secure Backup administrative domains.

Backup image instances remain in the disk pool until they expire, are explicitly deleted, or moved to tape. Oracle Secure Backup deletes expired backup image instances only when the disk pool space threshold is exceeded and not immediately after they expire.

Storage Capacity on Disk Pools

When you create a disk pool, it is recommended that you set a capacity value. A capacity value represents the amount of space that can be occupied by the backup image instances stored on this disk pool. When the specified capacity is reached, Oracle Secure Backup does not schedule any jobs for this disk pool until the space consumption drops below the capacity.

If a disk pool does not have a capacity set (unlimited capacity), then the current space utilization is used as the capacity value. The free-space-goal percentage is applied to that value and a purge is automatically performed to that utilization level.

For example, if the current disk pool utilization is 100 GB and the free space goal is 20%, then 20 GB of the space used by expired backup images (assuming such was available) is purged.

See Also:

"Monitoring Disk Pool Space Utilization"

Space Utilization in Disk Pools

For each disk pool, you can specify a threshold value for space utilization. This threshold is referred to as the free space goal. It is expressed as a percentage and represents the amount of free space that Oracle Secure Backup attempts to maintain in the disk pool. When the space consumed by a disk pool exceeds the specified threshold, Oracle Secure Backup deletes expired backup image instances.

See Also:

"Monitoring Disk Pool Space Utilization"

Disk Pool Orphans

If a backup to a disk pool fails, then the existing data related to this backup on the disk pool is not added to its disk pool catalog. Oracle Secure Backup does not detect the presence of these backup files on the disk pool. Such files are named orphans. Oracle Secure Backup runs a daily automatic cleanup process to delete files that do not have corresponding entries in the catalog. In some cases, this may cause loss of important data. Hence, it is highly recommended that you catalog your disk pool immediately after importing it into a new domain to avoid the automatic deletion of disk pool orphans during its cleanup. You can disable the daily cleanup process by changing policy settings.

See Also:

• "Managing Disk Pools" for more information on performing disk pool tasks

• "Importing and Cataloging Backups" for more information on cataloging disk pool data

• Oracle Secure Backup Reference for more information on the deletediskorphans policy.

About Backup Image Instances and Tape Volumes

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

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

• A volume is a unit of media, such as an LTO5 tape cartridge.

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

• A backup image is the product of a backup operation and stores metadata about the backup.

• A backup image instance is the product of a backup operations and stores the actual data backed up.

Figure 1-7 Backup Image Instances, Backup Sections, and Volumes

Description of "Figure 1-7 Backup Image Instances, Backup Sections, and Volumes"

Backup Image Instances and Backup Sections

When you run a backup operation in Oracle Secure Backup, you create a backup image instance. As shown in Figure 1-8, a backup image instance is a file that consists of at least one backup section.

Figure 1-8 Backup Image Instances and Backup Sections

Description of "Figure 1-8 Backup Image Instances and Backup Sections"

A backup image instance is uniquely identified in the Oracle Secure Backup catalog by its backup UUID. Similarly, a backup section is uniquely identified in the catalog by its backup section OID.

Example 1-8 shows output from the lsbi command for a backup with the backup UUID of brhost2-20130329-123722.1.

Example 1-9 shows output from the lsbi command for the backup sections belonging to the backup image instance shown in Example 1-8.

See Also:

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

Example 1-8 Backup Image Instance

ob> lsbi brhost2-20130329-123722.1 
        Instance Name                 Created       Container(s)brhost2-20130329-123722.1         2013/03/29.05:37  VOL000001

Example 1-9 Backup Section

ob> lsbi --sections brhost2-20130329-123722.1
        Instance Name                 Created       Container(s)
brhost2-20130329-123722.1         2013/03/29.05:37  spantape-000001,                                                                spantape-000002                 BSOID  File Sect   Size     103     1    1  100.1 MB     104     1    2   24.4 MB

About Validating Backups by Computing Checksums

Oracle Secure Backup ensures integrity of backups by detecting data corruption at any point during the lifecycle of the backup. This includes database backups, file-system backups, and backups from NDMP filers.

Data corruption can occur due to hardware failures, human errors or malicious attacks, network or latency issues, storage issues, or application corruption (as part of read or write processing). While creating a backup image instance (as part of a backup, staging, or copy instance operation), Oracle Secure Backup computes and stores a checksum. To verify the integrity of a backup image instance, the media server recomputes the checksum, reads the checksum that was stored when this backup image instance was created, and then compares the recomputed checksum with the stored checksum. If the stored checksum and the recomputed checksums match, the backup image instance is valid and has no data corruption.

The process of verifying backups is referred to as backup validation. Backup validation can also be used to validate backup image instances before performing vaulting or staging. You can perform backup validation immediately after a backup is created or through an automated script that runs a validate job at specified intervals. Each validation request creates a separate validatechecksum job. Note that backup validation does not restore backups or copy them to another location.

During an upgrade of Oracle Secure Backup administrative domain, the device policies for all storage devices are set to SYSTEMDEFAULT. Unless you modify this setting explicitly after the upgrade, by default, checksum computation is performed for all backups created on tape devices and disk pools after the upgrade.

Levels for Configuring Checksum Computation of Backups

Checksum computation can be configured in one of the following ways:

• To configure checksum computation for all storage devices of a particular type, set the device policy for that type of device.

• To configure checksum computation for a specific device, enable checksum computation for that device.

When you configure checksum validation both at the device type level and for a specific storage device, the device type level setting takes precedence over the individual device policy setting.

Operations for Which Checksum Computation Can be Performed

Checksum computation is applicable for the following types of jobs:

• backup
• copyinstance
• staging

All these operations result in copying an entire backup image instance to different storage containers. Checksums are recomputed and stored for each new backup instance that is created. The checksums on the source device and that of the new backup instance must match.

For copy instance jobs, even if the source backup does not have a checksum stored, the copied backup image instance can compute and store a checksum.

Limitations of Checksum Computation

• Checksum computation cannot be performed for existing backups.

  For example, you created a backup image instance using Oracle Secure Backup 12.2. The administrative domain was subsequently upgraded to Oracle Secure Backup 18.1. Backups that were created using Oracle Secure Backup 12.2 cannot be validated because checksums were not computed at the time the backup image instance was created.

• Restarted backups and backups to NDMP filers cannot be validated.

• Only one backup image instance can be validated at a time.

• Checksum validation is not supported when the copying backup image instances from an NDMP filer to another NDMP filer.

• Checksum validation is not supported when duplicating volumes.

• Hardware-encrypted transient backup image instances are not supported when performing checksum computation as part of the validatechecksum job.

See Also:

Oracle Secure Backup Reference for information about performing backup validation

About Data Blocks and Blocking Factors

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

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

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

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

• Blocking factor specified using the obtar -b option

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

  See Also:

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

• Configuration of the tape drive to be used

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

  See Also:

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

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

  See Also:

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

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

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

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

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

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

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

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

About Media Families

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

You can associate a media family with a disk pool. However, the only attribute that is applicable to disk pools is the retention time. It is possible to use the same media family for backups to tape and disk pool. When the backup is stored on a disk pool, only the retention time specified in the media family is used.

Media Family Attributes

A media family is an attribute defining multiple characteristics that is assigned to a volume at creation time. The media family contains information including whether or not a volume is time or content managed, when or if it ever expires, rotation and duplication policies, and what the volume ID name will look like.

The media family attributes associated with a tape will be whatever attributes the media family had defined when the first volume in a particular volume set was written. Later changes made to the media family settings will not be applied to existing tapes, only to tapes that are written or recycled using this family in the future.

Every volume in a media family shares the following attributes:

• Volume identification sequence

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

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

  • Oracle Secure Backup overwrites the tape from the beginning.

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

• Volume expiration policy

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

  • Content-managed

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

    See Also:

    "Content-Managed Expiration Policies"

  • Time-managed

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

    See Also:

    "Time-Managed Expiration Policies"

  For file system backups, if no media family is designated, then the null media family is used as the default which appears with the volume id VOL. For RMAN backups, if no media family is designated, the RMAN-DEFAULT media family is used as the default.

  The media family associated with a volume is assigned to the tape during the first Oracle Secure Backup write to that tape.Volumes can be unexpired and have unused space remaining on them and not be selected for the next backup operation. Only backups from the same media family can append to a tape. Volumes that are full or closed will obviously not be written to, unless they have expired. When Oracle Secure Backup initiates a backup, it looks for the most recent volume with space available belonging to the specified media family. If none such volume is available, the first new or recyclable volume located in the library storage elements will be used for the backup.

  When a time-managed volume set expires, Oracle Secure Backup automatically considers each volume in the set eligible to be overwritten and recycled. Content-managed volume sets expire independently of other members of a volume set; they become eligible for recycling as soon as all pieces on a volume expire.

• Write window

  The write window is the period of time for which a time -managed volume set remains open for updates. Updates are other backups that can append an existing tape of the same media family that still has an open write window. The write window opens at the volume creation time for the first volume in the set and closes after the write window period has elapsed.

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

• Rotation policy

  A rotation policy defines the physical management of backup media throughout the media life cycle. This policy determines the sequence and timing during which a volume moves from it's initial, active location to a storage location and back to an active location to be reused.

  See Also:

  Vaulting for more information about rotation policies

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

See Also:

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

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

Volumes in a Media Family

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

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

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

• Media family default volume sequence file

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

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

• User-specified volume sequence file

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

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

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

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

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

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

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

• User-specified volume ID

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

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

  See Also:

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

Volume Sets and Media Families

Figure 1-9 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 instance.

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

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

Description of "Figure 1-9 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.

Volume Expiration Policies

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

Figure 1-10 Volume Expiration Policies

Description of "Figure 1-10 Volume Expiration Policies"

Content-Managed Expiration Policies

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

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

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

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

See Also:

• Oracle Secure Backup Reference to learn about the chmf command

Time-Managed Expiration Policies

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

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

• Volume creation time for the first volume in the set

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

• Write window period

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

• Retention period

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

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

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

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

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

Note:

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.

About Cloud Storage Devices

Oracle Secure Backup cloud storage devices are used to backup and restore data to and from Oracle Cloud Infrastructure Object Storage Classic and from Oracle Cloud Infrastructure Object Storage. A cloud storage device operates on a cloud storage container in the Oracle Cloud user’s identity domain. The cloud storage container acts as a repository for backup image instances.

Each cloud storage device is associated with only one cloud container. The storage class options for a cloud container are:

• Standard storage class (object) for both Oracle Cloud Infrastructure Classic and Oracle Cloud Infrastructure

• Archive storage class (archive) for both Oracle Cloud Infrastructure Classic and Oracle Cloud Infrastructure

• Infrequent access storage class (infrequentaccess) for Oracle Cloud Infrastructure

See Also:

• Oracle Secure Backup Installation and Configuration Guide for information about configuring cloud storage devices

• Oracle Cloud Infrastructure Object Storage Classic for more information about the Oracle Cloud Infrastructure Object Storage Classic

• The obtool commands "mkdev" and "lsdev" for more information about Cloud storage class options

The cloud storage device is an Oracle Secure Backup device resource. Backup jobs must be explicitly configured to use cloud storage devices. The cloud storage device can store file-system backups or RMAN backups of Oracle databases. Cloud storage devices can be accessed concurrently by multiple backup and restore jobs. The number of concurrent jobs is defined by the device’s concurrentjob setting. Each of the backup or restore job creates parallel data connections to Oracle Cloud storage. The number of parallel connections is controlled by device’s streamsperjob setting.

A cloud storage device and its associated container can belong to only one Oracle Secure Backup administrative domain. It cannot be shared between multiple Oracle Secure Backup administrative domains.

Oracle Secure Backup stores each backup image instance by splitting it into multiple segments and storing each segment as a single object in the container. The segment size defines the size of the object and is specified by the device’s segmentsize parameter.

Backup image instances remain in the cloud container until they expire, are explicitly deleted, or are migrated to a cloud archive container. Oracle Secure Backup deletes expired backup image instances only when the device’s free space threshold is exceeded; not immediately after they expire.

See Also:

• Managing Cloud Storage Devices

Oracle Secure Backup ensures that backup data is encrypted on the client before it is written to the cloud. If the backup job does not require encryption, then Oracle Secure Backup’s client-side software encryption is automatically forced on and the encryption polices set up in the client are applied to the backup data written to the cloud storage device.

You can stage backup data to a disk pool and then move it to a cloud storage device using automated staging. The backup data in the disk pool must be encrypted in order to copy it to the cloud storage device. However, a cloud storage device cannot be used as the source device for automated staging.

You can move a backup image instance from a standard storage class (object) container to an infrequent access storage class container or an archive storage class container with a manual copy job. Both containers must be located in the same identity domain. The copy between the standard object storage container and the infrequent access storage container or the archive storage container does not download the data to the client.

Oracle Secure Backup Using Multipart Upload

Oracle Secure Backup can perform secure backup and restore operations using multipart upload for efficient backup jobs.

The backup and restore jobs are run on the media server. Oracle Secure Backup uploads data in segmented chunks to a cloud storage device. In bucket, each segment is written as a single object. The segment size can be anywhere between 10MB and 1 GB. A huge backup generates a high number of objects in the bucket. Managing a large number of objects becomes harder as the number of backups grows. Some actions, such as delete instance, storage reclaim, cloud copy, and cataloging backups taking a lengthy time, may have performance issues.

With multipart uploads, backup segments are uploaded in parallel and once the entire backup is uploaded, segments are concatenated to form a single object (segment), lowering the number of objects in the bucket. This helps to improve the performance of above-mentioned operations.

See Also:

• Cloud Policies for Multipart Uploads in Oracle Cloud Infrastructure Documentation.
• segmentsize from mkdev and chdev in Oracle Secure Backup Reference.