A.0 XML Elements and Attributes for ArkConfig

<arkConfig>

(Root element)

<basic>

A single Basic tag set surrounds the management information that applies to all jobs. Its child elements specify where to display the log, the authentication information, and the storage location where the archive data (versions) reside.

At a minimum, configure the <authentication> information for ArkManager 2.1 to run.

For information about its child elements, see <basic> in the Parent Element column of this table.

<job>

A Job tag set surrounds the child elements that define the settings for a given job. Create one job for each unique information set that you want to version. An archive server can version a given source volume with only one job. If you want to create multiple jobs for a source volume, you must create the jobs on different archive servers.

The values configured in a given job override the default settings only for that job. If a value is not set in the Job element, the default settings apply for only that element.

Use the attributes optionally to indicate whether the job is to be added, modified, or deleted from the archive server.

For information about its child elements, see <job> in the Parent Element column of this table.

<authentication>

Contains child elements that provide information about the administrator user. This user must have rights to all servers being accessed by this archive server. Child elements also define the ArkSQL database user, password, and port number. The ArkSQL user needs server-specific ArkSQL rights.

The <authentication> information must be set before ArkManager can run.

For information about its child elements, see <authentication> in the Parent Element column of this table.

<defaults>

(Child to <arkConfig>)

<fullCopy/>

For information about these child elements, see the Job element (<job>) in this table.

The Defaults element can contain any tags that you use in a Job element, except for <name>, <volume>, and <stopped/>.

Although you can have multiple Job elements, only a single Defaults element appears in the arkConfig.xml file.

<source>

<deletePolicy>

<fullCopy/>

(Optional) If used, sets a flag so that the job copies all files that pass the filter from the source volume to the archive database the first time the job runs or if a full copy runs but did not finish previously.

In any given Job element or Defaults element, use <fullCopy/> or use <noFullCopy/>, not both. If neither one is specified, <fullCopy/> is the default software setting.

This is an empty element; it has no child elements and no data values.

<source>

Contains child elements that define the specific server context, server, paths, directories, or file types to be archived for this job.

For information about its child elements, see <source> in the Parent Element column of this table.

<job>

(cont’d)

<deletePolicy>

Contains child elements that specify when to delete a version, such as by age of the version (elapsed time of creation), by the number of versions that exist (oldest deleted first), or by the interval of time before the next versioning process.

For information about its child elements, see <deletePolicy> in the Parent Element column of this table.

<authentication>

(Child to <basic>)

<eDirectory>

Contains child elements that specify the Novell eDirectory™ authentication information, including the administrator user, the password, and the eDirectory tree where the administrator user, archive server, and source servers reside.

For information about its child elements, see <eDirectory> in the Parent Element column of this table.

<eDirectory> 

(Child to <authentication>)

<user>

Specifies the Novell eDirectory Common Name of the administrator user who has the appropriate rights to the original data location and to the archive server’s data location. For example:

<user>admin.server_context</user>

<tree>

Specifies the tree where the administrator user, archive server, and source servers exist. For example:

<tree>site1_tree_name</tree>

<tree>eur_tree</tree>

<password>

The password of the ArkSQL database administrator. For example:

<password>arksql_password
</password>

The first time that you run arkManager, the arkConfig.xml file must contain a <password> element with the correct password for the MySQL root user. If arkManager finds a <password> element, it reads the password, encrypts it, then stores the encrypted password in a local store. It removes the password from the arkConfig.xml file, then saves the file.

The <password> element is not necessary unless you need to change the saved password. ArkManager refers to the encrypted password whenever you use the arkStart command, which also starts ArkSQL. If you change the root user’s password for MySQL, you must also change the database password that arkManager uses when it starts. ArkManager cannot restart until you pass it the updated password in the arkConfig.xml file.

If you need to change the password, stop ArkManager (arkstop) and ArkSQL , add a database <password> element to the arkConfig.xml file with the new password, then start (arkstart) the ArkManager.

<source>

(Child to <defaults> and to <job>)

<snapshotPool>

Specifies the name of the destination pool where a snapshot of the source volume is created temporarily at the beginning of each versioning. For example:

<snapshotPool>pool_name
</snapshotPool>

Snapshots make it possible to save point-in-time versions of all eligible source files, even if a file is open at the time. Eligible files are those files that exist at the end of the epoch, changed during the epoch, and met the filter requirements.

By default, if no snapshot pool is specified, ArkManager copies the eligible source files directly from the source volume. Exclusively open files cannot be versioned and data might be inconsistent.

If the specified snapshot pool is inactive or otherwise not available when a versioning job begins, the job copies the files directly from the source volume.

<server>

Specifies the unique name of the server in the specified context where the original data is stored. For example, to specify a server named srv1:

<server>srv1</server>

Use the <server> tag as a child only of the Job element; it is invalid in the Defaults element.

<filter>

<filter overrideDefaults="false">

<filter overrideDefaults="true">

(Optional) Contains child elements and attributes that specify the criteria for filtering data so that only selected data is versioned.

Use the attributes optionally to indicate whether the filter is to be used in combination with filters set in the Defaults element (false) or if the filter is to be used in place of the filters set in the Defaults element (true).

For information about its child elements, see <filter> in the Parent Element column of this table.

<exclude>

(Optional) Contains child elements that specify traits of data you want to exclude in the job.

