Staging

About Staging

Staging lets you store one or more backup image instances in a container in preparation for automatically copying or moving the backup image instances to another container.

For Oracle Secure Backup, the staging container can be a disk pool or a cloud device. In a typical staging scenario, the backup instance would be moved from a disk pool to a tape drive.

Staging can involve multiple backup image instances and can be configured to run at scheduled times and based on certain conditions. Examples of conditions include the size of a set of backup images, the client hosts in the backup, and database information.

Staging can also be done on-demand.

Benefits of Staging

Disks have much faster random access of backup files than tapes. Tapes can be moved offsite for long-term storage. Staging allows a backup to be automatically contained on both disk and tape, thus allowing both fast restores and the benefits of being on tape.
Staging allows the use of multiple streams, in parallel, during backup and restore operations. In the case of backups, the data is copied to a single tape drive at a later time.
Staging can minimize the stop-and-reposition issue that occurs when slow clients are backed up to tape because when staging is used, slow clients can be concurrently backed up to a disk pool and then copied to tape in a single high-speed data stream.
Staging allows backup instances to remain on disk after they are also written to tape. Each instance can have a different expiration time so the backup could remain on the disk to restore more quickly while also being on tape for long term protection.
Staging can be used to create additional copies of backup image instances at an offsite location using a remote Oracle Secure Backup media server to provide additional data protection through redundancy.

Staging Concepts

The following terms describe the concepts of staging:

Staging: Staging is the temporary use of a disk pool as an interim container for a backup image that is ultimately destined to be written to another container, usually tape. The backup is first written to a disk pool device in order to improve efficiency by reducing the time a physical tape drive is assigned for exclusive use by a given backup job. Backup images staged to a disk pool are scheduled for movement to tape based on either a schedule, or based on the amount of data in the disk pool device. After the backup image instance in the disk pool is copied to another container, it can optionally be deleted.
Stage source job: A stage source job (usually referred to as simply a source job) is the initial backup job that writes backup images to the stage pool. A source job can be an on-demand backup job, a backup schedule, a cpinstance job, or even another copyfromstage job that writes backup image instances to another stage disk pool device.
Copy-from-stage: Copy-from-stage refers to automatically copying backup image instances to a destination container.
copyfromstage job: A copyfromstage job is the job that copies the backup image instances created by a stage source job to a destination container.
stagescan job: A stagescan job scans and filters the backup image instances in one or more stage disk pool devices. Instances that match a stage-rule that is attached to the device are grouped and copied by a copyfromstage job created by the stagescan job. A stagescan job can create zero or more copyfromstage jobs. A stagescan job is typically launched by a stagescan schedule, but can also be launched on-demand using the obtool stagescan command.

Note:
All copyfromstage jobs have system job ID numbers, starting at 1 and increasing. Scheduled stagescan jobs also have a system job ID. In the output of the obtool lsjob command, system jobs always appear first in the job listing and so could appear at the top of a very long job listing. To view both copyfromstage jobs and stagescan jobs, specify them as job types when you issue the lsjob command. See Oracle Secure Backup Reference for information about the lsjob command.
Staged: A backup image instance is said to be staged if the instance is to be stage-copied ether immediately or at some future time.
Migrate: To migrate a backup image instance refers to doing a stage copy of a backup image instance from the source container to the destination container and, upon a successful copy, deleting the backup image instance in the source container. The term migrate, in the context of staging, is synonymous with the word move.
On-demand staging: On-demand staging refers to issuing an obtool command to create an immediate stagescan job that copies all backup images instances that match a specific stage device and a specific set of stage rules.
Source container: The staging disk pool device that contains one or more backup image instances.
Destination container: The target device to which a copyfromstage job copies backup images from the staging disk pool. The destination container can be a tape device or another disk pool.

About the Oracle Secure Backup Default Stage Rule

Stage rules control which backup images are copied, and when they are copied. They can also be used to control the minimum time a backup image is guaranteed to remain on a stage device.

Oracle Secure Backup provides a default stage rule that matches all instances. For a scheduled stagescan job, if no other stage rule in a device matches a backup image instance, then the instance is always copied by the default stage rule. The purpose of having a default stage rule is to guarantee that all instances in a stage disk pool are copied. Copying all instances ensures that if you make a configuration error, and an instance you expected to be copied is not copied, then backup image instances that expire in the source disk pool are not permanently lost.

A "match" to a stage rule means that an instance matches the media family name and one or more places (database ID, database name, or file-system host name). If the stage rule restriction list contains a cloud device, then the instance also must be encrypted to match the rule. If those conditions match, then the default stage rule is not invoked for the instance. In the following situations it is possible that even in the case of a match, an instance still might not be copied:

There is a stagescan schedule listed in the stage rule that does not match the current stagescan schedule that invoked the stagescan job. The instance is copied by that rule later when the other schedule runs.
The value of a matching stage rule's minimum age filter, or minimum copy size filter, could be set to values so large that an instance is never copied. The instance will then never be deleted even if the instance expiration time is exceeded. Caution should always be used when setting values for those filters.

The device in the restriction list of the default stage rule should be considered an “error” device so that any instances copied there by the default stage rule are considered mistakes. These mistakes can then be corrected by adding additional stage rules that match these backup image instances stored in the source disk pool device.

Note:

A stage-enabled Oracle Secure Backup Cloud Storage Device does not support the default stage rule. A backup instance that is stored within the stage-enabled Oracle Secure Backup Cloud Storage Device and not picked up by the stage rule may be purged when it expires. Such an instance may be deleted if it has not been staged. To ensure that all backup instances are staged, you can add a "catch all " stage rule at the end of the device's list of staging rules.

