Direkt zum Inhalt

Backup plan not working anymore after setting password for user account

Thread needs solution

Hi @ll!

I've installed ATI2016 on one of my machines (Win7) for a nightly backup which worked flawlessly so far! :)

That means the PC switched on at night; backup was started soon after that and PC was shutdown automatically.
Since yesterday I was the only user on that machine so I didn't have to login after startup.

Now I have set a password so I have to provide login data everytime I switch on the PC... nothing unusual.
However ATI didn't execute the backup last night...

What do I have to change to make ATI work with a password protected machine?

 

Thanks!

 

0 Users found this helpful

FW, welcome to these user forums.

Was ATIH 2016 installed and being run under an Administrative account?

I would suggest setting up a new backup task now that you have your account with a password and test that this works correctly.  If needed keep the backup very simple for the purpose of the test, i.e. select just a single folder to be backed up.

If you reboot and do not login, several backgroudn services may not start on their own and scheduled tasks may not run either (if they were created with a parituclar account and only run when that account is logged in).

I would recommend you log in after reboot and just lock the computer with a quick Winkey+L.  Without that iniitial login, it probably just won't work.  I don't how Acronis handles the scheduling, but other backup products create scheduled tasks and those also only run when a user is logged in as well. 

Steve Smith wrote:
Was ATIH 2016 installed and being run under an Administrative account?

I would suggest setting up a new backup task now that you have your account with a password and test that this works correctly.  If needed keep the backup very simple for the purpose of the test, i.e. select just a single folder to be backed up.

Yes... it was run under an administrator account before. That means: It's still an admin account but now with password.

I thought there's an option to set the account+password on an existing backup plan somewhere but just was too
blind to see it!?

F.W. I canot find any place in the ATIH task configuration settings, nor is the underlying script (.TIS) file where your account password would be stored - the only settings related to passwords is in the archive protection (in the Advanced settings tab) but this is for the encryption of the backup file and can only be set when a new task is created - once the task has run, that password cannot be changed.

Ditto to Steve's last note.

Have you tried logging into the system and locking it and then seeing if the backup runs after that?  There are other issues that can prevent a backup from running after hours - coincidence, possibly - you'd be suprised...

Fastboot/fast startup can be an issue for some

Pending Windows updates/software installations that need reboots.

Windows "upgrade" with Windows 10 that changes Windows settings that were different in the previous build

Power settings of a device  where it may have been in a higher sleep state or hibernation state (commond if hybrid sleep or hibernation is enabled)

Verify that the backup drive still has the same drive letter the backup task was created with - for testing, reconfigure your backup by re-picking the source and destination and running it right after - does it run then?  If so, now let it try to run at the scheduled time.

Acronis logs may point you in the right direction or at least shed some more light.  Links for the logviewer are in Steve and my comments - grab it and check some of the service logs and/or post them here for additional review.  Do they show any signs of trouble - were logs even created (if not, the system may not have even tried to backup).

Perhaps adding a password to the accoutn did cause an issue - it shouldn't since acronis runs under the local system account, but let's assuem it did.  Have you tried to run a "repair" install with the current Acronis installer (right-click and run as admin to ensure the highest privileges) and let it repair the install while under the admin account with the new password - if it is Windows password related (although I'm not sure how it would be), this should theoretically fix that.