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:
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 property is not used, the job starts, according to the Run Schedule settings, the next time ArkManager runs. Specify the 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. This copies the files the first time job is run. 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. |
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 2 Linux 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. |
|
Mount Point |
The OES 2 Linux NSS volume where the data to be versioned is located. Each volume can be the target of only one versioning job. For example, primevol2. |
|
Snapshot Pool |
The OES 2 Linux NSS pool where the snapshots of the source volume are temporarily stored while file versions are written to the archive database. Specify the pool name of the destination pool for the snapshots. This pool is where the primary volume resides. 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, primepool2. 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. |
|
Free Space ID |
ID of the free space object to be used for storing snapshot data. For example, hda_nwfreespace1 or hda. |
|
Sectors |
Specifies the number of sectors on free space to be used for storing snapshot data. The value needs to be an integer, for example, 419430400. |
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.
|
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 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.
|
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 Filter section using Archive Versioning plug-in in iManager. 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.
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> |
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 nested include or exclude elements always override previous include or exclude 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):
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 sub-expressions 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 sub-expressions 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 * 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.
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>