Schedule Resource

The Schedule resource provides a means of automatically scheduling a Job as well as the ability to override the default Level, Pool, Storage and Messages resources. If a Schedule resource is not referenced in a Job, the Job can only be run manually. In general, you specify an action to be taken and when.

Schedule Start of the Schedule directives. No resource is required, but you will need at least one if you want Jobs to be automatically started.

Name

Name = <name> The name of the schedule being defined. The Name directive is required.

Enabled

Enabled = <yes|no> This directive allows you to enable or disable the resource.

Run

Run = <Job-overrides> <Date-time-specification> The Run directive defines when a Job is to be run, and what overrides if any to apply. You may specify multiple Run directives within a resource. If you do, they will all be applied (i.e. multiple schedules). If you have two Run directives that start at the same time, two Jobs will start at the same time (well, within one second of each other).

The Job-overrides permit overriding the Level, the Storage, the Messages, and the Pool specifications provided in the Job resource. In addition, the FullPool, the IncrementalPool, and the DifferentialPool specifications permit overriding the Pool specification according to what backup Job Level is in effect.

By the use of overrides, you may customize a particular Job. For example, you may specify a Messages override for your Incremental backups that outputs messages to a log file, but for your weekly or monthly Full backups, you may send the output by email by using a different Messages override.

<Job-overrides> are specified as: keyword=value where the keyword is Level, Storage, Messages, Pool, FullPool, DifferentialPool, or IncrementalPool, and the value is as defined on the respective directive formats for the Job resource. You may specify multiple Job-overrides on one Run directive by separating them with one or more spaces or by separating them with a trailing comma. For example:
Level=Full is all files in the FileSet whether or not they have changed.

Level=Incremental is all files that have changed since the last backup.

Pool=Weekly specifies to use the Pool named Weekly.

Storage=DiskAutochanger specifies to use DiskAutochanger for the storage device.

Messages=Verbose specifies to use the Verbose message resource for the Job.

FullPool=Full specifies to use the Pool named Full if the job is a full backup, or is upgraded from another type to a Full backup.

DifferentialPool=Differential specifies to use the Pool named Differential if the job is a differential backup.

IncrementalPool=Incremental specifies to use the Pool named Incremental if the job is an incremental backup.

Next Pool = <pool-specification> The Next Pool directive specifies the pool to which Jobs will be migrated. This specification takes precedence over any other **Next Pool** definition
Priority = <number> This directive permits you to control the order in which your jobs will be run by specifying a positive non-zero number. The higher the number, the lower the job priority. Assuming you are not running concurrent jobs, all queued jobs of priority 1 will run before queued jobs of priority 2 and so on, regardless of the original scheduling order.

The priority only affects waiting jobs that are queued to run, not jobs that are already running. If one or more jobs of priority 2 are already running, and a new job is scheduled with priority 1, the currently running priority 2 jobs must complete before the priority 1 job is run, unless AllowMixed Priority is set.

The default priority is 10.

See Priority for more information.

<Date-time-specification> determines when the Job is to be run. The specification is a repetition, and as a default Bacula is set to run a job at the beginning of the hour of every hour of every day of every week of every month of every year. This is not normally what you want, so you must specify or limit when you want the job to run. Any specification given is assumed to be repetitive in nature and will serve to override or limit the default repetition. This is done by specifying masks or times for the hour, day of the month, day of the week, week of the month, week of the year, and month when you want the job to run. By specifying one or more of the above, you can define a schedule to repeat at almost any frequency you want.

Basically, you must supply a month, day, hour, and minute the Job is to be run. Of these four items to be specified, day is special in that you may either specify a day of the month such as 1, 2, … 31, or you may specify a day of the week such as Monday, Tuesday, … Sunday. Finally, you may also specify a week qualifier to restrict the schedule to the first, second , third , fourth , fifth or sixth week of the month.

For example, if you specify only a day of the week, such as Tuesday the Job will be run every hour of every Tuesday of every Month. That is the month and hour remain set to the defaults of every month and all hours.

Note

By default with no other specification, your job will run at the beginning of every hour. If you wish your job to run more than once in any given hour, you will need to specify multiple Run specifications each with a different minute.

