The SEPuler - an event calendar

The scheduling of SEP sesam backup and restore tasks is controlled by the SEPuler, which acts as an electronic calendar and assistant performing all stored backup and restore events. The SEPuler is a permanently active background routine (daemon) constantly checking for events to be executed. When the SEPuler finds a backup/restore task the execution of the corresponding program is initiated. Once the backup task has started, the SEPuler will determine the next execution event for a cyclical backup/restore task and rewrite the event to the backup calendar. For example, if the SEPuler starts a weekly backup on Saturday, January 1, it will schedule a new weekly backup to occur on January 8.

Possible types of SEPuler events are backup, media, arbitrary command and newday.

Backups initiated with the Immediate start command from the GUI or command line are posted in the calendar as non-recurring events.

All events in SEP sesam start from the SEPuler schedule, even if they are unique, one-time tasks.

The schedule provides a normalized view of the event calendar showing completed, executing and future events. It can be viewed under GUI->Scheduling->Calendar Sheet.

Detailed information regarding completed backups, restores, etc. can be obtained here.

Schedules

The cyclical behaviour of SEP sesam is realized through the above mentioned schedules. A schedule is a table that describes the cyclic behaviour of an event, i.e. when the event is supposed to happen and in which periods to repeat it. The mere fact that a schedule exists does not automatically mean that an event is executed. Only when one or more events (backup, migration, command, etc.) are assigned will entries be made in the schedule which are then picked up by the SEPuler. Potential changes in the schedule naturally affect all events that are assigned to that schedule. The following functions can be done with a schedule:

• A schedule's execution can be deactivated in the GUI.
• A schedule can be used for an arbitrary number of events as long as the type of event is the same.
• A task (backup, migration, media action, restore and command event) may have events in several schedules.

Setting Event Priorities

For more complex event strategies schedules can be given priorities. Starting with the lowest priority 1 (up to 99) the SEPuler checks if, within a sesam day, an event with the same type (e.g. backup) and the same task name but with a higher priority has already run or is still scheduled to run. It then supresses the execution of events with lower priorities. This way, for example, several schedules are created that overlap on certain days. According to their priorities they prevent each others execution. Schedules with prio=0 get special treatment. This means that no dependencies are accounted for and they are always executed.

The equality of events is managed differently for the different types:

• Backup events are equal if their task name is the same
• Media events are equal if their drive number or drive group number is the same
• Command events are equal if their name is equal

Example

the backup of the directory /etc of the client stratum1 with the task name stratum1_etc is strated via three different schedules.

• On weekends the weekend event is done instead of the the daily event (prio 2 overrides prio 1).
• At the end of the month the end of month event is done instead of the daily event (prio 3 overrides prio 1).
• If the end of the month and the weekend coincide then the end of month event overrides the weekend event (prio 3 overrides prio 2)

Blocking Events

A blocking event is an event of any type with a higher priority which inhibits another event from moving to active backup status. It may be used to prevent the activation of certain events on specific days (e.g. end of year, end of fiscal year, holidays, etc).

Attention

• switching off a schedule blocks the execution of all events using this schedule (select Execute in the schedule).
• a blocking event has an effect on similar events only ( select blocking event in the events).

A blocking event is created by marking the corresponding priority field during the configuration of an event.

Example A backup event that executes the task stratu1_etc runs continually with priority 2. A second backup event, also for the task stratum1_etc is only scheduled for December 24th every year as a blocking event with priority 9. On December 24th the priority check detects a backup stratum1_etc with higher priority and overrides the execution of the daily backup. The blocking event itself doeen't create an entry in the job status but only gives out the message that it was activated.

The SEP sesam backup day - NEWDAY

SEP sesam NEWDAY event resets the backup calendar. A NEWDAY switch set to Monday, 8 am, will cancel all pending jobs from the weekend and reset the SEPuler to begin looking at the current day's calendar settings. SEP sesam defines the time interval between two NEWDAY-events as a backup day. Since there is only one event for NEWDAY, it is set after the installation and only its schedule can be modified or deactivated.

Having set a daily NEWDAY-event at 08:00, the backup day extends until the morning of next day at 08:00. Backups that run after midnight - the actual date change - are 'time stamped' with the previous day's date. The reason is quite simple, yet elegant. The data was created on day one, but not backed up until day 2. To do otherwise would create two backups for the same date, with a portion on backup day 1 and the remainder on backup day 2. With SEPsesam NEWDAY all media backed up from one day have the same date. SEP sesam NEWDAY gives system managers the flexibility to extend backup routines to run after midnight and retain the backup date of the prior day. This is very useful when the computers requiring backups exceed the time allotment between the end of day and midnight.

Weekends are often used for full-backups. When this is the case, it is advisable to interrupt the NEWDAY event on the weekend. Define the execution as a weekly event but without execution since a full backup is performed instead.

Note: SEP sesam protocol or log files are all created with the date of the backup day.

Example: Backup day from 10.SEP.2007 08:00 until 11.SEP.2007 08:00 A backup starting on 11.SEP.2007 00:40 will be assigned to backup day 10.SEP.2007, it will appear in the daily protocol as 20070910.

Backups can be arranged in shifts.

A NEWDAY-event also executes the following tasks:

• aborts all executing backups (data created after NEWDAY belong to the next backup sequence) This is also useful in complex network environments, when alerts are not transmitted to the backup server. These backup tasks would otherwise remain suspended but are terminated by the NEWDAY event.
• deletes files and database entries for savesets which no longer exist
• finalizes the SEP sesam status and daily log files
• reorganizes the SEP sesam database
• advances the calendar (SEPuler) by one day
• restart of the SMS- and STPD-processes

To ensure error-free execution of the SEP sesam backup environment SEP NEWDAY should never be completely deactivated. By switching NEWDAY off you will prevent SEP sesam from reordering its database. SEP sesam will no longer be able to delete old log files and will cause the system to exceed system disk drive storage.