Verified archive fails

I checked an archive with True Image 9.0 (Build 3666). The archive had been created with the same software. The archive was verified by TI. Then I attempted to Restore it. The restore failed, with the error message that selfsame archive is Corrupt. However, it did not tell me this until it had deleted the current partition.

I restored from a different archive, this time in the Secure Zone, built another archive outside the Secure Zone, and checked it with TI. It checked out, but again told me the archive was corrupt when I tried to install it. Running the check on the archive again, TI told me the archive was good.

This seems a very serious problem. Even if this problem has been resolved in a later build, which I haven't checked, it does not seem something that should ever happen. Am I wrong?

 

srdiamond, can you provide some details of your system please.

Processor, RAM, OS, Disk type, Internal disks, USB drives.... etc

Tks

 

2.6 gh processor; 728 MB ram; Windows XP Home; backup contained on partition of Maxtor external hard drive connected to USB port; 40 GB internal Maxtor drive. (The computer is essentially an intermediate-priced Dell of two years vintage.)

 

Thanks for the info.

Shutdown Windows completely and then reboot from the TI CD. Attempt the restore again. If it fails, try a few times. The external USB drive must be switched ON before you boot from the CD, if you switch it on after you boot the Linux kernel may not pick up the drive. (This is not a fault with TI it is just the way some USB devices handshake with the system).

If the above fails come back to the Forum.

 

In situations where you have the luxury of still having a runninbg system, check out tye archive BEEFORE you attempt a restore by running the followqing programs:

http://www.standards.com/index.html?CompareDrives
http://www.standards.com/index.html?GetFileTypeDistrbution

If the archive is indeed bad, one, or more, of those programs will fail, gracefully or not. but that's better than finding out the hard way, i.e.afTER deleting the partition an dthen failing on the restRE.

 

Hello srdiamond,

Thank you for your interest in Acronis True Image

First of all, please make sure you use the latest build of the program, which is available on our web site at http://www.acronis.com/enterprise/support/updates/. To get access to updates you should register your software first at http://www.acronis.com/enterprise/registration/. Please disable any download managers, Internet download/connection boosters, etc. before the download.

Most likely, this is a problem of your outdated build. Please update your product and try again. If it fails - please contact our technical support (support@acronis.com).

Thank you.
--
Fedor Kurbatov

 

I don't think this is a satisfactory response. I would be interested in the opinions of some technically proficient users, because it seems to me so completely unsatisfactory. So what if its an outdated build. The archive was created by the same build, and I could just as easily have had the problem before an updated build is released. Is this not the kind of problem that should _never_ see the light of day? The check your archive before rebuilding and find it is ok, and not to be able to rely on information. This seems completely intolerable.

Are these standards unrealistically high?

 

Thanks for your response, Howard. Are you saying then that the archive checker native to TI does not reliably work or is insufficiently accurate to rely on? Why does it tell me the archive is OK if it's corrupt, and the freeware programs you mention could determine this. If freeware can get it right, why can't the archive checker that comes with TI?

But really more to the point, I don't think the archive was corrupted. It still exists, so the question isn't entirely moot. I think the archive is OK but for some reason was rejected by TI as corrupted. The reason I think that is, for one thing, it seems implausible that the archive checker would take twenty minutes or whatever to check the archive and give it a clean bill of health, but upon trying to mount the archive, TI would in a split second correctly render a verdict of "Corrupt." Also, the suggestions that one user made to make repeat efforts and to make sure the USB drive is turned on at boot (it was) suggests that others also think the archive was actually OK.

That's less bad than if the archive is corrupt, because if it's a problem mounting the archive, then maybe it could be solved and the archive in the end relied on. But to draw that conclusion, shouldn't Acronis be interested in why such a problem could occur? It's still a bad situation to be locked out of an archive you think you can rely on and has checked out. It isn't as though the restoration hasn't worked in the past with the same hardware and system. So it isn't that there's something inherently problematic in on my computer, like an incompatible drive or something.

 

Have any of your backup images been run from schedules and if so have any of these been edited? In some builds prior to 3677,including 3666, editing a scheduled backup gave this fault. The backup would run and appeared to be sucessful but it would fail on restoration. Whether this is the cause of your problem or not I would say do not edit any scheduled backups in 3666 if you want to change them delete and recreate. Better still uninstall 3666 and install 3677.

Xpilot

 

