2 Backup and Restore Concepts

Full and Incremental File System Backups

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

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

Figure 2-1 Cumulative Incremental Backups

Description of "Figure 2-1 Cumulative Incremental Backups"

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

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

Privileged and Unprivileged Backups

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

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

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

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

Catalog Data Selectors

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

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

file1.dat   file2.dat   file3.dat

file2.dat   file3.dat

file1.dat   file2.dat

file2.dat              file4.dat

Catalog View Modes

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

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

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

• Overwrite either backup image

• Manually clean up the backup catalog

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

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

File System Restore Methods

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

• Catalog-based restore operation

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

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

• Raw restore operation

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

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

• obtar restore operation

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

Backup Sets and Backup Images

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

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

Figure 2-4 Backup Sets and Backup Images

Description of "Figure 2-4 Backup Sets and Backup Images"

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

Database Backup Storage Selectors

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

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

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

Library Elements

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

• Storage Element (SE)

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

• Data Transfer Element (DTE)

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

• Medium Transport Element (MTE)

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

• Import/Export Element (IEE)

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

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

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

Library Operations

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

• Inserting and extracting volumes

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

• Loading and unloading volumes

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

• Moving volumes

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

• Importing and exporting volumes

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

Backup Image and Volume Labels

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

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

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

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

Oracle Secure Backup backup images adhere to the IEEE POSIX.1 data archiving format. Oracle Secure Backup numbers each backup image on a labeled volume set with a backup image file number, starting from 1.

As shown in Figure 2-10, when Oracle Secure Backup writes multiple backup images on a volume, it places a tape file mark after each backup image. After the last image, Oracle Secure Backup writes a tape file mark, then an end-of data (EOD) label, and then two more tape file marks.

Figure 2-10 illustrates the format of a volume that contains two backup images. This figure shows the position of the labels and tape file marks.

Figure 2-10 Two Backup Images on a Volume

Description of "Figure 2-10 Two Backup Images on a Volume"

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

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

The volume label for the second backup image could look like the one in Example 2-5.

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

After you create a backup image, Oracle Secure Backup positions the volume just before the EOD label. The EOD label contains a copy of the data in the preceding backup image label, except that the image file number is incremented by one. Oracle Secure Backup uses the EOD label to provide a volume ID, backup image file number, and sequence number for the next backup image without rewinding the volume.After you read a backup image, the volume is positioned after the tape file mark following the backup image that you just read and before the volume label of the next backup image.

Media Family Attributes

Volumes in a media family share the following attributes:

• Volume identification sequence

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

  • The tape is written to for the first time.

  • The tape is overwritten from the beginning of tape.

  The volume ID consists of a fixed portion, usually the name of a media family, followed by a sequence number assigned and updated by Oracle Secure Backup. For example, if the media family is full_backup, then a volume ID might be full_backup-000029. By default the sequence number of the first volume in the media family is 1.

• Volume expiration policy

  A media family can have either of the following mutually exclusive volume expiration policies: content-managed, which is the default, or time-managed. When a volume set is expired, Oracle Secure Backup automatically considers each volume in the set eligible to be overwritten and recycled. If the volume set is content-managed, then an individual volume of the set can expire before the remainder of the set.

  Although a volume may be unexpired and have unused tape remaining, Oracle Secure Backup will not write to a volume whose sequence number is lower than the most recent volume sequence number for the media family. Every backup tries to append to the most recent volume in the media family; if this volume is full, then it writes to a new one.

• Write window

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

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

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

Volume Expiration Policies

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

Figure 2-12 Volume Expiration Policies

Description of "Figure 2-12 Volume Expiration Policies"

Volumes in a Media Family

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

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

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

• Media family default volume sequence file

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

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

• Administrative domain default volume sequence file

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

• User-specified volume sequence file

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

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

  • The prefix 8mm or DAT to identify volumes created by different devices

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

  • An operator's initials to identify the user who performs the backup, for example, la

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

• User-specified volume ID

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

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

Service Daemon

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

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

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

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

Schedule Daemon

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

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

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

Index Daemon

The obixd daemon manages the backup catalog for each client. The index daemon runs intermittently on the administrative server.

The index daemon is started at the conclusion of any backup to import the index data generated by obtar into the backup catalog. In addition, obixd is started when the catalog must be accessed for restore or browsing operations.

Apache Web Server Daemon

The obhttpd daemon provides the Web tool for Oracle Secure Backup. This daemon runs continually on the administrative server.

The Web server daemon is signaled to start by the service daemon, which itself is normally started as part of system startup.

NDMP Daemon

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

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

Robot Daemon

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

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

Proxy Daemon

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

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

Identity Certificates and Public Key Cryptography

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

• A public key

• The identity of the host

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

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

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

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

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

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

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

Authenticated SSL Connections

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

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

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

Certification Authority

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

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

Oracle Wallet

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

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

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

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

Figure 2-15 Oracle Wallets

Description of "Figure 2-15 Oracle Wallets"

Web Server Authentication

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

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

Figure 2-16 Web Server Authentication

Description of "Figure 2-16 Web Server Authentication"

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