I do not use Duplicati’s schedule to start a backup. I use our RMM tool. So the actual run time is not an issue for me & I have not tested it. Yes, the issue I have as I depicted in my log example, is the logged start & end times being 5 hr ahead of my actual time on the applicable computer date/time. So clearly, the log is using GMT time & NOT local time. Thanks.
My 7:15pm job (M-F) starts at the correct local time and, as everyone else has pointed out, records GMT times in the logs and reports. This could be overlooked as being a bug…
This same job does not run on Friday at 7:15pm since Duplicati thinks that it’s 0:15am on Saturday. Then it will run on Sunday at 7:15pm since Duplicati thinks that it’s 0:15am on Monday. Now I would consider this a major issue…
I would think that having backups not run, or run when they’re not supposed to, would be pretty high on the priority list…Especially since this has been an issue for over a year, even before version 2.
I can confirm this is STILL a problem with 184.108.40.206_beta_2018-04-02. This causes major problems for us as our maintenance window is Sunday evenings and the destination server could be offline during this time. Also, because we would like a backup BEFORE there is any maintenence downtime hence the schedule for Friday night. Anyone have any idea when this will be addressed? I can’t believe there are many issues with a higher priority for this long.
Here we are with the latest stable update (220.127.116.11_experimental_2018-11-12) and this time issue STILL has not been solved! Even the beta versions don’t mention that this has been solved… Taking a look at the changelog indicates that the beta versions have the same major changes as does the latest “experimental” version.
I think that’s exactly the release path. There was a canary that led to experimental too. Basically test-and-promote. This is my reconstruction of the history. At the moment, canary is beyond both experimental and beta, but that’s what it’s for – you get the latest fixes and the latest bugs. Unfortunately, this issue doesn’t appear fixed even in canary. I can’t speak for development, but would a fix in canary help any of you out? Experimental and beta are not frequent occurrences. Canary can be unpredictable, either stable or not…
Possibly a workaround is to know the bug is there, and adjust the day spec to fit (shift a day to give UTC). That plan gets worse if you backup at a time which is either same UTC day or one-off depending on DST. Original case of 7:15 PM being next day at UTC-5 goes to same-day (23:15) in the DST period at UTC-4. Another problem with workarounds is that the workaround may need removal when actual bug fix arrives.
There are a number of time bugs, and I can’t accurately say which is highest priority. One dangerous one breaks hourly-or-faster backups when times happen twice at DST time change, when clocks are set back. Another perhaps-less-disastrous one is DST causing backups to move around when viewed in local time. Then there’s this bug. At one it was thought changing the scheduler to use local time might fix many bugs (possibly adding others – time is hard), however I wonder if less risky, local, temporary fixes might be had:
DateTime.ToLocalTime Method added to that in the debugger compiler looks promising based on looking at About --> System info --> proposedSchedule, where the time is in UTC and the formatting is not friendly yet.
If it turns out a simple fix was possible, it’s too bad it didn’t go in. Bug tracking doesn’t seem very formalized, especially from the flood of forum support posts. GitHub issues might do better, but backlogs are abundant.
Mostly correct, in that it won’t run on the day you requested, but if you look at proposedSchedule it might run 6 days later. Here in UTC-5 time, a Tuesday 12/4 11 PM schedule gets proposed for next Tuesday 12/11 at 4 AM UTC, and in local time that’s Monday 12/10 11 PM. I’m assuming it will run, but I obviously haven’t seen it.
Thanks for the fix! It’s the same one I used, except I just added a ToLocalTime on the line I highlighted. A nice thing about its behavior is that it won’t hurt if the scheduler ever goes to local time, and the code still remains.
Backups will run at the correct local time, just not on the correct days… It has to do with how Duplicati checks the start time (EST) with its own clock (UTC).
Example: Backup set to run on weekdays at 8pm (EST)
Mon --> Backup starts on Tuesday at 1am (UTC) --> Weekday = run
Tue --> Backup starts on Wed at 1am (UTC) --> Weekday = run
Wed --> Backup starts on Thu at 1am (UTC) --> Weekday = run
Thu --> Backup starts on Fri at 1am (UTC) --> Weekday = run Fri–> Backup does not start on Sat at 1am (UTC) --> Weekend = don’t run
Sat --> Backup does not start on Sun at 1am (UTC) --> Weekend = don’t run Sun–> Backup starts on Mon at 1am (UTC) --> Weekday = run
Exactly, this has to do with the function that checks it the day is allowed. It checks the day on UTC time and not local time. It should be fixed on the next canary if @kenkendk decides to merge my PR.