error 0x80070005 on scheduled backups


Author
Message
Big Dawg
Big Dawg
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 15
I've been using Macrium for years to backup my system. Everything has gone well until this past week. I noticed that my scheduled backups were not running. When I went into Macrium to look at my scheduled backups I saw the above error. Thinking that somehow my backup definition files were corrupted I tried rebuilding them. After a number of attempts to recreate the scheduled backups with no luck, I decided to upgrade from ver. 5 to the latest version 7 thinking that would solve the problem...but it didn't.
I can run a manual backup with no issues, but cannot create a scheduled backup that will run any longer.
My hunch is that a windows update may have created this problem. Obviously, it's only a hunch. 
Has anyone seen this error and how do I fix it?
I run Windows 7 Ultimate 64 bit.
BD

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
It sounds like you only tried deleting and recreating your definition file and scheduled task entries before upgrading to V7, is that correct?  If so, try doing that again now after you've upgraded. Scheduled tasks created by V7 use a newer version of the Windows Task Scheduler API and may therefore yield different results.  Technically you could probably get away with just deleting any schedules in your definition file, saving the changes, and then recreating the schedules (i.e. keeping the rest of the definition file intact), but if it's not too much trouble, it may be worth building a new definition file from scratch at this point anyway since you've moved up two major releases.

If that doesn't fix it, is the error code you posted shown in the log of the failed jobs (found under the Log tab) or in the "Last Result" field of the scheduled task (found under the Scheduled Backups tab all the way on the right of the Reflect window)?  If the latter, sometimes there's an actual description of the error rather than just an error code in that field -- any luck?  If not, is there anything more descriptive in the job log?

Additionally, since you mentioned you can run a manual backup successfully, how exactly are you doing that?  Are you stepping through the entire wizard manually, or right-clicking the definition file (Backup Definition Files tab) and clicking Run Now, or right-clicking the scheduled task (Scheduled Backups tab) and clicking Run Now?  The first two should be equivalent, but manually launching the scheduled task works a bit differently and more accurately simulates the conditions of a true scheduled backup, so you may get different results there.

Edited 9 January 2018 9:15 PM by jphughan
Big Dawg
Big Dawg
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 15
jphughan - 9 January 2018 9:07 PM
It sounds like you only tried deleting and recreating your definition file and scheduled task entries before upgrading to V7, is that correct?  If so, try doing that again now after you've upgraded. Scheduled tasks created by V7 use a newer version of the Windows Task Scheduler API and may therefore yield different results.  Technically you could probably get away with just deleting any schedules in your definition file, saving the changes, and then recreating the schedules (i.e. keeping the rest of the definition file intact), but if it's not too much trouble, it may be worth building a new definition file from scratch at this point anyway since you've moved up two major releases.

If that doesn't fix it, is the error code you posted shown in the log of the failed jobs (found under the Log tab) or in the "Last Result" field of the scheduled task (found under the Scheduled Backups tab all the way on the right of the Reflect window)?  If the latter, sometimes there's an actual description of the error rather than just an error code in that field -- any luck?  If not, is there anything more descriptive in the job log?

Additionally, since you mentioned you can run a manual backup successfully, how exactly are you doing that?  Are you stepping through the entire wizard manually, or right-clicking the definition file (Backup Definition Files tab) and clicking Run Now, or right-clicking the scheduled task (Scheduled Backups tab) and clicking Run Now?  The first two should be equivalent, but manually launching the scheduled task works a bit differently and more accurately simulates the conditions of a true scheduled backup, so you may get different results there.

Jphughan:
Thanks for getting back to me so quickly.
To answer your questions:
Yes, I deleted and recreated the definitions in ver 5 with no luck and then created new definitions in ver 7 with no luck.
The error code was only shown in the "last Result" field. Although I may have missed it in the logs but I saw nothing in the log files. And no I've found nothing more descriptive.
As far as a manual backup, I've done it by stepping through the entire wizard as well as right-clicking the definition file under the backup definition files tab. However, if I try to right-click the scheduled backup and click run now...it fails with the error code.
So something has changed and I don't know what.
Your help is appreciated.
BD

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
Is any job log at all generated for the attempts that throw this error?  If so, errors are typically listed at the very bottom of the log (the one viewed by clicking the timestamp, not the VSS log underneath it).  Is there anything useful in that log, or is it just a repeat of that same error code?

A quick Google of Task Scheduler error code 0x80070005 indicates that it means "Access denied", so if that's accurate for this situation, the next important question is: Where are you storing these backups, i.e. on a local drive or a network location?  And did this breakage perhaps coincide with you changing a password, such as your Windows logon password or (if using a network location) the account credentials for a network share?