You have a valid point. And I am not too comfortable with the advice given by Acronis Support. Personally I always ensure that the restore is done with the same build as the image was created. Unnecessary perhaps but to me this seems to make logical sense.

My view of your problem is that there is a very good possiblility that the image is OK and that it is during the restore that the problem occurs. In your particular setup the most likely cause is timing differences between your USB drive and your system. TI will popup a "one-size-fits-all" message like "Archive Corrupt", when in fact there is nothing wrong with the archive, but TI has detected a data error initiated by something else (e.g. RAM, timing differences, noise on a USB data cable... etc)

(NOTE : The following assumes that you have an external USB enclosure and a disk in that enclosure. This DOES NOT apply if you have an integrated external USB drive, e.g. a Maxtor One-Touch)

If you cannot get the archive to restore from the USB drive then the only suggestion that I have is that you move the disk from the USB enclosure and install it as an internal disk and try again. In this case you are moving data in a way that your other system components should be able to synchronise and there should (theoretically) be no data corruption in the restore process and (hopefully) TI will not have a blue fit and popup heart-stopping messages.

Give it a try.

 

Programs such as Ghost 10 and TI 9 do no more than verify a "checksum" to determine whether what they recorded is self-consistent, i.e., they do not actualy go back and compare byte by byte as is done by some well known file-based backups. But file-base backups can have the same problem, there are no guarantees.

Although there is a very low probability that checksums could be in error, it can happen.

Also, media sometimes gets bad after the deed was done.

The programs I listed use the standard windows APIs to access the files. If they cannot access the files, then that is a useful warning that the archive is corrupt, and thou shalt not delete a partition before one knows the archive is good.

Two of the programs just compare certain file attributes, so they do not actually read the files. However, if the archive is corrupt, it is likely that either of theose programs will fail on some file. It does not take very long to run either of those programs.

The "Attributes" program does examine ALL files on both drives, but it does nor read the file content.

The "FileTypes" program does examine ALL files on both drives, but it does nor read the file content.

The "Content" program compares files on two volumes by actually reading the files, if they have the same size. Of course, if you run this shortly after a backup, the files will almost all have the same size, so this is a good check of an archive. Certain files will not be readable because they are in use or protected by the OS. The "Content" progran can take a long time to run, as it is, in effect, reading each file twice.

Again, if the archive is correct, one, or all, of these programs will fail and that will serve as a warning that th earchive is bad.

 

I fergot to mention.

Only TI know fer sure whethe rdifferent code is used for retireving files via mount or via a restore.TI would be foolish to use diffeent code, but there could be bugs in either mechanism.

A "recovery", should merely be copying te file cluster bacl onto the drive, with the addition of updating the cluste rinfo in the file system structues, so this likely uses very different code than use by mount or restore.

Since TI does not have an API for their archive, best one can do is to try to read the files from a mounted volume using the usual windows API FindfirstFile, FindNextFile, CreateFile and ReadFle.

 

"Very low" might be a bit of an understatement for files as large as TI images.

Here is the formula:

p = 1/2^b - 1/2^n

where:
p is the probability that any two files have the same checksum, but are
actually different.
b is the number of bits in the checksum
n is the number of bits in a file.

The first term is the probability any two random files have the same
checksum. The second term is the probability that any two random files are
actually the same. As you can see, as b -> n, p -> 0, but as n gets
significantly larger than b, it has less and less affect. We are talking
relative probability changes in the order 1/2^1000.

What this means is that in this universe, the chances of the checksum method producing a false verification are effectively zero.

 

TI's attitude appears to be that they care only about the latest build.
This is inappropriate, as TI has even suggested that some go back to earlier builds in certain circumstances. It is EVERY software company's dream to only have to support i version/build of each product, that's unrealistic, especially given te buggy releases we see for certain software

To be useful, a product has to have a reasonable product lifecycle, be it 1 year or 2 years or whatever. at the end of the product lifecycle, support can be dropped, or made available on a paid basis.

Ditto for each build. I would guess that anything less than a 6-month build lifecycle would be inappropriate.

 

I tend to turn this around and say because of buggy releases it makes sense to try the latest build because it has likely more than just obscure fixes in it. I also think that Acronis has limited support resources so it provides some relief to have a customer try the latest build that has a chance of correcting the problem. Chasing around obsolete builds is not a good use of time. Is this ideal, not likely, but in most cases it is the practical way of doing things.

 

