different Jobs, you will probably want to use Pools. For additional details,
see the
\ilink{Pool Resource section}{PoolResource} of this chapter. This
- resource is required.
+ directive is required.
\item [Full Backup Pool = \lt{}pool-resource-name\gt{}]
\index[dir]{Full Backup Pool }
The {\it Full Backup Pool} specifies a Pool to be used for Full backups. It
- will override any Pool specification during a Full backup. This resource is
+ will override any Pool specification during a Full backup. This directive is
optional.
\item [Differential Backup Pool = \lt{}pool-resource-name\gt{}]
\index[dir]{Differential Backup Pool }
The {\it Differential Backup Pool} specifies a Pool to be used for
Differential backups. It will override any Pool specification during a
- Differential backup. This resource is optional.
+ Differential backup. This directive is optional.
\item [Incremental Backup Pool = \lt{}pool-resource-name\gt{}]
\index[dir]{Incremental Backup Pool }
Incremental
backups. It will override any Pool specification during an Incremental
backup.
- This resource is optional.
+ This directive is optional.
\item [Schedule = \lt{}schedule-name\gt{}]
\index[dir]{Schedule }
- The Schedule directive defines what schedule is to be used for the Job. The
- schedule determines when the Job will be automatically started and what Job
- level (i.e. Full, Incremental, ...) is to be run. This directive is
-optional,
- and if left out, the Job can only be started manually. For additional
- details, see the
- \ilink{Schedule Resource Chapter}{ScheduleResource} of this
- manual. If a Schedule resource is specified, the job will be run according
-to
- the schedule specified. If no Schedule resource is specified for the Job,
- the job must be manually started using the Console program. Although you may
- specify only a single Schedule resource for any one job, the Schedule
- resource may contain multiple {\bf Run} directives, which allow you to run
- the Job at many different times, and each {\bf run} directive permits
- overriding the default Job Level Pool, Storage, and Messages resources. This
- gives considerable flexibility in what can be done with a single Job.
+ The Schedule directive defines what schedule is to be used for the Job.
+ The schedule in turn determines when the Job will be automatically
+ started and what Job level (i.e. Full, Incremental, ...) is to be run.
+ This directive is optional, and if left out, the Job can only be started
+ manually using the Console program. Although you may specify only a
+ single Schedule resource for any one job, the Schedule resource may
+ contain multiple {\bf Run} directives, which allow you to run the Job at
+ many different times, and each {\bf run} directive permits overriding
+ the default Job Level Pool, Storage, and Messages resources. This gives
+ considerable flexibility in what can be done with a single Job. For
+ additional details, see the \ilink{Schedule Resource
+ Chapter}{ScheduleResource} of this manual.
+
\item [Storage = \lt{}storage-resource-name\gt{}]
\index[dir]{Storage }
\item [Run Before Job = \lt{}command\gt{}]
\index[dir]{Run Before Job }
The specified {\bf command} is run as an external program prior to
- running the current Job. Any output sent by the job to standard output
+ running the current Job. Any output sent by the command to standard output
will be included in the Bacula job report. The command string must be a
valid program name or name of a shell script. This directive is not
required, but if it is defined, and if the exit code of the program run
Thus if you edit it on a command line, you will need to enclose
it within some sort of quotes.
- Bacula checks the exit status of the RunBeforeJob
- program. If it is non-zero, the job will be error terminated. Lutz Kittler
- has pointed out that this can be a simple way to modify your schedules
-during
- a holiday. For example, suppose that you normally do Full backups on
-Fridays,
- but Thursday and Friday are holidays. To avoid having to change tapes
-between
- Thursday and Friday when no one is in the office, you can create a
- RunBeforeJob that returns a non-zero status on Thursday and zero on all
-other
- days. That way, the Thursday job will not run, and on Friday the tape you
- inserted on Wednesday before leaving will be used.
+ Bacula checks the exit status of the RunBeforeJob program. If it is
+ non-zero, the job will be error terminated. Lutz Kittler has pointed
+ out that using the RunBeforJob directive can be a simple way to modify
+ your schedules during a holiday. For example, suppose that you normally
+ do Full backups on Fridays, but Thursday and Friday are holidays. To
+ avoid having to change tapes between Thursday and Friday when no one is
+ in the office, you can create a RunBeforeJob that returns a non-zero
+ status on Thursday and zero on all other days. That way, the Thursday
+ job will not run, and on Friday the tape you inserted on Wednesday
+ before leaving will be used.
\item [Run After Job = \lt{}command\gt{}]
\index[dir]{Run After Job }
- The specified {\bf command} is run as an external program after the current
- job terminates. This directive is not required. The command string must be
-a
- valid program name or name of a shell script. If the exit code of the
-program
- run is non-zero, the current Bacula job will terminate in error. Before
- submitting the specified command to the operating system, Bacula performs
- character substitution as described above for the {\bf Run Before Job}
- directive.
+ The specified {\bf command} is run as an external program after the
+ current job terminates. This directive is not required. The command
+ string must be a valid program name or name of a shell script. If the
+ exit code of the program run is non-zero, the current Bacula job will
+ terminate in error. Before submitting the specified command to the
+ operating system, Bacula performs character substitution as described
+ above for the {\bf Run Before Job} directive.
- An example of the use of this command is given in the
+ An example of the use of this directive is given in the
\ilink{Tips Chapter}{JobNotification} of this manual. As of version
1.30, Bacula checks the exit status of the RunAfter program. If it is
non-zero, the job will be terminated in error.
\item [Client Run Before Job = \lt{}command\gt{}]
\index[dir]{Client Run Before Job }
- This command is the same as {\bf Run Before Job} except that it is run on
+ This directive is the same as {\bf Run Before Job} except that the program is run on
the client machine. The same restrictions apply to Unix systems as noted
above for the {\bf Run Before Job}. In addition, for a Windows client on
version 1.33 and above, please take careful note that you must ensure a
executable file. Specifying the executable's extension is optional, unless
there is an ambiguity. (i.e. ls.bat, ls.exe)
- The System \%Path\% will be searched for the command. (under the envrionment
+ The System \%Path\% will be searched for the command. (under the environment
variable dialog you have have both System Environment and User Environment,
we believe that only the System environment will be available to bacula-fd,
if it is running as a service.)
\item [Client Run After Job = \lt{}command\gt{}]
\index[dir]{Client Run After Job }
- This command is the same as {\bf Run After Job} except that it is run on
+ This directive is the same as {\bf Run After Job} except that it is run on
the
client machine. Note, please see the notes above in {\bf Client Run Before
Job} concerning Windows clients.
case the Storage daemon will buffer the File attributes and Storage
coordinates to a temporary file in the Working Directory, then when writing
the Job data to the tape is completed, the attributes and storage coordinates
-will be sent to the Director. The default is {\bf no}.
+will be sent to the Director.
\item [Where = \lt{}directory\gt{}]
\index[dir]{Where }
projects / bacula / docs / commitdiff