On Demand Data Protection Operations

Topics | How To | Support | Related Topics


Overview

Defining Content for On Demand Data Protection Operations

How to Run an On Demand Data Protection Operation

Best Practices

General Information


Overview

On Demand Data Protection Operations allow content to be specified as an external input at the time of initiating a data protection operation. Whereas traditional backups/archive operations are performed on subclients, which have fixed content configured prior to performing the operation, On Demand Data Protection Operations allow you the flexibility of specifying content each time you perform a backup or archive operation. Although the concept is the same, the implementation differs somewhat based on the type of agent, as described below.


Defining Content for On Demand Data Protection Operations

Content for On Demand Data Protection operations is defined by the user in the form of text files called the Content File. In addition, some iDataAgents utilize a Directive File to list the location of the Content File(s). It is important that you understand the purpose of each of these files, and what they contain in order to successfully utilize the On Demand Data Protection feature. Details on these files are provided below.

Content File

The Content File is a text file that you create for the purpose of telling the system where the data is located that you want protected on demand. Each Content File contains the fully qualified paths from the root directory to files, links and/or devices to be backed up/archived. For example:

Sample Content File on Windows Sample Content File on Unix/Macintosh Sample Content File for NAS File Server
c:\data\datafile.txt
c:\data\wordfile.doc
d:\my documents\webdoc.html

UNC Path
\\client1\shares\ondemand_content\test1.txt
\\client1\shares\ondemand_content\test2.txt
\\client1\shares\ondemand_content\test3.txt

/usr/datafile
/usr/textfile
/etc/docfile
NetApp
/vol/vol0/Dir1
/vol/vol0/Dir2
/vol/vol1/Dir1

Celerra
/fs1/Dir1
/fs1/Dir2
/fs1/Dir3

You are allowed to use multiple Content Files for an On Demand Data Protection operation, provided that they are listed in the Directive File. For NAS iDataAgents and the File Archiver for Windows Agent, which do not use a Directive File, only one Content File is used.

Content File Location

For NAS iDataAgents, the Content File must be placed on the CommServe or the MediaAgent; in all other cases, the Content File must be placed on the client.

Creating the Content File

To create the Content File, set up a text file that contains the fully qualified path(s) from the root directory to the data you want backed up/archived. These paths can include files as well as entire directories. If you include directories, the system will automatically expand all subdirectories within the specified directory and back up/archive all the data within them as well. For certain agents, the OnDemand_AutoExpandDir registry key is available to turn off the automatic expansion of nested directories if you prefer to literally specify every directory whose contents are to be backed up/archived. In addition, links and devices can be specified; however, special care should be taken when utilizing On Demand Data Protection for links and devices.

NOTES

Adding Files and Folders with Unicode Characters

If the path or the filename contains Unicode characters, the Content File must be converted to a format that can be used by the data protection operation. This can be done using the cvconvertunicode utility. For a detailed explanation on how to use this tool, see Unicode Conversion Utility.

Directive File

The Directive File is a text file that you create on the client for the purpose of the telling the system where the Content Files are located in order to perform an On Demand Data Protection operation. (A Directive File is not required for the NAS iDataAgents or File Archiver for Windows Agent.) The Directive File contains the fully qualified paths from the root directory to one or more Content Files. For example:

Sample Directive File on Windows Sample Directive File on Unix/Macintosh Sample Directive File on SharePoint
c:\temp\ContentFile1.txt
c:\temp\ContentFile2.txt
d:\ContentFile3.txt
/usr/ContentFile1
/usr/ContentFile2
/etc/ContentFile3
http://med/sites/itdeveloper
http://med/sites/newproduct
 

Keep in mind that each On Demand Data Protection operation requires exactly one Directive File. That is, the system will only let you enter one Directive File for the operation.

Creating the Directive File

First create the Content File(s). Then create the Directive File by setting up a text file on the client computer containing the fully qualified paths from the root directory to the Contents File(s).

NOTES


How to Run an On Demand Data Protection Operation

The following section provides the steps for using On Demand Data Protection Operations:

  1. Create a New On Demand Backup Set/Archive Set.
  2. Create the Content File.
  3. Create the Directive File if your iDataAgent requires one.
  4. Run an On Demand Data Protection Operation.

Best Practices

Consider the following when using On Demand Data Protection operations:


General Information

This section contains information of a general nature regarding On Demand Data Protection Operations.

On Demand Backup Sets/Archive Sets

The On Demand Backup Set and On Demand Archive Set are logical entities that allow data to be protected on demand, with content specified at the point of the operation. The primary difference between an On Demand Backup Set/Archive Set and a traditional backup set/archive set, is that data protection operations for the subclient associated with an On Demand Backup Set/Archive Set only support On Demand Data Protection operations. Other points to keep in mind are as follows:

Default Subclients for On Demand Backup Sets/Archive Sets

An On Demand Backup Set and On Demand Archive Set contain a default subclient that functions differently from ordinary default subclients of other backup set/archive set types (i.e., default and user-defined). These differences are listed below.

On Demand Data Protection Operations for Oracle iDataAgent

You can perform on demand data protection operations for Oracle iDataAgent, by creating On Demand Instances.

On Demand Instance is a logical entity that allows Oracle data to be protected on demand, with content specified in an RMAN script that is run through the Command Line Interface. The primary difference between an On Demand Instance and a traditional Instance, is that data protection operations for the subclient associated with an On Demand Instance only supports On Demand Data Protection operations.

Review the following before creating On Demand Instances:

Default Subclients for On Demand Instances

An On Demand Instance contains a default subclient that functions differently from ordinary default subclients of other instances. These differences are listed below.

See Running RMAN Scripts using the Command Line Interface for information on the RMAN parameters supported by the On Demand Instance.

Oracle On Demand Operations can also be executed from the Command Line Interface using Save as Scripts. For more information, see Command Line Interface.

Restoring/Recovering Data from On Demand Data Protection Operations

Data from On Demand Data Protection operations can be restored/recovered through ordinary operations as well as a Restore by Jobs operation. See Restore Backup Data, Recover Migrated Data, or Restore By Jobs for the respective overview.

Command Line Interface

The Command Line Interface supports the capability to create, rename, delete or back up an On Demand Backup Set, as well as back up an On Demand Instance. See Command Line Interface for an overview.

Oracle On Demand Operations can also be executed using save as scripts. To do this, you will need to save a regular Oracle backup or restore operation as a script (XML) file, and then include the path to the RMAN script in the XML file.

Example:

<scriptItem>/database/oracle10g2/onejob/rman_restore.txt</scriptItem>

For step-by-step instructions on saving the job as a script file, see Save a Job as a Script.

The saved XML file can later be executed from the Command Line Interface using qoperation execute command. For step-by-step instructions on executing the save as scripts, see Execute Scripts using qoperation execute Command.


Back to Top