The SEPuler - an event calendar 4.4
SEPuler – an event calendar
SEPuler is a process that controls the scheduling of all SEP sesam tasks, such as backup, migration, replication, restore and other tasks. It acts as an electronic calendar and assistant performing all SEP sesam data protection events.
SEPuler is a permanently active background routine (daemon), constantly searching for events to be executed. When SEPuler finds a scheduled task or manually triggered event, the execution of the corresponding program is initiated.
Once the event has started, SEPuler will determine the next execution event for a cyclical task and rewrite the event to the task calendar. For example, if SEPuler starts a weekly backup on January 1, it will schedule a new weekly backup to occur on January 8.
Events 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, non-recurring tasks. An overview of scheduled as well as completed, expired events and their current status is provided by Calendar sheet from the Main selection -> Scheduling -> Calendar sheet.
Schedules are used for setting events to occur at a specific time. A schedule is a timetable that defines the cyclic behavior of an event, i.e. when the event is to take place and how frequently to repeat it. The 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 to the schedule, it becomes active. The entries in the schedule are then picked up by the SEPuler. Modifying a schedule affects all the events assigned to that schedule.
Flexible scheduling features include the following:
- Any number of events of the same type can be linked to one or more schedules.
- A task (backup, migration, replication, media action, restore and command event) may have events in several schedules.
- From v. 4.4.3 onwards, schedules provide User defined option that allows you to create a calendar which is customized according to your country or company specific requirements. You can use it to exclude scheduled jobs from running on specific dates, such as holidays, or to schedule additional jobs on selected dates. For details, see Creating Custom Calendar.
- A schedule's execution can be deactivated: a schedule will remain displayed as shaded in the list of schedules, but the related jobs will not run.
For complex event strategies, event priority is used by SEPuler for resolving scheduling conflicts. Priorities can be assigned to events, from lowest (1, default) to highest (99). For each SEP sesam backup day all scheduled events are checked according to their type and priority to see whether the events of the same type (for example, a backup) with the same task name and higher priority have already expired or are still planned to run; in the latter case, SEP sesam suppresses execution of lower priority events of the same type. In other words, if there are more equal events (see equality of events) of the same type scheduled on the same backup day, only the event with a higher priority is executed. This prevents the events that might be linked to several schedules, which overlap on certain days, to be executed except for the one with the highest priority.
If all equal events of the same type have the same priority (for example, the default – 1), then all of them are executed. Events with priority 0 are not checked for dependency of event priorities and are always executed.
Priorities can be used together with Blocking date option.
|Event priority determines which job in a queue will first be executed regardless of the equality of events. If there are jobs in the queue and a new event with a higher priority is activated by SEPuler, this job will first access a busy device.|
Equality of Events
The equality of events is managed according to their type:
- Backup events are equal if their task name is the same. The same is true for each individual event type: migration, replication, command and restore event.
- Media events are equal if their drive number or drive group number is the same.
Example In the following example, backup of the directory /etc of the client stratum1 with the task name stratum1_etc is started via three different schedules.
|Daily||8 p.m.||1||daily incremental|
|Weekend||6 p.m.||2||differential on the weekend|
|End of Month||9 p.m.||3||full at the end of the month|
- On weekends, the weekend event is performed instead of the daily event (prio 2 overrides prio 1).
- At the end of the month, the end of month event is performed 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 is performed instead the Weekend event (prio 3 overrides prio 2).
A blocking event is any type of event with a higher priority that obstructs another event and prevents it 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).
A backup event that executes the task stratum1_etc is configured to run daily with priority 2. A second backup event for the same 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 the stratum1_etc backup with higher priority and overrides the execution of the daily backup. The blocking event itself does not create an entry in the job status, but sends a notification that it was activated.
SEP sesam backup day – NEWDAY
NEWDAY is used to cancel all pending jobs from the previous day and to define a new backup day. All SEP sesam protocol and log files are created with the date of the backup day.
If a NEWDAY event is set for 08:00, the backup day is defined from 8 a.m. of the current day to 8 a.m. of the next day. Backups that run after midnight – the actual date change – are 'time stamped' with the previous day's date in order to avoid the creation of two backups for the same data (one save set for day 1 and another for day 2).
With SEP sesam NEWDAY, all media backed up from one day have the same date. SEP sesam NEWDAY gives system administrators 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 skip the NEWDAY event on weekends. Define the execution as a weekly event but without execution on weekend to enable scheduled full backups to be performed. Backups can be arranged in shifts.
Other NEWDAY-event roles
Besides resetting the event calendar and setting a new backup day, NEWDAY also performs the following:
- Depending on SEP sesam version, the NEWDAY behaviour is slightly different when it comes to cancelling active tasks.
- In v. 4.4.3 Tigon, NEWDAY event may or may not abort any active tasks. This behaviour is defined by selecting the check box All Events in the Schedules -> NEWDAY event properties -> Parameter tab.
- In v. ≤ 4.4.3 aborts all running backups (data created after NEWDAY belong to the next backup sequence). This is especially useful in complex network environments when alerts are not transmitted to the backup server. These backup tasks, which would otherwise remain suspended, are terminated by the NEWDAY event.
- Deletes files and database entries for save sets which no longer exist.
- Finalizes the SEP sesam status and daily log files.
- Reorganizes the SEP sesam database.
- Advances the event calendar (SEPuler) by one day.
- Restarts the SMS- and STPD-processes.
To ensure error-free execution of the SEP sesam backup environment, SEP NEWDAY should never be completely deactivated. Switching NEWDAY off prevents 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.
Backup day is defined from April 10th 2017 from 08:00 until April 11th at 08:00. This means that a backup starting on April 11th 2017 at 00:40 will be assigned to backup day April 10th 2017 and will appear in the daily protocol as 20170410.