Possible bug in archive scheduling

[AndreaR]

NOTE: this report is possibly related to Issues with archiving scheduling

For a groups of PCs which backup weekly, I have setup archiving in the following way:

The intended behaviour is archiving a backup on the first Sunday of each month, which should be selected by

*;1,2,3,4,5,6,7;*;0

as archive window.

However, the window is ignored and the backup is performed after (at least) 27 days, for example:

Is there something wrong with the way I specified the archive window, or is this a bug?

Thank you!

EDIT: I have now realized that there is a conceptual error in my rule: it should archive every 3 days, using a backup window of *;1,2,3,4,5,6,7;*;0, not every 27 days

This would assure a new archive on the first Sunday of each month, without skipping any month.

Archiving every 27 days with a window of *;*;*;0 doesn’t force archiving on a specific Sunday, but on different Sundays depending on when a client has been first configured in urbackup.

[AndreaR]

An update on this issue: today is the first of the month, and apparently this triggered archiving, although it’s not Sunday. As an example, for one PC which has been using urbackup since October the situation is the following:

with one archiving happening on Nov 23 (i.e. the first backup older than the 27 days I specified in archive settings) and one happening on Dec 1 (apparently, the first day matching a portion of the archive window).

Thanks for watching into this one.

[AndreaR]

I bring back this topic, although it is a secondary issue, because after checking the behaviour of archiving for months, I’ve come to the conclusion that the archive parameters in an archive rule:

• hour
• day of month
• month
• day of week

are ORed rather than ANDed.

This is, I think, the reason why my rule, which uses

*;1,2,3,4,5,6,7;*;0

as archive parameters, does NOT archive ONLY on the first Sunday of a month. What it does is archiving on Sunday OR on one of the first 7 days of the month, depending on which condition matches first once the days specified in the Archive every field of the rule have passed since the previous backup

IMHO, the archive parameters should be ANDed, because ANDing them allows to create more refined rules, if necessary. At the same time, if one needs to OR the parameters, he/she can easily get the needed result using multiple archive rules, ie

rule 1: *;1,2,3,4,5,6,7;*;0

result: Archive on the first Sunday of each month

rule 1: *;1,2,3,4,5,6,7;*;*
rule 2: *;*;*;0

result: Archive during the first week of the month OR on Sunday

Note that the documentation is wrong, when it says:

To archive a file backup on the first Friday of every month we would then set “Archive every” to something like 27 days. After entering the time we want the backups archived for we would then add

*;*;*;5

Suppose for example that the server is stopped for more than a month, and restarted on the second week of the month. On the next Friday, archive will be triggered since it’s Friday and more than 27 days have passed since last backup, but from that moment all backups will happen on the second week of the month.

IMHO, *;1,2,3,4,5,6,7;*;0 (with AND) is the only way to be sure that archiving only happens on the FIRST week of the month (and on the specified day)

Thanks for your attention and for the great work you’re doing with UrBackup

[zmezoo]

I know im dredging up a old thread however i thought it better than posting a new one about this topic.

I would like to voice that i agree with what AndreaR is pointing out. I find it extremally annoying to have an archive every day for a month meant to keep recent backups for the past month, go and mark a 3 month old backup of a client that’s been offline for a month as archived. sometimes its not even the most recent backup but rather an older one, due to each day it has to go one backup farther back to find a backup that is not archived yet. It can result in older backups being archive longer than the newer ones, simply because the older one was archived after the newer one, or re-achive a second or third time.

Also if a second archive rule tries to apply and there are no recent backups that are not already archived, it could mark a very old backup as archived. An example of this is marking 1 backup a year to keep for a year. if the 50 most recent backups are all already marked as archived when this rule is applied and the 51st is not archived yet, the 51st is the one marked to keep for 1 year from when the rule is applied not the 1st most recent, ignoring the fact the 51st might be any number of months old. This completely kills having multiple archive rules, if less frequent rules apply in a useless manner.

Laptops and computers that are not always on or awake, are extremally susceptible to this! Basically you need all clients to archive n+1 times as often as the most frequent archive rule at all times to avoid what is happening, and get the desired effect. This is not a resonable expectation for a portable device that is not always on.

While i can see the merit of the current system maybe a few options for how archived backups are selected, could be useful. As AndreaR suggested flipping the and and or logic. Also an option of being able to make it only use the most recent backup as the archive target, and if its already marked for archive resetting its archive window to the new target window, only if its current window is shorter than the new target window.