It is not OUR job to do a software manufacturer's job.
The only appropriate response, by a user, to inadequate support and SQA is to move to another product.

In general, few products have adequate support, but there are many that reflect obviously better SQA/design processes and are stable products. In the area of backup software, there are such products.

In the case of TI, users can help themselves by not using options for Secure Zone, Recovery Manager and "cloning". And better documentation, not to mention putting up a useful support knowledge base, would really help a lot.

 

I agree it's not our job but we seem to be stuck with it. Since I do my backups the simple way,no external drives, no DVD, no SZ, no Recovery Manager, no cloning as you mention, I have had great success since even the first version I bought, build 2302.

The lack of better documentation, a knowledge base and even the considerably easier task of expanding the info in the forum sticky is one of the reasons I say that they are running with limited support resources.

 

There are alternatives.

I use both Ghost 10 and TI 9.

No external drives means you are not doing backup, rather you are playing with fire. I'm sure your parents told you not to play with fire!

Forum stickies are a horrible way to document things.

 

You are welcome to use Ghost, one of my rules is keep anything by Symantec away from my PC.

I consider a failure that wipes out a second internal drive to be very unlikely. To be honest, I also copy and sometimes create images to another PC using a gigabit LAN, and I do burn the odd one to DVD. Even though I use DVDs, I let Nero deal with them not TI. Direct burning is not for me.

I don't think it is a good way either but when I think how many hundred times I and others have typed the same answers to questions I think stickies would be better than that in the absence of a knowledge-base.

 

OT posts concerning other products removed

To all:

As a reminder....this is the Acronis Support Forum. Any side discussions about other software....i.e....likes\dislikes, cost comparisons can be discussed in our software & services forum.

Bubba

 

I always backup to and restore from a second internal HD. It's the fastest and most reliable way.

Selected images get copied from the second internal HD to an external HD that's being connected only for that operation and the subsequent validation of the copy.

Once in a while I will copy an image from the second internal HD to DVDs instead, using Roxio and keeping the burning speed low. Validating again, of course, or performing a bit-to-bit compare.

 

Hi,

How do you do a bit-to-bit compare? And is it really more accurate than the validation method used by Acronis software? A well-known competitor of Acronis boasts of bit-to-bit comparison, but I've never understood why it matters.

Thanks in advance,

Good luck, Dan

 

I believe you will get a bit-to-bit compare if you use the burning program's "verify after burning" feature. It is easy for it to do this since it has an untouched original file and the new copy to do a compare. When TI does a compare it may well be working with an archive that was created by a Windows snapshot and the original form of the disk no longer exists. Using the checksum method allows the archive to be validated at any time on any machine.

Probably the advantage of the bit-to-bit compare is that it does go back to the original for the comparison. The checksum method certainly will catch any problem in reading the contents of the archive or if the archive has changed in any way but to say more than that really requires a knowledge of how the checksum mechanism is implemented in TI.

 

I was unclear, yes.

A bit-to-bit compare between the image and the source itself can not be performed in TI. If the image was created from inside Windows (like I always do), that wouldn't be even possible, due to constant changes Windows and other background processes do to files.

Therefore, I regard the TI validated image, stored on the second internal HD, as the reference image file and the compare of it's copy on DVD is done against that. I started to use the CDCheck program I already had because it's faster then Roxio's verify after burning option though my method requires some additional work. Moreover, it's unclear to me whether Roxio's verify procedure is a true bit-to-bit compare or not.

It would be interesting to know under what conditions and to what extent the competitor is able to execute the advertised bit-to-bit comparison. To me it would seem quite a feat to perform a real bit-to-bit compare between a processed (and possibly compressed) image file of it's own format and the actual data bits as they reside on the hard disk.

 

THere are two compares that matter:

1. The verify using the checksum to assure that, AT THAT MOMENT. the archive is self-consistent and may be read.

2. Whether the content of the files in the archive is identical with the content of the actual files on the source drives. Except or a few files that cannot be read due to being open or security issues, the only way to verify this is to use programs such as:

http://www.standards.com/index.html?CompareDrives
http://www.standards.com/index.html?GetFileTypeDistribution

The Attributes and GetFileTypes programs wil compare certain attributes, and if run shortly after a backup, give a high level of confidence that al files are present in te backup.

The Content program will actually read the files that have the same size in the archive and in the source drive, and will report those thatr have different sizes. This will occur for all non-open files for which there are no restrictions on access.