Stage Loops

Oracle Secure Backup prevents a copyfromstage job from using the same disk pool as both the source and destination. However, when more than a single pool has staging enabled, it is possible for instances to be copied back to the original pool if a stage loop occurs. For example, the following situations result in stage loops:

A stagescan schedule in a copyfromstage job copies an instance from source disk pool A to destination disk pool B which also has staging enabled. Later, another stagescan schedule creates a copyfromstage job that copies the new instance in the destination pool B back to the original source disk pool A.
An instance is copied from pool A to pool B, then from pool B to pool C, and then from pool C back to the original pool A.

Stage loops must be prevented because they could easily result in the same instance being replicated many times until a disk pool runs out of space.

To prevent stage loops, Oracle Secure Backup does the following when a stage rule is added to a device or a change is made to a stage rule restriction list:

Scans the stage rule list on the source device and assumes that the instance might be copied to any disk pool that is in each stage rule restriction list.
Scans the restriction list for each stage rule in each of the potential destination disk pool devices and assumes that the instance might be copied to any of these disk pools.

If any of these disk pools are the original disk pool, or any other disk pool that has already been assumed as a destination for the instance, then the configuration command fails, and an error message is displayed. For example:

ob> chstage --restrict pool1 srule2
Error: stage loop - pool1 -> srule2:pool0 -> srule1:pool1
Error: restriction list not changed
ob>

Limitations of Stage Loop Detection

There is no check to see if the instance matches any stage rule, or even if staging is enabled in the disk pools. Creating a stage loop by changing a stage rule restriction list is prohibited.
Oracle Secure Backup usually only searches four disk pools deep to detect stage loops. If there are many disk pools and stage rules, then the search can potentially time out after 10 seconds. Oracle Secure Backup is always guaranteed to search two disk pool levels deep, regardless of how long it takes, so the case shown in the previous example will always be detected.
If a disk pool has any stage rules with a disk pool device in the stage rules restriction list, then the disk pool device cannot be added to the restriction list of the default stage rule because this would cause a stage loop.
Stage rules with a disk pool in the restriction list cannot be added to a disk pool device that is already in the restriction list of the default stage rule.

Setting Up Staging

The following are some concepts and guidelines to be aware of when you set up staging.

When staging is used, it is assumed that all backup image instances copied into a stage disk pool device will be copied elsewhere. This assumption prevents incorrect configurations in which an instance is expected to be copied but is not, and then the instance expires and is deleted, leaving no backup to restore. To prevent this, an instance in a staging disk pool is never automatically deleted until it has been copied, even if the instance has expired. (However, if desired, you can explicitly delete the instance using the rminstance command.)

Do not use the default stage rule to intentionally cause backup image instances to be copied. Instead, use it with an "error" disk pool as the target device to so that instances that don't match any other stage rule can be identified when they appear in the error disk pool.

The default stage rule can be used to copy instances in a staging design, but be aware that doing so can make it harder to detect that instances are not going where expected because the default rule always copies anything that does not match any rule. Therefore, if you expect a rule to lead to an instance being copied, but the instance does not match the rule, then that instance gets mixed in with everything else that is copied by the default stage rule.
Use the minimum number of stage rules necessary so that stagescan jobs run as fast as possible.
To avoid having too many instances in a copyfromstage job, do not use an existing disk pool as a staging device when you first upgrade to use staging. You can ignore this guideline if the existing disk pool has relatively few instances in it.
Do not leave the restriction list in a stage rule empty. Explicitly list the destinations device(s).

There are many ways to set up staging. The following describes one example.

To set up staging:

Use the mkdev command to create a target disk pool device.

ob> mkdev --type disk --initialize --attach somehost:/somepath/pooltarget pooltarget

Use the mksched command to create two stagescan schedules.

ob> mksched --type stagescan --day daily --time 6:00 scheda
ob> mksched --type stagescan --day daily --time 12:00 schedb

Create three stage rules. The --dbid, --dbname, and --fshost options are not specified in these examples, so they all default to the asterisk (*) wildcard character.
```
mkstage --schedule scheda --matchfamily mfa  --targetfamily mftarget --restrict pooltarget rulea
mkstage --schedule schedb --matchfamily mfb  --targetfamily mftarget --restrict pooltarget ruleb
mkstage --matchfamily mfc  --targetfamily mftarget --restrict pooltarget rulec
```
The first stage rule, rulea, matches media family mfa and uses schedule scheda.

The second stage rule, ruleb, matches media family mfb and uses schedule schedb.

The first stage rule, rulec, matches media family mfc and has no schedule.
Set the default state rule target media family and restrictions.

Staging cannot be enabled on any stage disk pool device using the --staging yes, until after the target media family and the restriction list are set in the default stage rule. This only needs to be done one time. (The following example assumes there is a tape device named vt1.)
```
ob> chstage --targetfamily mftarget --restrict vt1 OSB-DEFAULT-STAGE-RULE
```
Create a staging disk pool device.
```
ob> mkdev --type disk --initialize --stagerule rulea,ruleb,rulec --staging yes
 --attach somehost:/somepath/poolstage poolstage
```
When schedule scheda is triggered, instances that match stage rule stagea (that is, instances that are backed up using media family mfa) will be copied to disk pool poolstage using media family mftarget. Instances that match stage rule rulec (that is, instances backed up using media family mfc) will be copied. Because rulec has no schedule, it will match all schedules.

When schedule schedb is triggered, instances that match stage rule stageb (that is, instances that are backed up using media family mfb) will be copied to disk pool poolstage using media family mftarget. Instances that match stage rule rulec (that is, instances backed up using media family mfc) will be copied.