3.4 Understanding Job Properties

Job properties are the set of parameters used for individual job settings and default job settings. Individual job settings apply only to a single job. Default job settings can apply, in whole or in part, to any individual job defined for an archive server. Parameters used only for individual jobs include Name, Volume, and Stopped. Within a job definition, you can specify values for a given job property, or if you do not specify the value, its default value can be applied. In some cases, you can choose to specify no value, such as when a function is disabled.

Changing the property’s value in an individual job’s settings causes a different outcome than changing property’s value for the default job settings. Modifying values in an individual job affects only the behavior of the individual job. Modifying values for the default job settings affects every job that uses the default values. All changes take effect the next time ArkManager runs.

Use the following properties to define jobs for your archive server:

3.4.1 Job Information

The Job Information identifies control information for jobs on an archive server. Each job has a unique name that represents a unique relationship between an archive server and a source volume.

IMPORTANT:You can define only one job per source volume.

The following table describes the job information properties:

Table 3-2 Description of Job Properties for Job Information

Job Property

Description

Name

The administrator-specified unique job name. For example, svr1_users or svr2_finance. A job name can be up to 64 ASCII characters.

The job’s name persists for the life of the archive server and represents the relationship between the archive server and a specific source volume. You cannot reuse the name for any other archive server and volume relationship.

Specify the Name property only for individual jobs, not as a default value.

Stopped

Specify this property to define the job but leave it in a Stopped state until you manually activate the job. If the Stopped property is not used, the job starts, according to the Run Schedule settings, the next time ArkManager runs.

Specify the Stopped property only for individual jobs, not as a default value.

Full Copy or No Full Copy

If Full Copy is selected, the archive server copies all files specified by the job from the source volume to the archive volume on a one-time, special version occurrence. Use this option to save at least one version of every file eligible for versioning.

If No Full Copy is selected, the job begins at the next scheduled start time. Use this option to save versions of files eligible for versioning only as the files change during epochs.

3.4.2 Source Server Information

The Source Server information identifies the source server, the NSS volume that contains the information to be versioned, and the destination pool where temporary snapshot pools are stored during the versioning process.

Table 3-3 Description of Job Properties for Source Server Information

Job Property

Description

Server

The host name of the OES NetWare or NetWare 6.5 source server where the data to be versioned is located. For example, svr2. This server is in the same eDirectory tree as the archive server.

Volume

The name of the source NetWare 6.5 or OES NetWare NSS volume where the data to be versioned is located. For example, users or data.

Specify the Volume property only for individual jobs, not as a default value.

Snapshot Pool

NSS pool snapshot technology allows all eligible files to be versioned at the end of the epoch, even exclusively open files.

Specify the pool name of the destination pool for the snapshots. The snapshots are maintained temporarily at the end of an epoch until point-in-time file versions can be saved to the archive database. For example, create a pool named arksnaps on the source server.

If no snapshot pool name is specified or if the snapshot cannot be created for any reason, the versioning process copies files directly from the source volume. In this case, eligible files that are exclusively opened at the time cannot be versioned, and eligible files that are deleted before the copy occurs cannot be archived.

3.4.3 Run Schedule

Run Schedule specifies when to start the job upon activation, and the frequency for running the job. To set the frequency, you must specify one of three scheduling options: Use Defaults, Scheduled Interval, or Scheduled Start Time.

Table 3-4 Description of Job Properties for the Run Schedule

Job Property

Description

Scheduled Interval

If it is used, the Scheduled Interval specifies the elapsed time between the beginning of versioning processes for a job. The units can be seconds, minutes, hours, or days. For example, 45 seconds, 1 minute, 15 minutes, 2 hours, or 12 hours.

If the versioning process exceeds the time specified as the interval, the overlapping scheduled job is skipped. No file versions are saved for skipped job runs. After the version process completes, the job runs at its next scheduled interval. If you observe the job skipping some versioning intervals, you can increase the interval between versions or reduce the amount of data to be versioned by setting Filter properties.

Scheduled Start Time

If it is used, the Scheduled Start Time specifies the start time when the job’s version process begins and one or more days of the week to run the job.

  • Start: Specify the start time in hours and minutes.

  • Daily: Specify the days of the week to run the job. For example, specify All days for a daily job run, or specify one or more days of the week you want the job to run. Choices include Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, and All.

3.4.4 Delete Policy

The Delete Policy determines the retention of file versions by age or by number of versions.

Table 3-5 Description of Job Properties for the Delete Policy

Job Property

Description

Delete Interval

Specifies the schedule for deleting file versions, if they are eligible for deletion. 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 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 1 hour. When you activate the job, the Delete Schedule begins an interval timer. After 1 hour elapses, 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.

Maximum Keep

Specifies the maximum number of versions of each file to keep in the archive and how long to keep file versions. At least one of the values must be non-zero. If you set both the Maximum Keep Versions and Maximum Keep Time to zero values, the Delete Policy function does not run.

  • Time: The maximum time that a file version is maintained in the archive. Specify the time in whole numbers for seconds, minutes, hours, or days.

  • Versions: Specify the maximum number of versions of each file to keep in the archive. When the number of versions exceeds this integer value, the oldest version is deleted.

  • Keep Current Copy: By default, at least one file version of current files remains in the database, even if the Maximum Keep Time elapses. If Keep Current Copy is enabled, the archive keeps an existing file version as long as its source file is current on the source volume, beyond the Maximum Keep Time. 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 Maximum Keep Time, the archive database retains a copy of the file version until its Maximum Keep Time elapses. When the file version’s age exceeds the Maximum Keep Time, the archive deletes the file version at the next scheduled delete time.

    If Keep Current Copy is disabled, the archive deletes the file version when the Maximum Keep Time elapses.

