Skip to main content

Error Codes and Descriptions

Thread needs solution

I give. Has anyone else noticed (or complained) about how horrid the errors are in Acronis? None of them make any sense. There isn't just one specific error that is easy to understand there are always 5 or 6 errors and none of them make any sense. Then... if you click on the option to find the error on Acronis's web site it never finds it or displays anything. It reminds me a lot of Veritas Backup Exec. "There was an error. You figure it out.".

How do other people make heads or tail out of errors and is Acronis ever going to make them user friendly?

0 Users found this helpful

Hello Jim,

Thank you for your feedback. We are aware of this problem and are working on more meaningful errors. You can see some of these improvement in Acronis Backup Cloud and this functionality will be fully transformed to provide user-friendly errors by Acronis Backup 12.

However, in the meantime, the following information might help:

The errors are hierarchical, meaning that the top error message in the log error stack comes from the highest placed component. Usually this is the backup task itself and it will say something not very useful, like "backup failed". However, this failure was caused by some smaller part of the backup task, which is the next error you see. This continues until the specific (usually) very small component is reached. Something like the component that checks credentials to a remote location when connecting to a NAS. This is the component that encountered the specific problem that then caused the higher up dependent components to also fail.

So in my example of checking credentials, you might get an "access denied" because the password has changed on the NAS. Since we don't have access, the higher component that looks for archives on the location would also fail, but the error would be "can't find backup", which would be followed by a "can't open location" by the component that opens network shares and so on.

This chain of errors was originally designed this way because it gives a good snapshot of what the product was doing in the different modules at the time the error happened, but does make for more complex troubleshooting if you don't have experience with the errors.

So, generally, you want to look at the very last error message in the error stack for the true cause of the different problems.

I say generally because, in some cases, the lowest level error is actually returned from the OS. This happens when the failing component is outside the product. For example, if our product makes a call to VSS and the VSS functionality fails, the lowest error message in our logs can actually be a Windows error.