Skip to main content

Computer sleeps between backup jobs

Thread solved

PC running Windows 11. About 10 backup jobs run every night — 5 to NAS and 5 to cloud. I have a task scheduled that wakes the computer up just before the backup jobs are scheduled to start. I did this because the "wake computer" option wasn't working consistently. This part all works fine.

The computer is set to sleep after 30 minutes. What I'm finding is, if the backup jobs run longer than 30 minutes in total, the computer will sleep between the time that one job ends and the next in the queue starts. For example, if jobs A, B, C, D, and E are scheduled and are queued up, and jobs A and B together run longer than 30 minutes, the computer will sleep before job C fires. In the morning, when I wake the computer up again jobs C, D, and E will complete.

I have the "keep computer awake" option checked on all of the jobs. But apparently that's only active per job and ends when the job ends. Is there some way to set a universal "keep computer awake" until all of the jobs are finished? I don't really want to make the time to sleep longer. It used to work with Windows 10. I only notice this problem since I updated to Windows 11.

0 Users found this helpful

This is not an issue I have seen mentioned previously in the forums but my initial thoughts would be to use a Post Command for your backup tasks to change your sleep time while there are still further tasks to run, then revert it back to your normal 30 minutes in the final task.

POWERCFG /Change standby-timeout-ac 60

POWERCFG /Change standby-timeout-ac 30

See webpage How to use powercfg to control power settings on Windows 10 for more details of using this command.

Note: it may be easiest to put the above commands in small .BAT files i.e. Sleep60.BAT & Sleep30.BAT to use in your task Post Commands.

Thanks for your response. I do seem to find the odd issues that nobody else ever does... 

I realized that I had the jobs scheduled rather far apart. I think that's what's allowing the computer to sleep between jobs — there are no jobs queued because of the schedule spread. I've changed the scheduling so they should all fire off well within the 30 minutes that the computer is awake. I'm thinking that if the jobs have started and are queued, the computer will realize that it's busy. 

I'm going to monitor that for a few days and see what happens. If that doesn't work, I'll play around with powercfg.

 

Have you considered starting all the backup jobs together? The scheduler will take care of queuing them all. You may need to consider if there is any sequence that is required and account for that with small differences in the start time.

To Steve suggestion, rather than set the times I would create a power scheme for when backups are running (to not sleep at all) and then switch back to the normal scheme at the end of the last backup.

Yesterday I changed the backups so that they are scheduled to run 1 minute apart in the order I want them to run. That seemed to work just fine. Every job completed. They were all incremental backups, though, and didn't take much time. I'm going to try this scheme for a week — which should hit all of the jobs that do a full backup — and then evaluate whether I need to use powercfg. 

I thought I'd update this in case anyone else also runs into it.

To recap:

- I have 9 backup jobs that run nightly: First 5 jobs back up to NAS and then 4 jobs back up to the Acronis cloud.

- Under Windows 10, everything worked as expected. The PC woke up when it was time to start the backups, all of the backups ran, and the computer went to sleep again when they were all finished.

- After upgrading the PC to Windows 11 the computer would only sporadically wake up when the backups were scheduled. To fix this problem I created a scheduled task that wakes the computer up just before the backups are scheduled. That shouldn't be necessary — all of the jobs have "wake up the computer" selected — but it is working.

- The PC's power mode has the computer go back to sleep after 30 minutes. If the backup jobs ran longer than 30 minutes, the PC would sleep and any subsequent jobs would not run.

- I tried scheduling the jobs at 1-minute intervals, assuming that queued jobs would run. This did not work. Queued jobs were ignored and the PC went to sleep. (Queued jobs would fire off immediately in the morning when I woke the computer up.)

- I added a powercfg pre-task to the first scheduled backup job that sets the power mode to "always on." Apparently pre- and post-tasks are not available in cloud jobs. I moved one of the NAS jobs to be last scheduled and added a post-task powercfg to change the power mode back to "balanced." This has been working as intended: the PC wakes up, all of the jobs run, and the PC goes back to sleep. (Note I decided on changing the power mode vs increasing the sleep time because this way I don't have to guess how long it needs to be.)

This seems like a bit of a hassle to go through to get something working that used to be just fine. Maybe it will be fixed in a subsequent release. But for now it's working and I don't think it's worth entering a support ticket for, especially since I appear to be the only one having this problem.

Thanks again for the suggestions!

Glad to hear you got it working, albeit in a rather convoluted way.

These kinds of issues pop up and sometimes it is nearly impossible to say why. I had a similar issue some years back, with ATI 2017 I believe. I also had a nagging issue that showed up in ATI 2019 that I spent a year trying to figure out. I gave up trying to figure out what the bug was... I just wanted to figure out how to avoid triggering it. I ended up starting my jobs with a scheduled task and not using the Acronis scheduler. The Schedul2 logs may provide some insight, but maybe not enough to really nail it.

Perhaps best to stick with the current solution if it works reliably.

 

BrunoC wrote:

Perhaps best to stick with the current solution if it works reliably.

I'm  of the opinion that "if it ain't broke, don't fix it." I'm not sure that I care enough to dig around in the log files, etc. If it breaks again then I might take a harder look. But for now this appears to be a workable solution.