3.4.5 Filter

The Filter information determines what data in the source volume gets versioned. You can combine the filters for the individual job with filters for the default job settings.

You can filter files in the source volume that you do not want to version by using a series of Include and Exclude elements under the Defaults element or an individual Job element in the sys:\arkManager\arkConfig.xml file. The order of the Include and Exclude elements determines what data is eligible for versioning. Make sure the order is adequate to achieve the desired filtering outcome.

Filtering is optional, but you should avoid versioning volumes that contain system software. Exclude system files and file types that change constantly, such as log files and databases. You can also exclude nonessential file types such as MP3 and temporary files such as Internet files. Identify the file types your applications use as intermediate saves for open files, such as the TMP files for Microsoft Word, and set up filters to exclude that file extension from versioning.

Extremely large files, such as database files and ISO image files, take a long time to be copied into the archive, which can potentially block other requests to access the database. You cannot filter files by file size, but you can modify database settings or distribute data to lessen the impact of versioning large files. Another option is to separate larger files into one or more separate volumes, and then create a job for each source volume. Schedule the jobs to run in off-peak hours.

For example, if your files are potentially very big, such as several hundred megabytes to gigabytes in size, you might need to increase the time that queries wait to access a locked MySQL database before time-out. For example, set the MySQL Lock Wait Timeout variable (innodb_lock_wait_timout) in the sys:\arkManager\arkSQL.cnf file to more than the default 50 seconds.

Table 3-6 Description of Properties for the Filter

Job Property

Description

Path

Specifies the relative path of directories in the specified source volume that you want to include or exclude in the versioning process. For example:


<path>\log</path>

Extension

Specifies the extension of files in the specified source volume that you want to include or exclude in the versioning process. Use the preceding dot followed by the characters of the file extension. For example:


<extension>.mp3</extension>

Pattern

Specifies the regular expression pattern to match for files that you want to include or exclude in the versioning process. For example, to specify a pattern for files that start with the letter a:


<pattern>.*\\a.*</pattern>

Wildcard

Specifies the wildcard pattern to match for files that you want to include or exclude in the versioning process. For example:


<wildcard>a*tmp</wildcard>

Include and Exclude Elements

You can filter out files in the source volume that you do not want to version by using a series of Include and Exclude elements. The child elements within each Include or Exclude element can contain multiple Path, Extension, and Pattern elements, in whatever order is needed to determine what data is eligible for versioning.

By default, all data in the volume is included. The first step in filtering is to exclude everything. For example:


<exclude>
  <path>\</path>
</exclude>

Next, add back in the paths, file types, and patterns for files you want to version. The latter include or exclude elements override previous include or exclude elements.

Pattern Elements

The regular-expression parser used for the <pattern> tag does not support the following regular-expression constructs in PERL 5:

  • The conditional constructs (?{X}) and (?(condition)X|Y)

  • The embedded code constructs (?{code}) and (??{code})

  • The embedded comment syntax (?#comment)

  • The preprocessing operations \l, \u, \L, and \U

The regular-expression parser used for the <pattern> tag supports the following regular-expression constructs, which PERL 5 does not:

  • Possessive quantifiers, which match as much as they can and do not back off, even when doing so would allow the overall match to succeed

  • Character-class union and intersection

    Character classes can appear within other character classes, and can be composed by the union operator (implicit) and the intersection operator (&&). The union operator denotes a class that contains every character that is in at least one of its operand classes. The intersection operator denotes a class that contains every character that is in both of its operand classes.

    The precedence of character-class operators is as follows, from highest (1) to lowest (5):

    • 1) Literal escape \x
    • 2) Grouping [...]
    • 3) Range a-z
    • 4) Union [a-e][i-u]
    • 5) Intersection [a-z&&[aeiou]]

Other notable differences from PERL-based regular expressions are shown in the following table.

Table 3-7 Comparison of Supported Regular Expressions and PERL-Based Regular Expressions

Supported Regular Expressions

PERL-Based Regular Expressions

Octal escapes must always begin with a zero. \1 through \9 are always interpreted as back references, and a larger number is accepted as a back reference if at least that many subexpressions exist at that point in the regular expression; otherwise, the parser drops digits until the number is smaller or equal to the existing number of groups or it is one digit.

\1 through \9 are always interpreted as back references; a backslash-escaped number greater than 9 is treated as a back reference if at least that many subexpressions exist; otherwise, it is interpreted, if possible, as an octal escape.

It is implicit that repeated invocations of the find method resume where the last match left off, unless the matcher is reset.

PERL uses the g flag to request a match that resumes where the last match left off.

Embedded flags always take effect at the point where they appear, whether they are at the top level or within a group; in the latter case, flags are restored at the end of the group just as in PERL.

In PERL, embedded flags at the top level of an expression affect the whole expression.

The defined class accepts dangling brackets but is strict about dangling metacharacters like +, ? and *, and throws a PatternSyntaxException if it encounters them.

PERL is forgiving about malformed matching constructs, as in the expression *a, as well as dangling brackets, as in the expression abc], and treats them as literals.

For more information, consult a programming textbook or search the Internet for a reference that discusses the behavior of regular expression constructs.

Wildcard Elements

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


<wildcard>d*sxi</wildcard>