How to make Duplicati scheduled backups run reliably after wake from sleep (Windows workaround)

How-To
1

Hi all,

I struggled for a while with scheduled backups not starting after the PC wakes up from sleep/hibernation.
The root cause is that Duplicati relies on .NET PowerModeChanged events, and these are not always triggered on automatic wake (only reliably when a user actively resumes the session). As a result, the internal scheduler sometimes “misses” its backup slot.

Workaround using Windows Task Scheduler

I solved it by creating a simple Task Scheduler job that runs at the same time as my nightly backup (01:00).
The job runs under the SYSTEM account and is configured with Wake the computer to run this task.
Its only action is a small batch script:

timeout /t 60 /nobreak
"C:\Program Files\Duplicati 2\Duplicati.CommandLine.ServerUtil.exe" resume
timeout /t 120 /nobreak

Why this works

  • timeout /t 60 → gives Windows and the network some time to stabilize after wake.

  • ServerUtil.exe resume → unpauses the Duplicati service and makes the scheduler re-check jobs. If the backup was due while the PC was asleep, it runs immediately.

  • timeout /t 120 → keeps the task alive a bit longer, so Windows won’t put the PC back to sleep before the backup actually starts.

Result

Since adding this Task, my nightly backup jobs run reliably, even if the PC was asleep beforehand.
No more missed backups due to sleep/hibernate!

2

Hi @mezcalf, welcome to the forum :waving_hand:

That is a great discovery, and explains why it would not resume automatically.

I think we should fix this, but until then, happy that there is a workaround!

3

One downside of running the schedule on any wake is Windows’ built-in wakes such as

image

which runs briefly 3 A.M. to do things like below. I’m not sure I want backup started too, although I have another vendor’s program that starts but often can’t finish before sleep:

image
image689×174 5.93 KB

4

I have made a PR that changes the way PowerMode events are detected:

The new method uses a hidden window to obtain a message pump and then listen to messages from that. According to the MSDN documentation, this is the right way to do it, and should not result in lost messages.

For testing purposes, it is possible to switch between the previous .NET based power-mode provider and the new native one. It is also possible to set it to None, which will disable the power mode detection.