V5 and V6 required that administrative credentials be stored to execute scheduled tasks, so if you changed the password of the account you were using for scheduled tasks, they would all break, regardless of the destination -- but manually executed tasks launched using the first two methods I mentioned above could still work because they always use the credentials of the logged on user.  However, V7 now supports using the SYSTEM account for scheduled tasks, so you can fix this in a way that prevents it from recurring.  Go to Other Tasks > Edit Defaults > Schedule and make sure the "Use the Windows SYSTEM account" checkbox is checked.  It is by default on new installations, but I'm not sure about upgrade installations, since that didn't exist in V5 or even V6.  Then try a launching a manual backup from the Scheduled Backups tab.  If it still fails:

- If you're backing up to a local drive, please navigate to the folder where you're storing backups, right-click it, select Properties > Security > Advanced and capture a screenshot of the Permissions tab.

- If you're backing up to a network location, then the above change would still be useful to make, but you'd also then have to provide credentials appropriate to access the network location under the Network heading of the Edit Defaults interface, since the SYSTEM account under which the scheduled tasks now run would not have any network privileges. Under previous versions that used an actual Windows account, it was possible for that single account to have privileges both to run the scheduled task AND access the required network target.  I can provide more detailed guidance on that front if needed.

Edited 9 January 2018 10:24 PM by jphughan
Big Dawg
Big Dawg
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 15
jphughan - 9 January 2018 10:03 PM
Is any job log at all generated for the attempts that throw this error?  If so, errors are typically listed at the very bottom of the log (the one viewed by clicking the timestamp, not the VSS log underneath it).  Is there anything useful in that log, or is it just a repeat of that same error code?

A quick Google of Task Scheduler error code 0x80070005 indicates that it means "Access denied", so if that's accurate for this situation, the next important question is: Where are you storing these backups, i.e. on a local drive or a network location?  And did this breakage perhaps coincide with you changing a password, perhaps your Windows logon password or (if using a network location) the account credentials for a network share?

If you're backing up to a local drive, V5 and V6 required scheduled tasks to maintain stored credentials just to execute the task, so if you changed that account's password, tasks would break.  However, V7 now supports using the SYSTEM account for backups, so you can fix this in a way that prevents it from recurring.  Go to Other Tasks > Edit Defaults > Schedule and make sure the "Use the Windows SYSTEM account" checkbox is checked.  It is by default on new installations, but I'm not sure about upgrade installations, since that didn't exist in V5 or even V6.  If it still fails, please navigate to the folder where you're storing backups, right-click it, select Properties > Security > Advanced and capture a screenshot of the Permissions tab.

If you're backing up to a network location, let me know and I'll provide guidance for that.

I've checked the log files but there is nothing in them related to this error and no log seems to be generated because of this error.
I have always backed up my image files to connected hard drives to my PC.  One external and one internal hard drive. No network drive.
I have not changed any Windows login password or any account password. And yes, I noticed that Ver 7 uses System account and yes it is checked as the default.
Here is a screenshot of the two properties you wanted me to capture.

Big Dawg
Big Dawg
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 15
jphughan - 9 January 2018 10:03 PM
Is any job log at all generated for the attempts that throw this error?  If so, errors are typically listed at the very bottom of the log (the one viewed by clicking the timestamp, not the VSS log underneath it).  Is there anything useful in that log, or is it just a repeat of that same error code?

A quick Google of Task Scheduler error code 0x80070005 indicates that it means "Access denied", so if that's accurate for this situation, the next important question is: Where are you storing these backups, i.e. on a local drive or a network location?  And did this breakage perhaps coincide with you changing a password, such as your Windows logon password or (if using a network location) the account credentials for a network share?

V5 and V6 required that administrative credentials be stored to execute scheduled tasks, so if you changed the password of the account you were using for scheduled tasks, they would all break, regardless of the destination -- but manually executed tasks launched using the first two methods I mentioned above could still work because they always use the credentials of the logged on user.  However, V7 now supports using the SYSTEM account for scheduled tasks, so you can fix this in a way that prevents it from recurring.  Go to Other Tasks > Edit Defaults > Schedule and make sure the "Use the Windows SYSTEM account" checkbox is checked.  It is by default on new installations, but I'm not sure about upgrade installations, since that didn't exist in V5 or even V6.  Then try a launching a manual backup from the Scheduled Backups tab.  If it still fails:

- If you're backing up to a local drive, please navigate to the folder where you're storing backups, right-click it, select Properties > Security > Advanced and capture a screenshot of the Permissions tab.

