Skipping Scheduled Backups

Support
1

This is going to be interesting to troubleshoot. It’s happening on one particular machine of three that I have running backups, about once a week on average, for maybe a month now.

The scheduled backup that day simply doesn’t start. The display says the next backup is scheduled for 19:30 that day. Next I look, nothing has happened (not even the Before script, which leaves a trail I can check), and the display says the next backup is scheduled for 19:30 the next day.

The system-level Show Logs shows nothing after the conclusion of the backup from the previous day.

The database is not locked - I was able to run a trial restore with no issues.

2

Is your Before script sometimes sending an exit code that would tell Duplicati to silently skip the backup job?

3

Sadly, no. The scripts are not running at all. They do two very simple things and I can tell that nothing of those is happening.

4

What operating system is it?

5

Ubuntu Server 20.04 LTS

6

Is that About → Show log → Live done retroactively at Information level (or better), or something else?

Although I don’t know if that may miss things, I’d prefer log-file=<path> at log-file-log-level=information.

“Interesting” probably meaning “challenging”. At least it seems like the job is a daily, so a miss can have ample time to look it over. Things to look at would be ls -lu --full-time on the before script (to see whether anything even tried to open it), and ls -l --full-time on Duplicati-server.sqlite, although the jump of the schedule to the next day seems like it should cause a DB write whether or not a backup ran.

If too much effort to check it manually, you could set up a daily cron job.

Speaking of time, does the system clock seem to be reliably accurate?

Is the system always up and running, is it sleeping and waking up, etc?

2.0.5.106_canary_2020-05-11

Fixed a case where backups could run immediately and ignore the scheduled time, thanks @warwickmm

doesn’t sound like your skip, but it’s a scheduler fix, so may have helped.

2.0.6.0_experimental_2021-04-09 would have it and is sort of a pre-Beta.
Or if you don’t like Experimental, you can wait until next Beta emerges…

7

I’ll put in a cron task to check the script and the DB. Results won’t be interesting until the next time it skips.

Nothing else is going on to indicate the clock is off.

Yes, this system runs full-time.

8

of course this will fail in November, because cron is not st00pid about DST. :wink:

9

Those are supplements to the log, so I hope a file log is there too.
Otherwise, we might stay at “DB updated, script was not read”…

This being Linux, script launch may need some forks and execs.
Does the system have ample capacity to handle possible peaks?
Running sar or something could probably keep an eye on things.
If backup runs at some popular time, maybe moving it would help.

10

The last time a day skipped, I checked the Information level logs and there was nothing there.

Since the first thing the before script does is delete a group of semaphore files, and the files were all still there from the previous day, I’m sticking to my hypothesis that nothing was even attempted that day.

But we’ll see now.

The time (23:30z) is not particularly “popular” in this environment. If it were my Plex media server instead of my file & utility server, it might be. But the Plex box doesn’t go until the wee hours when I’m sawing wood.

11

Well… a day skipped again. Nothing had started, the before-script was untouched.

And I started looking at EVERYTHING

And look: one day of the week was unchecked on the schedule.

facepalm

Sorry for running people in circles.

2 Likes
12

lol…thanks for following up! Glad you found the issue!

1 Like