Corrupt/Can't Verify Corrupt Archives: Let's uncover the problem!

Discussion in 'Acronis True Image Product Line' started by johnmeyer, Sep 11, 2007.

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

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    If you search this forum for the word "corrupt," you will get 1,000 hits (the maximum allowed by the search function). Trueimage is clearly the best backup software for Windows, but it may be the worst restore software, because of this bug. Obviously, backup without restore is like write-only memory: Not very useful.

    The purpose of this post is to collect, from all users, ideas and workarounds that can help avoid this problem, or can help deal with it once you are stuck trying to restore from an archive that is probably still OK, but which TrueImage is insisting on calling "corrupt."

    I'll start by sharing what I have learned, and then summarize at the end of the post what I recommend. If you respond to this thread, please try to limit those responses to things you have tried that worked, or seemed to work. There are lots of other threads where people bash Acronis. I'm trying to fix problems here, not pile on.

    Here is what I have learned from my own experience, and from reading dozens of those 1,000+ posts that mention the word "corrupt."

    1. Validating the backup at the time of the backup provides absolutely no assurance that you can use the backup. After first experiencing the "corrupt archive" problem earlier this summer, I then changed my backup practice so that I ALWAYS verify/validate the backup. However, when it came time to use the backup, the validate failed.

    2. Copying the backup from an external USB drive to an internal drive will often (but not always) cause it to validate correctly. I have over ten external USB drives, and this problem of failing validation on an external drive does not seem to be associated with any particular chipset. Also, I have tried this on my desktop computer as well as several laptops, and found the same problem, so I don't think it is associated with any USB chipset on the computer (all were from different vendors). Also, each computer had different versions of XP (Pro, Home, Media, with SP1 on some and SP2 on others). So, my preliminary conclusion is that USB support in TrueImage is flaky.

    What I cannot understand is how the image can validate correctly at the time of backup and then fail validation at a later time. Is there a date/time check of some sort that is failing? (I helped the Second Copy people track down something like this many years ago).

    3. Corollary to #2: Copying the TIB to a Firewire drive sometimes will make it validate correctly. I have a FAT32 formatted Firewire drive and was able to copy a "corrupt" TIB file from my USB drive to the Firewire drive. It validated just fine, and I was then able to restore my computer from this copy (this is how I finally solved my problem this morning).

    4. Bad memory is a red herring. Many responses from Acronis ask the user to test memory using Memtest86. I have done this and verified, of course, that my memory is just fine. I have an EE degree and have run three software companies. Believe me, if memory is flaky, you KNOW it, and it will show up, usually as crashes with BSOD, when running all sorts of programs. Also, I doubt that thousands of people are having memory problems that only show up with one application. I am certain that somewhere in the past few years, Acronis tech support did actually have a user with corrupt memory, but let's face it, all the corrupt memory computers didn't suddenly find there way to this one forum.

    Also, I defy anyone to find even one user in these forums that wrote back and said that their validation/corruption problem had been cured by changing memory. This, despite the fact that this suggestion is given in almost every post about this problem, and many of the poor users dutifully let memtest86 run overnight, and then report that they still have the problem.

    5. Backups which validate when using the Windows version of the software FAIL validation when trying to do a restore from the Acronis boot media. This is particularly nasty. This morning, while trying to restore my C: drive, I ran into all the problems already listed, but finally managed to get a reasonably recent image to validate. However, when I booted using the recovery media and ran the full version (not the safe version) of Acronis TrueImage, and I asked to restore the image, I chose to first validate the image file, and this validation failed.

    That validation failed, even though that exact same image, residing on that drive, had passed validation just minutes before, when validated from the main Windows version of TI.​

    I am using TI 9.0, build #3854, but based on posts in this forum and elsewhere on the Internet, version 10 doesn't seem to have fixed these fundamental problems.

    Unlike others, I have had a reasonably good experience with tech support, although they are extremely slow to respond, sometimes taking weeks. However, they really don't seem to be on top of this one, and it is going to ruin this product if it doesn't get fixed. Read the reviews on Amazon and elsewhere and you'll see what I mean.

    Acronis employees: If you want to still have a job, you've got to fix this!! This is the sort of thing that causes software companies to cease operations.

    My purpose in writing this post is to ask anyone if they have discovered a pattern to these problems so that we can try to develop some workarounds. Such workarounds often can help the vendor figure out a permanent solution to the problem. So far this is my one workaround:

    1. Copy the archive to another drive, preferably internal. Firewire also seems to work better, although my only Firewire is formatted with FAT32, so that may have something to do with it.

    So, does anyone else have something that has definitely worked, and is something they themselves have tested?
     
  2. captain_reef

    captain_reef Registered Member

    Joined:
    Sep 11, 2007
    Posts:
    1
    I have the identical problem and received identical suggestions from support.
    I wonder if you could be more specific on what worked for you. I believe you stated that the file was transfered to a disk formatted with FAT (32?) and then you booted with the rescue disk and that worked. If somthing other, appreciate clarification.
     
  3. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    Hello johnmeyer,

    Not at all!!

    Hmm, not sure what Keyword you used in your search but I only needed to go back over the past 9 months to find the evidence (believe me, there have been many more examples over the past few years):

    https://www.wilderssecurity.com/showthread.php?p=1022882
    https://www.wilderssecurity.com/showthread.php?p=920391
    https://www.wilderssecurity.com/showthread.php?p=898828

    Regards

    Menorcaman
     
  4. Xpilot

    Xpilot Registered Member

    Joined:
    May 14, 2005
    Posts:
    2,318
    If you were to break down the figures that you have come up with by version number and build you would find with something quite revealing.
    Early builds of version 9 very frequently reported corrupt archives. In fact there was nothing wrong with with the vast majority of them and they could be validated and restored by using the rescue CD of version 8. Once the problem was fixed a new build was released and the large number of apparent bad archives dropped dramatically.

    For your analysis to be itself more valid you should really concern yourself with corrupt archives that could not be restored. Unfortunately I don't think that you will be able to extract this information. This is because most users will keep several generations of .tibs and if they have a failed restore with the latest image they have the option to go back to another one to get up and running again. There is also the fact that the vast majority of users will not attempt a restore from a "corrupt" archive. They forget that this can be done in perfect safety by running the restore to a spare hard drive and then booting from it.

    The best part of two years ago I gave up running validations completely. Not because they failed but because I find them unnecessary. I am convinced that there are sufficient internal checks within the imaging and restore process to ensure that all the data is handled correctly. My conviction is based on the fact that I have done and continue to do restores from unvalidated archives and it works. I can do this with confidence because I never restore over a current drive but use a previous one. Swapping main hard drives may be a bit old fashioned but it is still the most secure way I have found.

    Unlike you I am convinced that validation problems are almost always hardware related with a small number of conflicts with other programs or services. I have no statistics to prove this apart from the fact that I have run hundreds of restores with less than 0.5 % failure rate. I am willing to believe these were due random errors in my equipment rather than a fundemental problem with the TI program. It does however point up the need to always have more than one backup and to have backups on more than one media.

    So my advice to you would be to do some restores to a spare drive and then you will know if you have to start going through the range of hardware and software checks that are available to bottom out the problem.

    Xpilot
     
  5. Xpilot

    Xpilot Registered Member

    Joined:
    May 14, 2005
    Posts:
    2,318
    Hi johnmeyer,

    Having slept on it and then thought a bit further it has become patently obvious that your reference to a bug and a thousand hits for the word corrupt is somewhat misleading.
    It assumes that there really is a bug and it ignores the multiplier effect. When an individual has a validation problem and reports it to this forum several contributors will rally round to help as will Acronis support. Many of these will quote the original post and virtually all will repeat the key word maybe several times in their replies. So just to pick on a key word can give a much inflated view of the actual situation.

    Xpilot
     
  6. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    A good point about search results Xpilot.

    Granted it's a small sample but this Poll indicates that, of the 20 users that had carried out 10 or more restores, only 3 had experienced more than 1 failure. It's a fair bet that those failures, particularly the user reporting 10 out of 10 failures (if true :cautious:), were due to specific hardware/other software problems/incompatibilities rather than a fundamental design flaw in TI.

    I also agree that the number of reports on archive corruption have reduced noticeably since the release of TI 10. The new imaging engine introduced in TI 9.0 Home Build 3567 had also helped to reduce the number of arisings.

    Regards

    Menorcaman
     
  7. johnmeyer

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    I copied the archive from one of my ten external USB drives to my one and only external Firewire drive. That drive is also the only drive that is formatted with FAT32. All the others are NTFS. So, unfortunately, I changed four variables at once: different drive; different enclosure; different interface; different file system. But, it worked and I am writing this to you on my restored PC.

    Thanks for the links to posts where users verified that bad memory was the cause of their problem. I obviously didn't see those. All of the ones I looked at showed that this WASN'T the problem, and it certainly is not the problem in my case.

    I'm working on that now. I have many dozens of TIB files, and as time permits, I am testing each one. If it verifies OK in its original location, I move to the next one. If the next one fails (reports as corrupt), I then copy it to one of my internal drives and retest (using the validation from Windows). So far, all of them have worked on the internal drive.

    What I am not yet testing is the separate problem which I also reported, namely that TIB files that validate OK from within the "normal" Windows version of True Image, fail validation when you try to restore from a True Image restore CD. That one would take too much time to test (at least I don't have that kind of time). However, that is what happened yesterday. I guess that is why one of you recommends doing a restore to a spare drive as the ultimate test of whether the image is valid and useful. He's got a good point -- although such a step should not be necessary IMO.

    Excellent point. And, that's exactly what I did as well and if it had worked right away, I probably wouldn't have take the time to report the problem. My most recent archive truly was corrupt (it was 4GBytes, but showed no files when I opened it in TI), so I moved to the one from a week earlier. It eventually worked.

    There is obviously a hardware component to this issue: the fact that the file works when copied to an internal drive proves that. However, I use these ten external drives all the time, connected to several different computers, and I capture video to them and do other things that stress them considerably. This is the ONLY application that has a problem. Also, only SOME of the files won't verify; others on the same drive DO verify just fine. And, if I connect these drives to other computers on which I am running True Image, I have the same problem, which is why I think the memory issue is not likely to be the problem for most people (unless I have three separate computers that all have identical memory problems that only manifest themselves with one program, and otherwise work perfectly).

    Yes and no. You are correct that it includes many posts from the same thread and therefore increases the number of hits compared to the number of actual problems. However, I didn't include variations on the word corrupt (such as "corrupted"), and I didn't also search for "validate" and other words that might have been used in place of corrupt.

    In addition, this forum stops the number of hits returned at 1,000: the actual number could have been 10,000, for all I know. The point is that I found a HUGE number of posts about this problem as I tried to search on my own for answers before burdening this forum with yet another post on the subject.

    I will certainly run memtest86 AGAIN (I have run it before); all four computers are running TI9, Build 3854 so I can't do anything to improve the situation there. I have updated the USB firmware on the one drive that permits such an upgrade (didn't help). I cannot find USB firmware upgrades for my motherboards. I have received a response from tech support, and I will see if I can find any solutions that work (nothing new in their response, but it is a very complete list).

    If I find something that works, I will let everyone know. In the meantime, if we are to continue to use this product, then the one piece of advice I can give is to make sure to backup to multiple different devices, and make sure that they are different in some way (different enclosure, drive, interface, etc.) in case that is the cause of this problem.
     
  8. dbknox

    dbknox Registered Member

    Joined:
    Jun 7, 2006
    Posts:
    511
    Location:
    Canada
    johnmeyer I commend you on the work you are attempting, although, I haven't seen anyone else post their fixes for the problem. I am one of the few lucky ones that have no problems at all with ATI 9.0, although originally I did and it turned out to be my win98se operating system that was the problem ( backup would freeze and stall) once I reloaded windows I had no further problems. The "rescue disk" worked fine. ( I now run XP)
    Though, I do not have problems this is excellent advice and I follow it. Every second week I image to my spare internal HD and the every other week to my USB HD.
    Good luck on your endeavours, I am sure your posts will be followed by those that have the trouble you are addressing
     
  9. MudCrab

    MudCrab Imaging Specialist

    Joined:
    Nov 3, 2006
    Posts:
    6,483
    Location:
    California
    johnmeyer,

    For your problems (images not validating in Windows), you may need to get updated snapapi drivers for TI. There are several links floating around the forum, but I don't know if they only work with TI 10 or if they'll work with TI 9 too. You might want to contact Acronis Support and find out.

    The way I look at "corrupt" images is that if the image can be validated successfully then it is not corrupt. That is to say, if the image fails validation on my USB drive and my Firewire drive and my network share and my NAS, but passes validation when it's on an internal drive, then the image is not corrupt. If it can pass at all then it's not corrupt. This does not help if the method you're using to restore does not let you use the specific scenario that results in a valid image. However, it does let you know the image file itself is intact and that data contained can be retrieved.

    When booted to the TI CD in Full Mode (Linux-based), TI uses Linux drivers to access the hardware. These drivers are the root of most problems when using this method. On most computer/chipsets, the drivers do well (although normally with times at least twice a slow as Windows). On others, they refuse to work or you have to use kernel command options to get it to work (or request a custom ISO that contains the correct drivers/settings for your computer). This may be the case for you, although it sounds like you do most of your backups/restores/validations from Windows.

    You say you use your USB drives a lot and capture video, etc. I assume these files are quite large. Have you ever done MD5 checksums on the files before being copied to a USB drive, then on the USB drive copy, then copy it back to the internal drive and check again?

    One of the problems seems to be how TI interfaces with the devices. You can create an image and save it to a USB drive and validation will fail. However, when you copy the same "corrupt" image to an internal drive, it will pass validation. What does this mean? It means that TI created a successful image, but can't read it back successfully. Windows, however, can, as proved by copying it to an internal drive.

    These kinds of problems can be very difficult to figure out as they can involve hardware, drivers, chipsets, USB controllers, Windows versions, etc. This makes pinning down the "root" problem practically impossible, at least on a "global" scale.

    As stated many times on this forum, the best solution is the one that allows you to be able to restore when necessary with the least amount of problems (hopefully, none). For some, this will take a while to find. For others, the program works perfectly from the first try.

    If you have any data that is important to you, then don't trust it to one backup source. Make multiple backups. Make image and data backups. Make backups using multiple backup programs. Make backups in native formats. And most importantly of all, store a least one "set" of backups off-site (at a friend's house or in a bank safety deposit box, for example).
     
    Last edited: Sep 12, 2007
  10. Menorcaman

    Menorcaman Retired Moderator

    Joined:
    Aug 19, 2004
    Posts:
    4,661
    Location:
    Menorca (Balearic Islands) Spain
    Hello John,

    You're hardly going to notice the affect of a few bad data bytes in a video file. However, if just a single data bit of an image is screwed up by your hardware then TI will report that image as corrupt. If not already done, I recommend you carry out the Large File Copy/MD5 Checksum test detailed in Post #29 of this previous thread. If you can't consistently copy an image file between your internal HD and the external USB drive without an MD5 checksum error then you definitely have a hardware problem. This often boils down to an incompatibility between the motherboard's USB sub-system and an external HD enclosure's USB-to-ATA bridge chipset.

    When you do, please ensure that you use Memtest86+ (currently v1.7) available from www.memtest.org rather than the original Memtest from www.memtest86.com. Memtest86+ is updated more frequently and has proven to be the better version.

    Regards

    Menorcaman
     
  11. Xpilot

    Xpilot Registered Member

    Joined:
    May 14, 2005
    Posts:
    2,318
    Hello again johnmeyer,

    Well you now have got some of the best heavyweights on your case you will be kept busy following all the procedures to get things running properly!

    So I will throw a few more suggestions into the hat to keep you on your mental toes.

    Build a Bart PE with TI plugin CD. Try running validations when booted in the PE environment. As this will use your standard Windows drivers it may eliminate the validation problems at a stroke with the added advantage it will probably run much more quickly.

    Another way for the validations to follow a different path and eliminate external drive chip sets etc would be to install a slave drive in the computer and create images and perform validations there. If this is consistantly sucessful you could then copy some or all to external drives for extra security or even restore to a spare drive from time to time.

    If your CHKDSK Rs on all your drives have shown up any with sectors marked as bad remove them form the mix if only on a temporary basis. I assume that nothing adverse has ever shown up from the various drives SMART status reports. However it is still worth running the manufacturers' quick diagnostic tests on all your drives if all else has failed to reveal anything.

    You can have a nice long sleep while the latest and greatest Mem test gives your RAM a good going over.

    Xpilot
     
  12. Disappointed

    Disappointed Registered Member

    Joined:
    Aug 28, 2007
    Posts:
    3
    Wouldn't you think that by the time it was version 10, build 4942 it would work? Keep it simple, the product either works or it doesn't and based on my experience with a E00070020 (corrupt file) at the time I really needed to do a restore, it doesn't. Very disappointing.

    As far as support, it is poor. You get much better advice in this forum then you do from Acronis. At least this forum provides useful tips.

    My work around was to reinstall XP and all prgrams and then mount the backup file (that worked) and copy back all of the data files. Very time consuming. It appears that just backing up data files works fine, it is when TI needs to do an image copy is when all of the problems come up.
     
  13. johnmeyer

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    Thanks, I'll have to look into that.

    Technically, you are correct, but that definition is cold comfort when your computer is dead and you're giving it mouth-to-mouth, and this damned program is giving you "corrupt" messages. Is it corrupt, or is it just pretending to be corrupt? I really don't want to have to deal with this.

    That would certainly explain why the validation behavior is different.

    No, I haven't. I'll look into this as well, but should I really need to? Also see my comment below about why I am quite certain the copy operation is perfect.

    Excellent description! That, in a nutshell, is the problem. TI seems to have a problem with external drives that other programs do not. The idea that it "stresses" the drive in some unique way is poppycock: a program makes a windows call to open, read, or close a file. That Windows call handles everything and doesn't care if the calling program is TI, a game, or a spreadsheet. Now, perhaps Acronis is using non-standard calls, or has some poor code that, in order to improve performance, is breaking rules. This sort of thing is done all the time (more so in the "old days"), but if you aren't a really good, experienced programmer, you can create serious problems. I strongly suspect that this is what we have in this case.

    What it takes is a product team that has recognized the seriousness of the problem and the implications for their paycheck, and therefore WANTS to find the problem and its solution. This is the difference between a run-of-the-mill software team, and a world-class software team that retires at age 35 with lots of money.

    That's definitely not true. At the very least, you will see a garbled or dropped frame. If you edit video for a living (as I do at this point), you will see that. What's more, with m2t files (the HDV long GOP format), any corruption will actually affect up to almost a dozen frames. Finally, if certain headers or periodic flags are screwed up, the file may not play at all.

    I ran Memtest86 again yesterday, just so I could say I did. Needless to say, it found nothing, even after several passes. This obsession with blaming this on memory reminds me of posts in other forums where some people love to tell everyone to defragment their drive, which is one of the most useless wastes of time imaginable. But, that's a topic for another post at another time.

    I'll have to remember that for the next time. I have used the Bart PE in the past to help recover a neighbor's PC.

    Yup, I've done that in the past, and it is the "ultimate" way to do a restore, eliminating virtually all possible problems. It's a royal pain in the tush, however.

    This is something I do quite regularly. No bad sectors on any of my drives, but it sometimes finds remnants of crashes.

    Since I started this post, I have gone back to dozens and dozens of backups on six of my ten external drives, and one-by-one, I'm validating all of them. I'm only about halfway through this process, but I DID find some additional corrupt file (as opposed to image) backups. However, the nice thing about those is that I was able to restore everything except a few files, and I then did a new backup from this slightly reduced set of files. By contrast, the image backup is all or nothing (at least if you are trying to recover the image -- you can still sometimes retrieve some of the files). Thus, it has zero margin for error.

    Summary to this point.

    After doing a lot of validation on lots of different external drives, I have not yet come up with a pattern. Every drive tested had some corrupt backups and also lots that were OK. Most of these corrupt backups tested OK when copied to the internal hard drive. Since the copy operation cannot "cure" the file, I can say for 100% certain that the file on the internal drive is exactly the same as the "bad" one on the external drive (i.e., I don't need to do a MD5 checksum or anything else).

    Also, I can take that same "bad" file on that same drive, hook up that external drive to another computer that is running the identical version of TrueImage, and it still validates bad, even though that computer is completely different (Dell laptop vs. Polywell desktop), running a different processor, different version of Windows, different memory, etc. Thus, the problem HAS to be True Image.

    One thing I am going to try to test is whether there is some correlation with cables. I have a lot of USB cables. Cables can definitely go bad, and can cause intermittents and other flakiness. However, just as with the memory red herring, I think it HIGHLY unlikely that such a huge number of people would have bad cables that only manifest problems with one application. Thus, I do not expect to find anything, but I'm going to at least look into it.

    If Acronis isn't going to track this down (although they darn well should), then hopefully we can.
     
  14. jmk94903

    jmk94903 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    3,329
    Location:
    San Rafael, CA
    Since you have tried lots of different USB drives, I think you have eliminated the drive itself as being the problem (except in some unusual cases). That suggests that some common point in the hardware is the cause of the problem. That puts the problem hardware on the motherboard. My guess would be first the USB chipset and second the hard drive controller.

    You could install an Adaptec PCI (or PC card if this is a notebook) USB 2.0 adapter which would give you a differenct USB chipset. In my experience the NEC chips that Adaptec uses are the most reliable.

    If using the Adaptec USB ports eliminates the validation problem, you have confirmed that the USB chps on your motherboard are the source of the problem.

    The hard drive controller chips are harder to test because I can't point out a PCI controller that has been shown to be good, and even if you bought one, the motherboard chipset may still be involved. There are confirmed cases of motherboards that cannot handle the large file sizes of backup images reliably.

    However, you reported that copying the files back to an internal drive from a USB drive resulted in valid files, so I doubt that your motherboard hard drive controller is the source of any problems.

    It is possible that some other USB activity interferes with reading the large files during the validation and accounts for a given file being good sometimes and bad sometimes.
     
  15. bilby

    bilby Registered Member

    Joined:
    Sep 4, 2007
    Posts:
    17
    A workaround that seems to be helping me with similar problems is to use a BartPE disk with an Acronis Plugin. Mudcrab has links in a previous message on how to do this, and he helped me get mine going (Thanks again, Mudcrab). --bilby
     
  16. johnmeyer

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    That would be true if it weren't for the fact that these backup files came from three different computers. They are all completely different (Polywell P4 2.8 GHz; Dell Inspiron 6000 laptop; Dell Dimension 4000).

    That's the second mention about this. I promised in my last post to look into this, but haven't yet had a chance. Thanks.
     
  17. jmk94903

    jmk94903 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    3,329
    Location:
    San Rafael, CA
    Are you saying that the backups sometimes failed to validate when checked on the three different computers on which they were made?

    I thought all the validating was done on one computer and that some of the images validated and some didn't. The source of the images wouldn't matter if the validating failed sometimes on only one computer.
     
  18. johnmeyer

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    I have every permutation possible, and they all have problems:

    1. I have three computers, all running the same (latest) version of True Image 9.0.

    2. I have ten external USB drives.

    3. I have made backups from each of these three computers to about six of these drives.

    4. I have experienced the problem of "corrupt" files on all six drives from all three computers.

    5. When I move the external drive from one computer to another, the file still is reported as "corrupt" when I do a validation.

    6. When I copy one of these "corrupt" files from any one of the six external drives to any one of the three computers, then most of the time that file will validate OK. For a few files, this "trick" did not work and I eventually had to delete the backup.

    I mentioned that I have ten external drives, but only mention six: I simply haven't used the others for backups.

    Hope that clarifies what I am doing.
     
  19. thomasjk

    thomasjk Registered Member

    Joined:
    Jul 22, 2005
    Posts:
    1,477
    Location:
    Charlotte NC
    I got tired just reading that. :D You really are determined!
     
  20. johnmeyer

    johnmeyer Registered Member

    Joined:
    Oct 18, 2005
    Posts:
    51
    Yeah, I'm compulsive. But once you get beyond my personality disorder, you'll find that the reason I'm doing this is:

    1. This is otherwise a REALLY good program;
    2. I rely almost daily on this program and have entrusted my data and a good portion of my livelihood to its care;
    3. The competing programs are painful to use;
    4. Yet, unfortunately, this bug is quite real and is affecting a lot of users.

    As I mentioned earlier, I have run several software companies and I know what it is like in both development and support. The support people hear about nothing but problems all day, and pretty soon one complaint sounds just like another. They have a VERY tough time prioritizing. The development team is usually isolated from all this and are pursuing the things that they find fun, challenging and interesting. What is needed -- and sadly is lacing in most software companies -- is a product manager who overseas development, marketing and support and IS able to understand the implications of a fundamental flaw like this, and puts out a "all hands on deck" call to focus on the problem and fix it.

    Unlike other companies where I can call the VP of Engineering and get an audience, I don't know anyone at all at this company and so cannot "tweak" them to get the process started. That's what I'm trying to do with this thread.
     
  21. bilby

    bilby Registered Member

    Joined:
    Sep 4, 2007
    Posts:
    17
    I agree with you wholeheartedly. I sincerely hope you can achieve your goal. Unfortunately, I'm just another user plagued by the problems you describe and don't have any expertise to contribute to a solution. My experience with Acronis support has been entirely negative to the point that I would never call on them again - it was a huge waste of time the last time I did. So your effort here seems to be the best hope by far. --bilby
     
  22. jmk94903

    jmk94903 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    3,329
    Location:
    San Rafael, CA
    That's a very significant typo. One problem with Acronis development is that the team is overseas. They are in Russia, and that adds to the complexity of communications.

    I guess I'll have to admit that you are right about this being an Acronis problem. Something in the way TI reads the image file, most often when on a USB drive but sometimes on DVD drives and network drives, leads to a bad CRC check which becomes a "corrupt" evaluation of the file.

    Have you ever created a backup image to an internal hard disk of any of your systems and had it found corrupt?

    I believe this is hardware related because I have not had any backup identified as corrupted on the systems I work with. That includes primarily systems with Intel motherboards but also many Dell systems both desktops and notebooks and a lesser number of HP and other systems. About 85% of the time I make the backup from the TI Recovery CD (50% TI 8, 45% TI 9 and 5% TI 10 as a guess) Frankly, I think I have just been lucky, but I don't mind that. :) Most of the systems I deal with have only the USB drive attached or perhaps a USB keyboard and/or mouse and possibly a printer or scanner, but none have USB hubs or USB memory card readers or other USB devices that I can think of.

    The USB drives I use are WD passport, Seagate FreeAgent, a CompUSA case with a Maxtor drive, a no-name case with a WD drive, etc. All work equally well.

    If you are willing to spend the $25-$40 to get an Adaptec PCI USB 2.0 card, I think you might get some valuable data on whether you can find a workaround for hardware problems.
     
  23. MudCrab

    MudCrab Imaging Specialist

    Joined:
    Nov 3, 2006
    Posts:
    6,483
    Location:
    California
    I have suggested before that it would be nice to have the option of parity/error correction information being stored in the backup image. I realize that this would increase the size of the image, but it would be nice to have the option. It would also allow any errors (at least minor ones) to be corrected automatically and let the image validate or restore properly. The way Acronis does it now is a 100% or nothing setup as far as restores go. You can usually mount or explore a "corrupt" image, but not restore it.
     
  24. jmk94903

    jmk94903 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    3,329
    Location:
    San Rafael, CA
    I think that quality and length of USB 2.0 cables can matter. I never use a cable longer than 3 feet. USB 2.0 cables should be shielded, and I only use cables of that design. This may be overly conservative, but I don't get corrupted images, so I will keep doing it this way.

    An interesting test that has been discussed in other threads is to simply copy a large backup image from an internal drive to an external USB drive. Do a CRC check on the file on the internal drive and then on the external drive. Do this several times, copying in both directions. All the CRC checks should be identical. If they are not, it's proof that there is a hardware problem totally separate from TrueImage.

    In several cases, people with validation problems also reported that simply copying the image files resulted in different CRC values.

    If there are validation problems but all the CRC checks are identical, it's proof that TI is reading incorrectly as a minimum and possibly writing incorrectly.
     
  25. MudCrab

    MudCrab Imaging Specialist

    Joined:
    Nov 3, 2006
    Posts:
    6,483
    Location:
    California
    I wonder if there's a "memtest" type program out there that does this automatically. If there were, you could setup the program to create a random filled file of a specified size and have it copy it repeatedly back and forth between selected drives (USB, network, internals, etc.), having it check and log the checksums on each transfer. You could let it run all night and see if any errors showed up.
     
Thread Status:
Not open for further replies.