Error E00070020

Discussion in 'Acronis True Image Product Line' started by jaydio, Mar 18, 2009.

Thread Status:
Not open for further replies.
  1. jaydio

    jaydio Registered Member

    Joined:
    Mar 18, 2009
    Posts:
    3
    I'd like to share my experience with the E00070020 error. I have True Image Home 11 and keep an incremental backup on an external USB hard disk of my entire PC. A few days ago I wondered about the health of such backup (now in the 300Gb range) and did a "Validate Backup", which ended with the well known (across the internet and in this forum) error E00070020. I immediately did a checkdisk and the memory error testing advised in the forum on each post where the error occurs. No memory or disk errors.

    Suspecting from some of the forum posts and other internet research that it could be related with the USB interface I took the SATA hard-disk from inside its case in the external USB drive and connected it directly to the motherboard via a SATA connector. Ran the "Validate" and it now validated fine, no errors whatsoever.

    What bothers me most is not the error itself, it's the way it has been systematically unacknowledged and it could be said even hidden by Acronis (try searching for E00070020 in the support section). Since Acronis is not exactly a bunch of amateurs one can suspect a scenario like that they cannot fix the error maybe because it's outside their product, say in Windows itself. Makes some sense, huh?

    The problem is that trying to ignore an error like this is not going to make it go away. It must be said that the handling of this problem has been a blunder and a lack of honesty which is costing many people a lot of time and money and which, if you keep handling it this way, may cost you your business.

    - Deal with the people that purchased your software in a decent manner Acronis!

    "Compute with confidence"?

    Cordially,

    Jay Dio
     
  2. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Hello jaydio,

    Thank you for your interesting in Acronis True Image

    Thank you very much for your useful experience share concerning “backup archive corrupt” error message. Thank you for taking time to contact us concerning this issue and providing resolution.

    Best regards,
    --
    Dmitry Nikolaev
     
  3. jaydio

    jaydio Registered Member

    Joined:
    Mar 18, 2009
    Posts:
    3
    Hi Dmitry/Acronis Support,

    Thank you for your "automated" copy+paste answer. You have nothing the thank me for, as this is unfortunately not a solution to True Image's error. It was a desperate try to save years of backups which I was very lucky not to loose. All I can do is wish good luck to people facing this problem.

    Handling E00070020 with vacant "thank you" messages is not going to solve it.

    Cordially,

    Jay Dio
     
  4. seekforever

    seekforever Registered Member

    Joined:
    Oct 31, 2005
    Posts:
    4,751
    I agree that Acronis is far from perfect in providing easy to find info on problems and searching on the error message should have provided results. However, Acronis does have a document on "corrupt archives" whose diagnostic flow sheet indicates to try and validate an archive stored on an internal drive and if that works a possible cause, among others, is USB drivers. Effectively, this is what you did. How easy it is to find that document by searching their knowlege base, I don't know.

    Of course, the TI software can be problematic but the common reason for the error you describe is a hardware deficiency, especially when running in Windows. The validation routine is not magic, all it does is open the archive file(s), reads them into memory, recalculates the 4000 checksums/GB, and compares them with the original one stored in the archive when it was created. If one bit is bad in a single checksum the entire archive is declared corrupt. As you can see, anything that causes the archive to be incorrectly read or stored in RAM for the calculation will trigger the error. Although it seems USB drives are generally better now, not so long ago, many of the chipsets did not play nice together and a common problem was handling very large files which archive files tend to be. Also, the very large volumes of data transferred at high-speed will sometimes show up problems that normal accesses don't.

    Have you validated using the TI rescue CD? This environment is Linux, not Windows, and there can be driver issues especially with newer hardware. It is important that you can validate with the CD because this is the environment that is used if you ever have to restore the active partition, typically C.

    If your sole backup is a single collection of incrementals totalling 300GB and consists of a full and a very long chain of incrementals, I recommend you make another full and restart the incremental chain. It is always good to have more than one archive and should a single incremental go bad in the chain then the data from that incremental and any one after it is lost.
     
  5. jaydio

    jaydio Registered Member

    Joined:
    Mar 18, 2009
    Posts:
    3
    This definitely must be related with USB hardware since the same exact disk validated fine when skipping the USB bus, going via SATA. Also, I did test via the Linux rescue CD with the same error. After going via SATA it now validates well in both Linux rescue disk and in Windows.

    However my point is that Acronis should deal with this error, either having some sort of "safe validate" possibly accessing the USB disk in smaller chunks or slower - or some other way. I've been using this same hard disk via USB without problems for over a year without problems, including the usage of large video files, so it must be possible to access large files without problems even in external USB disk drives.

    Or at the very least Acronis should explicitly have this error on they Knowledge Base or it will always appear they have something to hide.

    Seekforever - thank for your considerate post,

    Jay Dio
     
  6. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Hello jaydio,

    Thank you for using Acronis True Image

    You can easily find the appropriate article in Acronis Knowledge base.

    Key words: corrupt backup

    Thank you.

    --
    Oleg Lee
     
  7. seekforever

    seekforever Registered Member

    Joined:
    Oct 31, 2005
    Posts:
    4,751
    Hi Oleg,
    While "corrupt image" easily finds the document, I think giving any error number listed by TI should also find the correct documents.

    There should also be a listing of the error numbers and their probable causes in the User Guide, perhaps in an appendix.
     
  8. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Hello seekforever,

    Thank you for your feedback.

    As far as I know, we created a list of the main errors and wanted to publish it. I will create a request to figure out the current state of this task.

    Thank you.

    --
    Oleg Lee
     
  9. Kwestionmark

    Kwestionmark Registered Member

    Joined:
    Jul 8, 2009
    Posts:
    3
    Location:
    Munich, Germany
    Re: Error E00070020 Computing with confidence?

    Hi all,
    after 5 hrs of backing up (TI11) my EEE-PC onto an external HD (USB), the validation program came up with the dreaded E00070020 error.
    So I went through the routine of googling and searching this forum, chatting with Acronis etc, in short: I did my homework.

    Some forum members with the E00070020 issue could show, that if an external drive is connected via SATA or internally, the TI archive validation is OK. Apparently, it's a problem with USB and external drives. Well, my notebook has only USB and Ethernet, but, to be honest, I want to use USB only. From my point of view, Acronis must warn their customers, that the backup via external USB drives is unreliable. Or they should test this feature more thourougly before they release the software. USB really is not so new anymore.

    Since there is seemingly no solution, I' about to quit using TI for good, having lost my confidence in this company and its products.

    The Acronis advice to „copy the corrupt backup archive to the internal hard disk drive (if the backup is on an external resource/media)“ is not useful for me since I am backing up the entire hard drive of my notebook onto an external USB-drive (where else?)

    The other advice to „mount or explore the backup archive and try to restore files or folders from it“ is also not useful, as I wish to have a validated and reliable image of the notebook’s entire hard drive – I want to ‚compute with confidence’.

    When I follow the Acronis scheme to ‚Troubleshooting issues with corrupt backups’ on http://www.acronis.com/r/support/en/kb/254/troubleshoot.corrupt.htm, I end up with the info that I must be having defective hardware:

    1 Testing memory modules (and drives) > OK, no problems reported
    2 Saving backups to internal hd > Impossible: Why should I back up onto a drive which I'm backing up??
    3 Try creating a backup in Windows > Absurd: I’m using the TI Bootable Media and I don’t want to install TI on the notebook which I’m backing up.
    4 Hardware problem? Certainly not. All connected devices are OK.


    Acronis developers, please be honest: You must have been aware of this issue.
    Has this USB-External drive-issue been dealt with in the latest release or not?

    If so, we all here would gladly read some details.

    Thank you very much
    Kwestionmark
     
  10. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Re: Error E00070020 Computing with confidence?

    Hello Kwestionmark,

    Thank you for your detailed description.

    We would inform you that we do not have any common issues when our software itself makes backup corrupted. The most cases the reason is hardware\connection.

    1. It means that your RAM is good, but we are aware of some cases when memtest does not detect corruption when it exist.

    2. You were asked to do in order to exclude USB connector issue. Personally, I've suggested this thing to each case of backup corruption related to external\network drives, and that helped in many cases

    3. Absolutely correct suggestion. We have two environments: Linux for CD versions and Windows for basic ones. If one case reveals corruption, there's a possibility that issue is related to environment itself. So probably you will not receive the same corruption under Windows.

    We are aware of this issue. And backup corruption cases were escalated to testers and developers many times. The issue with software itself was not detected. If you feel that your case is the special one, please contact us and give us a chance to investigate it.

    Feel free submit a request for technical support. Attach all the collected files and information to your request along with the step-by-step description of the actions taken before the issue appears and the link to this thread. We will do our best to investigate the problem and provide you with a solution.

    Thank you.
    --
    Alexander Nikolsky
     
  11. Kwestionmark

    Kwestionmark Registered Member

    Joined:
    Jul 8, 2009
    Posts:
    3
    Location:
    Munich, Germany
    Thank you, Mr. Nikolsky, for your reply.
    I wanted to let you know that I could successfully access the TIB (the one that failed to validate). I didn't copy the TIB anywhere; I simply doubleclicked it in an explorer window after having connected the external drive to a different computer which has TI11 installed.

    I then tried to verify this archive again using the TI Windows installation (rightclick the TIB -> validate backup archive) - and it failed again:

    "Image corrupted (0x70020)
    Tag=0xF5F8CBCF76155638Aktion mit der Partition "0-0" wurde abgebrochen"

    Simply accessing files inside the TIB is not what I really had in mind.

    All I want is to have a valid, verified, trustworthy image of my HD, in order to restore the entire HD with all its partitions in one go. I do not want to spend my afternoons nerding my way through user forums and typing complaints.

    Now what do you suggest should I do in case I tried to recover my HD with an unverified TIB, and in the middle of this, TI comes up with Error E00070020 again, leaving me with a corrupted HD and a corrupted TIB.

    Can you understand why I can't 'compute with confidence' anymore?
    Some TIBs verify with no problems. I always use USB-drives. That's the depressing part of this issue.

    If my hardware (USB chipsets, RAM modules etc.) were really defective, wouldn't I then permanently encounter blue screens, copy errors and similar problems, when simply copying a file from one drive to another?

    My question was, if this issue is recognized by Acronis: Has this been dealt with in the latest release? Or maybe it is your validation tool, that is defective?

    Please forgive me for not trying out this unverified TIB on my PC ...

    Best regards,
    Mark
     
  12. seekforever

    seekforever Registered Member

    Joined:
    Oct 31, 2005
    Posts:
    4,751
    In case you haven't really abandoned TI you can consider this:

    The design of a typical PC is such that the hardware is assumed to be working. There is no checking of data into or out of RAM, HDs use a CRC that ensures that data as read off the platter is correct but does not guarantee that it is read from the HD connector into RAM correctly. Most files handled in typical PC operation are small compared to tib files and there were many known cases of USB chipsets not playing nice together (PC's and USB drive's) particularly with large file transfers. I would say that if the hardware is recently purchased the chipset issue is likely corrected but... . Whether you get BSODs depends on what the hardware issue is. If it is RAM it depends on what is loaded into that location and what the corrupted data causes the PC to do. A bad bit in a jpg file will likely not be noticed a bad bit in an execution instruction could cause a BSOD or some other quirk.

    The TI valdiation process is an internal consistency check. When the archive is created it writes 4000 checksums/GB of data into the archive file. When it is validated, the file is read into RAM and the checksums recomputed and compared to the ones placed in the archive when it was written. If there is only one bad bit in the multi-GB file it will declare the archive as corrupt. I doubt if there is any other typical program that puts this stringent a test on data as written into RAM. Most people hardly ever really flog all the RAM on their machines these days other than the fact Windows rotates things around RAM.

    What this means is that the validation is a stringent read test of your hardware and RAM and not much more. The archive itself can be bad if there was a hardware error when it was written - the case where the data was read from the HD correctly, processed correctly but got screwed up in the write process to the USB drive for example.

    Alexander is correct, memory diagnostic programs may not detect marginal RAM errors or will detect them but only after running many hours. Running the PC with only a memory diagnostic running isn't exactly the same environment as running it with disks transferring data at a high-rate. If your PC has multiple sticks of RAM you can try running with only the minimum required for the hardware and then swapping them around. The PC should not be running with aggressive memory timings or overclocking which might be OK in normal applications.

    Doing a test with the tib written to the internal HD was also a very valid suggestion since internal HDs tend to be less problematic than any other device for saving an archive. Sure it isn't the place you want a real archive but it does help in troubleshooting the problem which boils down to a process of elimination. Same as the suggestion to try Windows although it is imperative that the Linux environment run but this would have been another clue to the problem. The Linux driver set may not be a good fit for your PC. Since you are using TI11, you could download the trial of TI2009 and make its recovery CD which will restore and validate existing archives. It may have a better driver if it is the issue.

    You can try the following, although it assumes your RAM and other hardware is working properly:

    Download a free checksum calculator. Try this one:
    http://www.irnis.net/soft/xcsc/

    Pick one of your large tib files and run the calculator and record the checksum. The MD5 is a good one and you probably only need the last 6 digits or so if you don't want to write it all down.
    Copy the tib file using Windows to your USB drive and run the checksum test again on the copied file. It must agree with the original value.
    If it does, copy it back to another location on the HD and run the checksum test on that file, again it must agree.

    Exploring the archive and extracting a few files is not a guarantee it will restore or validate. You are correct in not attempting a restore to your regular HD with an archive that won't validate which is why we recommend that a spare HD be used for a test of TI on a machine.
     
  13. Acronis Support

    Acronis Support Acronis Support Staff

    Joined:
    Apr 28, 2004
    Posts:
    25,885
    Hello Kwestionmark and seekforever,

    seekforever, thank you very much for clear and detailed explanation!

    Unfortunately, in most cases corrupted backup cannot be accessed and recovered at all. So the simplest suggestion is extract some useful files from your corrupted archive (you mentioned that you were able to Explore it) and investigate the issue with new backups to prevent constant corruption.

    Have you tried to create the same backup onto internal drive? Was it corrupted? If not, it means a possibility of single corruption, which can be caused by some connection dropout, writing failure or another glitch, such case cannot be investigated without reproduction.

    No, our validation tool is not defective, it has been tested and we haven't received any confirmation of issue.


    Thank you for your understanding.

    --
    Alexander Nikolsky
     
  14. Kwestionmark

    Kwestionmark Registered Member

    Joined:
    Jul 8, 2009
    Posts:
    3
    Location:
    Munich, Germany
    Hello Alexander and seekforever,
    thank you for your replies.
    I must say, that I am positively impressed by your helpfulness and speed of resonse.

    All the working around (RAM-testing, using different drives etc.) may help tracking the problems, but it doesn't give me the solution I need: Computing with confidence: Mirroring a notebook drive onto one of my external HDs without any hassle.
    Despite today's rainy weather I don't want to spend my leisure to carry out forensic works, just to find out that TI sometimes works and sometimes doesn't. I don't want to purchase new external drives, then spend 5 hrs waiting for the backup etc ... As I said, some TIBs (even large ones) verified OK, some didn't. I never tracked which drives I use (I have about 20 external drives).

    All I know is that my WinRar creates huge archives from HD to external drives without errors - unfortunately it doesn't mirror drives like TI ...

    The workaround for TI would be to invent a technology that checks and corrects errors on the fly rather than letting TI first build a 'successful' archive and then disqualifying it afterwards ...
    (I already lost a couple of archives because I did not bother verifying them afterwards)

    Let's see what the future has in store for us ...

    Cheers,
    Mark
     
  15. Xpilot

    Xpilot Registered Member

    Joined:
    May 14, 2005
    Posts:
    2,318
    I can ony comment from my own personal experience of using TI of several different Versions on PCs and laptops.

    I have had a very small number of corrupt archives. In every case I have been able to identify the problem as being caused by hardware faults. I have had no reason to suspect that the TI program was a contributory cause.
    I have been lucky with all my RAM modules never showed any errors when tested. It is possible that a TI archive will find a bad patch which other programs have never stressed.
    Failing hard drives have been a source of archive corruption. At the first sign of errors I run CHKDSK R and if any bad sectors are reported I will consider replacing the drive sooner rather than later.
    The majority of the corrupt archives I was able to tie down to poor physical electrical connections. One example was a HD ribbon connector which just needed reseating. Another was a poor 5.5V supply connector to a harddrive. A recent example happened when a dust bunny found its way into a removable drive backplane connector.
    There are of course other areas such as over heating or poor power supplies which could be a source difficulties.

    The above is a long winded way of saying that if your computer is capable of creating some good archives the corrupt ones are most likely to be hardware related. After running MemTest and CHKDSK R on all your partitions/drives the simple step of re-seating all the modules and connectors may well cure the corruption problems.

    Trouble shooting does require one to set aside time and then proceed methodically.

    Xpilot
     
Thread Status:
Not open for further replies.