Default job settings are property settings that can optionally be used in any individual job on the server. Go to an individual job to configure it to use defaults.
To manage the archive server’s default job settings:
In iManager, expand Archive Versioning, then click Archive Server Properties.
Select the archive server you want to manage, then wait for the page to refresh.
For information, see Section 7.2, Configuring Archive Volume.
Select the Default Job Settings tab.
On the Default Job Settings page, specify the following default job information property.
Property |
Description |
---|---|
Copy All Files the First Time the Job Is Run |
If Copy All Files is selected, the job saves versions of all eligible files to the archive database the first time the job is run. Thereafter, the job saves file versions only for files that changed. If Copy All Files is deselected, the job saves versions only of eligible files that were changed during the epoch, such as files that were added, modified, renamed, deleted, or where trustee information changed. |
When you are done, click Apply to save your changes, or click Cancel at any time to discard them.
NOTE:On configuring the job first time, Copy All Files may get deselected on refresh. Select again before clicking Apply.
On the Default Job Settings page, specify the following default source server information properties.
Property |
Description |
---|---|
Server |
The host name of the source server where the data to be versioned is located. For example, servername.context. The source server is in the same tree as the Archive and Version Services server. If you specify a new source server for an existing job, the archived data becomes associated with the source volume on the new source server. Typically, you change the source server only when you have renamed the it. |
Snapshot Pool |
The name of the destination pool where snapshots of the source volume are created and temporarily maintained at the end of an epoch until point-in-time file versions can be saved to the archive database. For example, pusers_s1 or pdata_s1. 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. |
Free Space ID |
ID of the free space object to be used for storing snapshot data. For example, /dev/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, 409600. |
Filter |
Set filters to specify the types of files and directories to be versioned. For more information, refer to the online help. |
When you are done, click Apply to save your changes, or click Cancel at any time to discard them.
On the Default Settings page, specify when to start the job and the frequency for running the job. To set the frequency, you must specify only one of three scheduling options:
Property |
Description |
---|---|
No Run Schedule |
Select No Run Schedule to indicate that there is no default schedule available for the server. |
Every |
Select Every to enable a Scheduled Interval. Specify the elapsed time between the beginning of versioning processes for a job. In the Units drop-down list, select 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 that the job skips some versioning intervals, you can increase the interval between versions, or you can reduce the amount of data to be versioned by setting Filter properties in the Source Server Information section using iManager. |
Time |
Select Time, specify the start time when the job’s version process begins, then specify one or more days of the week to run the job.
|
When you are done, click Apply to save your changes, or click Cancel at any time to discard them.
The delete policy determines the retention of file versions by age or by number of versions. If a delete policy is set, the job runs a process to delete file versions according to its own Delete Schedule. The delete process is not related to the job’s Run Schedule, which determines when file versions are saved from the source volume. The job’s delete policy runs if the job is in a Running, Scheduled, or Stopped state. The job’s delete policy does not run if a job is in the Clean Up Users, Not Configured, or Deleted state.
IMPORTANT:The Delete Schedule operates separately from the Run Schedule.
On the Default Settings page, specify one of the following options:
Property |
Description |
---|---|
No Delete Policy |
Select this option if you want to retain file versions indefinitely. |
Define Job Delete Policy |
Select this option if you want to configure a default delete policy, then specify the schedule for deleting file versions, if they are eligible for deletion. Set the Interval and Maximum Keep settings. |
If you selected Define Job Delete Policy, complete the following information:
Property |
Description |
Interval |
This setting represents the amount of time to wait from the time a delete-versions process ends until another delete-versions process begins. If a value is not specified, 24 hours is the default interval. How long the delete process takes depends on the number of files stored in the archive database. For example, suppose you set the Delete Schedule Interval to 1 hour. When you save a job, ArkManager starts the interval timer. After 1 hour elapses, the job kicks off its delete-versions process, resets the interval timer, and pauses the timer. When the delete process ends, the interval timer begins. The delete intervals repeat in this manner until the job is stopped. |
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. NOTE:Whenever the job is run, it checks for the values specified in the Time and Versions fields to delete the job. The job is deleted depending on the condition that is satisfied, by the values specified in either the Time or Versions field.
|
When you are done, click Apply to save your changes, or click Cancel at any time to discard them.
Each job can optionally use none, one, or more of the default settings. Each job’s usage of defaults is independent of other jobs’ usage.
It is not necessary to stop jobs that use defaults while you modify, add, or remove default settings. Make your changes, then click OK or Apply to save them. The following table describes special circumstances for how the changes take effect.
For more information on the state of the Job, refer Job Status information.
Table 7-1 How Changes to Default Job Settings Take Effect
Change Made to Default Settings |
State of the Job When You Save Default Job Settings |
Additional Actions in Jobs that Use Defaults |
---|---|---|
Modifying an existing default Delete Policy |
Running, Scheduled, or Stopped |
If a delete-versions process is in progress, the run is completed with the old delete policy. The delete policy applies for the next delete-versions. |
Modify any existing default setting except Delete Policy |
Running |
The job runs are completed with the old setting. |
Clean Up Users |
The Clean Up Users run is stopped gracefully, and the job is placed in the Stopped state. The list might be only partially cleaned up. |
|
Not Configured |
The job remains in the Not Configured state until you verify the individual job settings and start or schedule the job. |
|
Add a default setting |
Any |
To take advantage of the new defaults, you must modify settings in individual jobs to use them. |
Remove default settings |
Running |
The job run is completed with the old settings, then the job is placed in the Not Configured state. Go to the individual jobs to specify values for the missing settings. |
Scheduled or Stopped |
Jobs are placed in the Not Configured state. Go to the individual jobs to specify values for the missing settings. |
|
Clean Up Users |
The Clean Up Users run is stopped gracefully, and the job is placed in the Stopped state. The users list might be only partially cleaned up. The job is then placed in the Not Configured state. Go to the individual job to specify values for the missing settings. |
|
Not Configured |
The job remains in the Not Configured state until you verify the individual job settings and start or schedule the job. |