This chapter introduces concepts related to backup and recovery using Oracle Secure Backup.
This chapter contains these sections:
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:
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.
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
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
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
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
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:
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:
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.
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.
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.
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
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.
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
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
"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.
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.
Oracle Secure Backup Installation and Configuration Guide for details on the contents of the files and directories in the Oracle Secure Backup home
Oracle Secure Backup supports importing and cataloging backups from tape using the
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.
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.
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.
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.
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.
Do not confuse policy classes, which are only an organizational convenience, with user 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.
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.
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 backup containers are automatically detected during device discovery. They also control when tape device write warnings are generated.
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.
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 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.
This class contains one policy which specifies the IP address of an Windows Internet Name Service (WINS) Server for the administrative domain.
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.
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 Oracle Secure Backup scheduler. For example, you can specify a frequency at which the scheduler attempts to dispatch backup jobs.
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.
These policies control aspects of stagescan jobs.
These policies control media management, which includes the rotation of tapes from one location to another as part of a data protection strategy.
Oracle Secure Backup Reference for more information about Oracle Secure Backup policies
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.
This section describes file-system backup and restore jobs. To learn about database backup and restore jobs, see "How RMAN Accesses Oracle Secure Backup".
About Defaults and Policies for a description of scheduler policies.
Figure 1-2 Backup and Restore Requests and Jobs
The steps in the process illustrated in Figure 1-2 are as follows:
A user creates a file-system backup or restore request. For example, the user submits a request for a backup of the
/home directory of client host brhost2.
Oracle Secure Backup maintains a queue of backup and restore requests in the user's Oracle Secure Backup Web tool or
obtool session. The user can review or modify this queue. When the user terminates the session, requests that are not yet sent to the scheduler are lost.
If necessary, the user modifies the requests in the queue. For example, the user can delete a job request.
The user sends the backup request to the scheduler (
obscheduled) running on the administrative server.
When a user sends a file-system backup or restore request to the Oracle Secure Backup scheduler, the request becomes a job. Oracle Secure Backup assigns each job a name that is unique among all jobs in the administrative domain.
At the scheduled time, the service daemon runs the job.
Oracle Secure Backup inspects each trigger defined in each backup schedule every five minutes by default. For each trigger that fires that day, Oracle Secure Backup creates one job for each dataset listed in the schedule.
You can change the frequency with which the scheduler inspects triggers by specifying a different value for the scheduler
In job descriptions, Oracle Secure Backup identifies this as a dataset job. It assigns the scheduled dataset job a numeric job identifier such as
Each time you create an on-demand request and then click Go or use the
backup --go command in
obtool to send your request to the scheduler, Oracle Secure Backup creates a dataset job. It assigns the job an identifier prefixed by the user who runs the command, for example,
In job descriptions, Oracle Secure Backup calls this a backup job. Oracle Secure Backup assigns each backup job an identifier whose prefix is the parent (dataset) job id, followed by a dot (
.), then followed by a unique small number. For example,
15.1 could be a subordinate job for scheduled job
Each time you explicitly request that Oracle Secure Backup restore data and then click Go or use the
restore --go command in
obtool to send your request to the scheduler, Oracle Secure Backup creates a restore job for each backup image instance that must be read to initiate the restore operation. Oracle Secure Backup assigns each job an identifier such as
If Oracle Secure Backup creates multiple jobs to satisfy one restore request, then it marks each job except the first as dependent on the success of the previous job. The effect of this notation is that, given the failure of a job on which a later job is dependent, that later job is also marked as failed.
After the earliest time to run a job has arrived, the 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.
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
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.
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
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.
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.
On the Windows operating system, only the service daemon is a Windows service. The other Oracle Secure Backup daemons are not Windows services.
This section contains these topics:
An Oracle Secure Backup administrative domain uses a variety of daemons to perform backup, restore, and configuration tasks. The daemon programs are located in the etc subdirectory of the Oracle Secure Backup home on Linux or UNIX, and in the bin directory on Windows. This section describes the Oracle Secure Backup daemons.
Table 1-1 lists the Oracle Secure Backup daemons and shows on which hosts they run.
Table 1-1 Oracle Secure Backup Daemons by Host Type
|Daemon||Administrative Server||Media Server||Client|
Apache Web Server
This section contains these topics:
On the administrative server,
observiced runs jobs at the request of the schedule daemon, cleans up log files and transcripts, and provides access to Oracle Secure Backup configuration data to other hosts in the domain.
observiced also serves as the Certification Authority (CA), accepting certificate signing requests from hosts within the administrative domain and sending signed certificates back to the requesting host.
observiced starts the schedule daemon and the Apache Web server during initialization.
When running on a media server or client,
observiced handles membership in a administrative domain, allows for remote administration of the host, and handles certificate operations. The identity certificate of the requesting host is used to verify that it is permitted to invoke the operation.
On all hosts, the service daemon is usually started as part of system startup. On UNIX and Linux, startup is usually performed through entries in
/etc/init.d, whereas on Windows systems the service is started by the Service Control Manager.
obscheduled daemon is the Oracle Secure Backup scheduler. The schedule daemon runs continually on the administrative server.
The schedule daemon manages each scheduled backup, retains a list of every available 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.
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.
obndmpd daemon implements the NDMP tape service and provides data communication between the media server and client. This daemon runs on both the client and media server. It passes control of the data connection to a sub-process so it can remain free to respond to control messages sent by
Two instances of
obndmpd run during an active backup or restore operation. If the same host is acting as both the media server and the client, then three instances of
obndmpd are running: one acting as controller, one acting as the data service, and one acting as the mover.
When an Oracle Secure Backup component such as
obtar must interact with a tape library, it asks
observiced on the media server to start an instance of
obrobotd. The robot daemon then fields all requests for inventory manipulations, the movement of media in the tape library, and so on. Each invocation of
obrobotd manages a single tape library.
obrobotd exits when all users of a tape library have closed their connections.
obpoolmgr daemon manages the contents of disk pools. It runs continuously on the administrative server.
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.
obproxyd daemon verifies user access for SBT backup and restore operations. The proxy daemon runs on the host that contains the SBT library accessed during the operations. The invocation of the proxy daemon is platform-specific.
The proxy daemon uses the operating system user identity of the process invoking the SBT library and the local host name to determine the Oracle Secure Backup account to use for the backup operation. If a preauthorization exists for this operating system user and host, then the associated Oracle Secure Backup user is permitted to perform RMAN backups and the login to Oracle Secure Backup is permitted.
Figure 1-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
observiced daemons run on all hosts, the
observiced daemon on the administrative server has invoked the
obhttpd daemons, and a client file-system backup job has been created and scheduled to run. The Oracle Secure Backup daemons interact with
obtar as follows:
On the administrative server,
obscheduled sends a request to
observiced to run the backup job.
observiced on the administrative server sends a request to
obrobotd on the media server to mount each volume required for the backup job.
observiced on the administrative server sends a request to
observiced on the media server to invoke
obtar on the media server establishes a data connection between the
obndmpd daemon on the client and the
obndmpd daemon on the media server. Backup data is transmitted over the data connection and written to 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.
obtar sends catalog information to
obixd on the administrative server and then terminates.
On the administrative server,
observiced sends a job status update to
When a backup operation is started, Oracle Secure Backup creates the following:
A backup image stores basic information about the backup that is not specific to the backup container in which the backup data is stored.
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.
You can create additional backup image instances, on different backup containers, if required.
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.
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
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.
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.
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
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.
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:
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:
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.
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.
Cloud storage devices
Cloud storage devices store data in Oracle Cloud Infrastructure Object Storage Classic and Oracle Cloud Infrastructure Archive Storage Classic. 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.
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.
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.
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.
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
label and backup image instance-related information is displayed with the header
label. These are actually different parts of a single label.
For volumes generated by the Oracle Secure Backup scheduling system, you might see entries such as media family and volume expiration.
Oracle Secure Backup 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
Backup image instances, volume labels, and the special
Volume labels share a common format and include both volume and backup image data. The volume label serves a dual role, being both the label for the volume and the label of the first backup image 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.
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 ...
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
VOL00007 have already been written to with other backups, then the second tape in
VOL00005's volume set will be
When Oracle Secure Backup reads and writes multiple volumes, it keeps track of the proper order of volumes within the volume set with the following data:
If a backup image 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.
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
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
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.
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.
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.
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.
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
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
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
In a typical format, a tape drive writes data to a tape in blocks. The tape drive writes each block in a single operation, leaving gaps between the blocks. The tape runs continuously during the write operation.
The block size of a block of data is just the size of the block in bytes as it was written to tape. All blocks read or written during a given backup or restore operation have the same block size. The blocking factor of a block of data expresses the number of 512-byte records that are contained in that block. So, for example, the Oracle Secure Backup default blocking factor (128) results in a tape block size of 128*512 bytes or 64KB.
The maximum blocking factor is an upper limit on the blocking factor that Oracle Secure Backup uses. This limit comes into play particularly during restores, when Oracle Secure Backup must pick an initial block size to use without knowing the actual block size on the tape. The maximum blocking factor limits this initial block size to a value that is acceptable to both the tape device and the underlying operating system.
When Oracle Secure Backup starts a backup, it decides what block size to use based on several factors. Listed in order of precedence, these factors are:
Blocking factor specified using the
This option can also be specified as part of the
operations/backupoptions policy. If this option is specified, then it overrides all other factors.
Configuration of the tape drive to be used
You can specify what blocking factor, maximum blocking factor, or both that Oracle Secure Backup should use for a particular tape drive when you configure that drive. You might want to do this if you have tape drives with very different block size limits.
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/maxblockingfactor policies set.
The default blocking factor (128) and maximum blocking factor (128), resulting in a block size of 64 KB
When a blocking factor has been nominated by one or another of these factors, it must pass the following tests:
The block size must be less than or equal to the maximum block size (blocking factor) in effect from applying whatever policies or tape drive configuration attributes are in force.
The block size must be supported by the tape drive and attach point in question.
Sometimes a tape drive, device driver, or kernel operating system has a limitation that supersedes all other considerations.
When Oracle Secure Backup begins a restore operation, it does not know what block size was used to write a given tape. Because issuing a read for a too-small block would result in an error condition and a required tape reposition, Oracle Secure Backup always starts a restore operation by reading the largest possible block size. This is either the current setting of the
media/maxblockingfactor policy or the tape drive configuration attribute. The maximum blocking factor, therefore, must always be greater than or equal to the largest block size you ever want to restore.
After the first read from the backup image 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.
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.
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:
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.
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:
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.
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.
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.
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.
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.
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.
When you create a media family, you specify how to generate volume IDs that become part of the volume label.
When Oracle Secure Backup labels a tape volume, it assigns it a volume ID based upon the contents of a volume sequence file. This file resides on the administrative server. Its location is defined by the media family of the volume. The volume sequence file is usually located in the
admin/state/general subdirectory of the Oracle Secure Backup home.
When you define a media family, you direct Oracle Secure Backup how to assign a volume ID. You can direct Oracle Secure Backup in the following ways:
In most cases, you should use this file. Volume sequence files for each media family are located in the
family_name directory. For example, if you define a media family with the name
new_data, then files are located in the
Oracle Secure Backup constructs each volume ID by starting with the media family name, appending a dash, then appending a 6-digit sequence number, the first of which is
000001. For example, if you define a media family called
new_data, then Oracle Secure Backup creates a volume sequence file on the administrative server called
.vid.new_data. The first volume ID in this file is
new_data000001. Each time Oracle Secure Backup assigns an ID to a volume, it increments by one. That is, the next volume ID that Oracle Secure Backup assigns is
new_data000002 and so on.
Oracle Secure Backup creates a default volume sequence file during installation. It resides in the
admin/state/general subdirectory on the administrative server. The first volume ID in this file is
VOL000001. Each time Oracle Secure Backup assigns an ID to a volume, it increments it by one. That is, the next volume ID that Oracle Secure Backup assigns is VOL000002, and so on.
If you specify your own volume sequence file, then Oracle Secure Backup ignores the default volume sequence file and instead uses your file for obtaining volume IDs. You can enter a full path name to specify where this file should be created later. Oracle Secure Backup does not create this file automatically. You must do so manually. You can use a text editor to customize the volume ID prefix.
Each volume ID file can contain a single volume ID. The maximum length of the volume ID is 31 characters. You can use the first few characters to help classify your volumes. For example, you could create volume IDs that begin with:
8mm to identify volumes created by one tape device and
DAT to identify volumes created by a different tape device
The initials of the operator who performs the backup, for example,
If you do not include any digits in the sequence number you create, then Oracle Secure Backup appends a 1 to the sequence number and increments that number by 1 each time the sequence number is used.
You can use the
--vidunique option on the
mkmf command to specify an explicit volume ID. For example, you can create your own volume ID if you previously created a tape that is partially unreadable. You can perform the backup again and use the
--vidunique option, specifying a volume ID that keeps your volume IDs in sequence.
You can also use the
--vid option on the
restore command to ensure that the volume being read is the correct one.
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
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 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
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
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.
Oracle Secure Backup Reference to learn about the
Volumes in a time-managed media family expire when they reach their volume expiration time. At this point Oracle Secure Backup automatically considers each volume in the volume set eligible to be overwritten.
As shown in Figure 1-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.
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.
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.
Oracle Secure Backup cloud storage devices are used to backup and restore data to and from Oracle Cloud Infrastructure Object Storage Classic. 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 for a cloud container can be either the standard storage class (object) or archive storage class (archive).
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 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
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
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.
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 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 archive storage container does not download the data to a client.