Schedules and Retentions

Schedules and retentions play a major role in calculating the requirements of a backup system. The number of tapes and the disk space required depend to a large extent on these two parameters. For instance, a 10MB backup taken every hour with a retention period of one month would require at least 7200MB of disk space to hold the full backup cycle.

Setup

Bacula will do exactly what you tell it to do. This is why you should be careful with Schedules and Retentions. If the frequency of your Schedule is high and the retentions are long, you will need a lot of disk space. In addition the catalog will be large, as its size is directly proportional to the number of jobs and the retention periods.

On the other hand, if you miss your retention and scheduling targets implied by policies, you may end up having your last Full backup recycled before a new Full has started.

Example

Let’s say that we have a pool “Storage1-WeeklyFull-pool” with all retention times set to 7 days. Further we have an incremental pool “Storage1-DailyInc-pool” with the same retention times. The Full backups are scheduled each Monday night and Incrementals daily from Tuesday to Sunday:

We can see the Full backups in red and the Incremental backups in blue. The retention times are indicated by a lighter color. The first Full F01 will expire on the same day we take the next Full F02. This is dangerous: if for any reason the Full job F02 does not succeed, no Fulls are available at that point in time. In this case, setting the full pool retention to 8 or 9 days allows the backup administrator to re-run a Full manually (disabling the Incremental of the day while running). Alternatively, you can configure Maximum Full Interval to 7 days to force the promotion of an Incremental to a Full if no Fulls are available in the catalog for the last 7 days.

If you want to guarantee to your users that they can go back in time for 7 days, the retention times in the example scheme depicted above will be too short: Imagine a user on day 11 (Thursday) in the morning (I09 will be taken in the late evening) wanting to have a file back from the week before, and the only thing she knows is that she last saw the file on Friday of the previous week. Since the retention time of Full F01 has expired, all the Incremental backup that followed can no longer be used to construct the file tree, because Bacula will need a Full and all following Incremental for this. Thus at this point in time you will only be able to go back to the Monday of the same week when the most recent Full was taken. Of course it could be that the file we are looking for has changed on day 5 (Friday of the week before) and was backed up in the Incremental I04, but this is a special case. If the file did not change it would not have been in that backup.

To accomplish the goal at all times with the above scheme the retention time for the Full should be at least 15 days.

Read further about Retention Period Configuration.

Note

The example above is a simple one, there are other ways of scheduling: using a specific week number (beware of 53 weeks years), or depending on a specific weekday (4th Sunday for example, beware of months with 5 Sundays). Theses variations must be well verified to avoid overlapping or, worse, missing a Full backup and thus creating a gap. In such a case you would be unable to restore in certain situations.

When planning schedules, it is essential to pay attention to corner cases, as sometimes the year has 53 weeks. or a month 5 weeks. In such cases if the retention period doesn’t take these situations into account the previous full backup may be pruned or overwritten before it should. It is recommended to configure Bacula in such a way that at least two full backups co-exist for a while. It is better to be safe than sorry.

Along with storage space, the catalog also grows proportionally to the number of files and the frequency of the backups.