For information about its child elements, see <exclude> in the Parent Element column of this table.

<extension>

(Optional) Specifies the extension of files in the specified volume that you want to include in the versioning process. Use the preceding dot followed by the characters of the file extension.

Repeat this element for each file extension type that you want to version.

For example, to specify that you want to version only files with no extension (.) and files with .xxx and .yyy extensions:

<include>
  <extension>.</extension> 
     <!-- No extension -->
  <extension>.xxx</extension>
  <extension>.yyy</extension>
</include>

<include> 

(cont’d)

<wildcard> 

(Optional) Functions like a wildcard in directory searches. Replace characters with an asterisk (*) to search for files that match. For example, to include files that start with d of type .sxi:

<include>
  <wildcard>d*sxi</wildcard>
</include>

<extension>

(Optional) Specifies the extension of files in the specified volume that you want to exclude from the versioning process. Use the preceding dot followed by the characters of the file extension.

Repeat this element for each file extension type that you do not want to version.

For example, to specify that you want to exclude .zzz files from versioning:

<exclude>
  <extension>.zzz</extension>
</exclude>

<wildcard>

(Optional) Functions like a wildcard in directory searches. Replace characters with an asterisk (*) to search for files that match. For example, to exclude files that start with d of type .tmp:

<exclude>
  <wildcard>d*tmp</wildcard>
</exclude>

<interval>

<interval unit="seconds">

<interval unit="minutes">

<interval unit="hours">

<interval unit="days">

(Conditional) Specifies the elapsed time between scheduled versions in seconds, minutes, hours, or days.

You must use one of the attributes in the Interval tag to specify the units of the integer value you specify as the interval of time to wait between when the versioning begins. For example, to specify an interval of 30 minutes:

<interval unit="minutes">30
</interval>

You must specify a non-zero value for the interval or the job cannot start. If no interval value is set, 0 (zero) is the default setting.

If no interval unit is set, seconds are the default unit setting.

Use either the Time element or Interval element, but not both in the same Job element.

<daily>

Contains child elements that specify the days of the week that the job is scheduled to run. You must specify at least one day or the job cannot start.

For information about its child elements, see <daily>in the Parent Element column of this table.

<minute>

Specifies the minutes of the hour in the day that the job is scheduled to begin. A valid minutes entry is an integer value ranging from 0 to 59. For example, to set the minutes after the hour to 45 minutes:

<minute>45</minute>

If no minute value is set, zero (00) is the default minute setting.

<deletePolicy>

(Child to <defaults> and to <job>)

<maxKeepTime>

<maxKeepTime unit="seconds">

<maxKeepTime unit="minutes">

<maxKeepTime unit="hours">

<maxKeepTime unit="days">

<maxKeepTime keepCurrentCopy=
"true">

<maxKeepTime keepCurrentCopy=
"false">

Use one of the unit attribute values in the <maxKeepTime> tag to specify the units of the integer value you specify as maximum lifetime of a version.

If no maxKeepTime value is set, file versions are retained indefinitely.

If a value is specified without a unit attribute, “seconds” is the default unit of the value specified.

Use the keepCurrentCopy attribute to designate that at least one file version of current files remains in the database, even if the maxKeepTime elapses.

If keepCurrentCopy is set to True (default), the archive keeps an existing file version as long as its source file is current on the source volume, beyond the maxKeepTime. After the user deletes the current source file, the deletion is noted at the next scheduled epoch. If the file version’s age is within the maxKeepTime, the archive database retains a copy of the file version until its maxKeepTime elapses. When the file version’s age exceeds the maxKeepTime, the archive deletes the file version at the next scheduled delete time.

If keepCurrentCopy is set to False, the archive deletes a file version when it exceeds the maxKeepTime, even if the file version is the only one in the archive database for a given source file, and whether the source file is current or deleted.

The keepCurrentCopy attribute is optional. If the keepCurrentCopy attribute is not otherwise specified, the default value is True.

For example, to keep versions for 90 days before purging, to keep at least the most current version, and to schedule the purging of versions with 1-hour intervals:

<deletePolicy>

  <maxKeepTime unit="days"
    keepCurrentCopy="true">90
  </maxKeepTime>

  <interval unit="hours">1
  </interval>

</deletePolicy>

<interval>

<interval unit="seconds">

<interval unit="minutes">

<interval unit="hours">

<interval unit="days">

The interval represents the amount of time to wait from the time a Delete process ends until another Delete process begins. If a value is not specified, 24 hours is the default delete policy interval. The time involved in deleting file versions varies with the amount and complexity of data stored in the archive server. The Delete Schedule operates separately from the Version Schedule.

For example, suppose you set the Delete Schedule to 2 days. When you activate the job, the Delete process begins. When it is done, it sets an interval timer. After two days elapse, the Delete process runs. The timer is inactive while the process runs. When the delete process ends, the interval timer begins again. The process repeats until the job is deactivated.

For example, to keep up to 100 versions of each file before purging and to schedule the purging of versions with a 2-hour interval:

<deletePolicy>

  <maxKeepVersions>100
  </maxKeepVersions>

  <interval unit="hours">2
  </interval>

</deletePolicy>

If an attribute is not specified for the <interval> tag, "seconds" is the default unit of the value specified.

If the <interval> element is not specified in either the Defaults element or the Job element, the default interval is 24 hours.