Strange bug that forces me to abandon UrBackup

Server
1

Hello guys,

I have been experiencing UrBackup for about 3 months and at first it seemed like an excellent solution, however, it has not met me as expected due to abnormal behavior in the automatic execution of backups in the medium term.

After setting up the server, clients and backup windows, everything works fine for a while (except for the bug I reported in this topic: Inconsistent backup status after prefilescript implementation), but after a few weeks, the automatic backup of some (random) clients stops working, forcing me to manually perform the tasks.

I could see that backup jobs suffer small consecutive delays each day, until they reach the limit of the backup window, when it stops running automatically, as shown in the following image:

image
image649×533 16.9 KB

Server and client time and date settings are correct and have no inconsistencies.

Has anyone experienced this and knows what might be happening? I’ve already redoed the server from scratch, but the behavior persists.

If I can not overcome this problem, unfortunately, I will have to abandon UrBackup because it does not show a reliable solution. Every day I need to check the backups and manually run those that did not run automatically, which does not make sense.

Clarifying: There are no errors and no record of backup jobs that fail on logs. Nothing happens and backups are not even started.

Environment overview:

UrBackup Version: 2.3.8
Server: CentOS 7.6 / Kernel 5.1.3
Storage filesystem: Btrfs
Clients: Windows and Linux

Any suggestions on how to solve this serious problem?

Is it possible to perform backup tasks from the command line? So I could disable the backup window in the settings and schedule the tasks through crontab, until the bug is resolved.

Thank you for any help.
André

2

Looks like you’re doing incremental backups with the interval set for 24 hours. Change it to 23 hours to fix your schedule slip problem.

If you had left the backups alone when the first one was skipped on 6/5, the automatic backups would have resumed the next day near the start of the window. Every time you manually ran a backup you reset the 24 hour timer for the next backup, which was outside the window when it expired, so you ran another manual backup.

UrBackup was doing what you told it to do. You just never let it catch up after you interfered with the automatic schedule.

3

Yes, I’m doing incremental backups with the interval set for 24 hours and yes it happens with clients configured with incremental backup, too. In the submitted example, it is a client configured to perform only full backups with a 1-day interval (note the second column of the printscreen - no incremental). In this case I can’t set 23 hours, is there some adjustment that can be made to fix this problem?

I applied the suggested configuration on incremental backup clients, I will observe the behavior from now.

Thank you very much.

4

Don’t do that. You’re wasting time and storage space. Incremental backups (both file and image) under UrBackup are as good as full backups under other products. The backend storage is handled in a different way than pretty much every other product. It uses the advanced features already present in the OS and filesystem better than others that still think like MS-DOS 3.3. When you need to restore a file you’ll see how much better UrBackup is.

Doing only incremental backups is a standard practice among UrBackup users. Doing only full backups actually hurts performance as the client-server design is optimized for frequent incrementals.

5

Perhaps try changing 1 day to .95 and see if that works?

6

Thanks for the feedback. In this case, I’m doing backups of FileMaker database files, which does not support incremental backup natively, so each backup is a new file. In addition, a pre-backup script compresses the files into a new 7z file. I used incremental backup for a while in this scenario, but the gain was very small. I preferred to use the full backup to reduce the risk of possible restoration issues. Do you believe that even in this situation it is always preferable to use incremental backups?

Your configuration tip from 24 to 23 hours interval seems to have worked for incremental backups, they were automatically executed in the last backup window, now I need to observe the medium and long term. For full backups, i’m trying DonN’s tip (0.95 day interval - at least UrBackup accepted and saved). Thank you so far.

7

Thank you, DonN. I’m trying this, let’s see how it works.

8

Could you explain me better why this happens? Why would a user choose 23 hours instead of 24? Let’s just say this is not so logical.
Is there anything I did not get in the documentation about this behavior and the correct way to configure the system to avoid it? Thanks.

9

The observed behavior in the first post shows that each backup begins around 25 to 30 minutes later than the previous day’s backup. Wherever this schedule creep comes from, expecting each backup to occur precisely 24 hours after the start of the previous backup differs from reality. Using 23 hours (or a fractional value of days) will tend to move the backup earlier in the window. The limits on simultaneous backups and network bandwidth will tend to counter this, allowing each backup to happen at the first opportunity each day.

10

going back to your original question yes there is a command line batch file that you can call from the clients from some autosys agent (or simply task manager):

C:\Program Files\UrBackup>UrBackupClient_cmd.exe --help

for example:

C:\Program Files\UrBackup>UrBackupClient_cmd.exe start --incremental --file
C:\Program Files\UrBackup>UrBackupClient_cmd.exe start --full --file
C:\Program Files\UrBackup>UrBackupClient_cmd.exe start --incremental --image
C:\Program Files\UrBackup>UrBackupClient_cmd.exe start --full --image

11

Confusing, but I think I get it. I’ve made the changes, let’s see how it works over the days. No words to thank for your help.

12

That’s nice! Thank you very much!