The date/time to run the Job can be specified in the following way in pseudo BNF:
<void-keyword> = on
<at-keyword> = at
<week-keyword> = 1st | 2nd | 3rd | 4th | 5th | 6th | first | second | third | fourth| fifth
<wday-keyword> = sun | mon | tue | wed | thu | fri | sat | sunday | monday | tuesday | wednesday | thursday | friday | saturday <week-of-year-keyword> = w00 | w01 | ... w52 | w53
<month-keyword> = jan | feb | mar | apr | may | jun | jul | aug | sep | oct | nov | dec | january | february | ... | december <daily-keyword> = daily <weekly-keyword> = weekly
<monthly-keyword> = monthly <hourly-keyword> = hourly <digit> = 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
<number> = <digit> | <digit><number>
<12hour> = 0 | 1 | 2 | ... 12
<hour> = 0 | 1 | 2 | ... 23
<minute> = 0 | 1 | 2 | ... 59
<day> = 1 | 2 | ... 31 | lastday
<time> = <hour>:<minute> | <12hour>:<minute>am | <12hour>:<minute>pm
<time-spec> = <at-keyword> <time> | <hourly-keyword>
<date-keyword> = <void-keyword> <weekly-keyword>
<day-range> = <day>-<day>
<month-range> = <month-keyword>-<month-keyword>
<wday-range> = <wday-keyword>-<wday-keyword>
<range> = <day-range> | <month-range> | <wday-range>
<date> = <date-keyword> | <day> | <range> <date-spec> = <date> | <date-spec>
<day-spec> = <day> | <wday-keyword> | <day> | <wday-range> | <week-keyword> <wday-keyword> | <week-keyword> <wday-range> | <dailykeyword>
<month-spec> = <month-keyword> | <month-range> |<monthly-keyword>
<date-time-spec> = <month-spec><day-spec><time-spec>
Note

The Week of Year specification wnn follows the ISO standard definition of the week of the year, where Week 1 is the week in which the first Thursday of the year occurs, or alternatively, the week which contains the 4th of January. Weeks are numbered w01 to w53. w00 for Bacula is the week that precedes the first ISO week (i.e. has the first few days of the year if any occur before Thursday). w00 is not defined by the ISO specification. A week starts with Monday and ends with Sunday.

According to the NIST, 12am and 12pm are ambiguous and can be defined to anything. However, 12:01am is the same as 00:01 and 12:01pm is the same as 12:01, so Bacula defines 12am as 00:00 (midnight) and 12pm as 12:00 (noon). You can avoid this abiguity (confusion) by using 24 hour time specifications (i.e. no am/pm).

An example schedule resource that is named WeeklyCycle and runs a job with level full each Sunday at 2:05am and an incremental job Monday through Saturday at 2:05am is:
Schedule Name = "WeeklyCycle" Run = Level=Full sun at 2:05 Run =
Level=Incremental mon-sat at 2:05
An example of a possible monthly cycle is as follows:
Schedule {
    Name = "MonthlyCycle"
    Run = Level=Full Pool=Monthly 1st sun at 2:05
    Run = Level=Differential 2nd-5th sun at 2:05
    Run = Level=Incremental Pool=Daily mon-sat at 2:05
}
The first of every month:
Schedule {
    Name = "First"
    Run = Level=Full on 1 at 2:05
    Run = Level=Incremental on 2-31 at 2:05
    }
The last day of February (28th or 29th), on May 31st and September 30rd at 20:00. In show schedule output, LastDay is printed as "31"
Schedule Name = "Last"
Run = Level=Full on lastday Feb, May, Sep at 20:00
Every 10 minutes:
Schedule {
    Name = "TenMinutes"
    Run = Level=Full hourly at 0:05
    Run = Level=Full hourly at 0:15
    Run = Level=Full hourly at 0:25
    Run = Level=Full hourly at 0:35
    Run = Level=Full hourly at 0:45
    Run = Level=Full hourly at 0:55
    }

Technical Notes on Schedules

Internally Bacula keeps a schedule as a bit mask. There are six masks and a minute field to each schedule. The masks are hour, day of the month (mday), month, day of the week (wday), week of the month (wom), and week of the year (woy). The schedule is initialized to have the bits of each of these masks set, which means that at the beginning of every hour, the job will run. When you specify a month for the first time, the mask will be cleared and the bit corresponding to your selected month will be selected. If you specify a second month, the bit corresponding to it will also be added to the mask. Thus when Bacula checks the masks to see if the bits are set corresponding to the current time, your job will run only in the two months you have set. Likewise, if you set a time (hour), the hour mask will be cleared, and the hour you specify will be set in the bit mask and the minutes will be stored in the minute field.

For any schedule you have defined, you can see how these bits are set by doing a show schedules command in the Console program. Please note that the bit mask is zero based, and Sunday is the first day of the week (bit zero).