- If you're backing up to a network location, then the above change would still be useful to make, but you'd also then have to provide credentials appropriate to access the network location under the Network heading of the Edit Defaults interface, since the SYSTEM account under which the scheduled tasks now run would not have any network privileges. Under previous versions that used an actual Windows account, it was possible for that single account to have privileges both to run the scheduled task AND access the required network target.  I can provide more detailed guidance on that front if needed.


Attachments
folder properties.pdf (2 views, 69.00 KB)
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
And unrelated to troubleshooting this particular issue, before I forget, since you've just moved from V5 to V7, pay special attention your retention policy settings.  The retention policy engine changed significantly from V5 to V6 and was carried over to V7.  It offers some interesting new capabilities (Incremental Merge, Synthetic Fulls, generally more flexible/granular management of backup retention), but one critical change is in the way backups are counted.  Under V5, the current backup set was not counted when evaluating the backups to purge.  In V6, the current backup set is counted.  So let's say you had a retention policy of 1 Full and had "Run purge before backup" enabled, then you ran a Full backup.  In V5, all but the most recent Full would be purged upfront (leaving 1 Full), and then the new Full would be created, leaving you with 2 Fulls at the end. Under V6, this same policy would cause all existing backups to be deleted before the new backup even runs, so that at the end of that job, you only had 1 Full as your retention policy specifies.  Of course having 1 Full at the end assumes that the job completed successfully, otherwise you'd be left with nothing, and therein lies the risk of a policy like I've just described.  So again, just make sure your retention policy still works the way you want.  At the very least you may want to increase your retention settings by 1 to take this different counting mechanism into account.

Edited 9 January 2018 10:37 PM by jphughan
jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
Ok, those screenshots indicate that the SYSTEM account has Full Control to those folders, which is as it should be.  In that case, was that checkbox to use the SYSTEM account already checked when you looked at it, or did you have to enable it?  If the former, I'm not sure what to check next; this might be worth opening a support ticket with Macrium.  If you DID have to enable that, I think Reflect updates any existing scheduled tasks to use the new user account when changes are made there, but just in case that didn't work as expected, try once more editing your definition file to remove any schedules, clicking OK to save the changes (check that the Scheduled Backups tab is now empty), then edit your definition file again to recreate the schedules, and once again try a manual backup under the Scheduled Backups tab.

Edited 9 January 2018 10:42 PM by jphughan
Big Dawg
Big Dawg
New Member
New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)New Member (11 reputation)
Group: Forum Members
Posts: 10, Visits: 15
jphughan - 9 January 2018 10:42 PM
Ok, those screenshots indicate that the SYSTEM account has Full Control to those folders, which is as it should be.  In that case, was that checkbox to use the SYSTEM account already checked when you looked at it, or did you have to enable it?  If the former, I'm not sure what to check next; this might be worth opening a support ticket with Macrium.  If you DID have to enable that, I think Reflect updates any existing scheduled tasks to use the new user account when changes are made there, but just in case that didn't work as expected, try once more editing your definition file to remove any schedules, clicking OK to save the changes (check that the Scheduled Backups tab is now empty), then edit your definition file again to recreate the schedules, and once again try a manual backup under the Scheduled Backups tab.

As far as retention...I set the two backups (I think) to retain the last 5 for Drive G and the last 10 for Drive M with purging the oldest AFTER the backup image is created.
The System account setting was already there by default. I didn't have to check it.
Now the real problem is I'm running the Free version so I wasn't aware I could open a support ticket.

jphughan
jphughan
Most Valuable Professional
Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)Most Valuable Professional (4.7K reputation)
Group: Forum Members
Posts: 3.3K, Visits: 24K
Ah ok.  I figured you were on a paid installation since having a forum account here requires you to have a paid license, but then again I know some people have a mixture of paid and free installations for their purposes.  Well even if you can't submit a support ticket, you can still email support where the Free version gets best effort support, although seeing as you already have a thread going, Macrium reps may be along to assist shortly anyway -- but they're based in the UK, so it may not be until tomorrow at this point.

But to sum up:
- The SYSTEM account was already being used for scheduled backups.
- You're backing up to local (directly attached) hard drives, both of which have correct permissions for the SYSTEM account.
- Backups launched manually from the Backup Definition Files tab work.
- Backups launched manually from the Scheduled Backups tab, as well as backups actually attempted on the specified schedule, consistently fail.

And no job logs are created at all for the jobs that fail?  That's probably the strangest part to me.  Any third-party anti-virus on this system that may be blocking Reflect from launching a task via Task Scheduler?

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search