Image won't restore

I have an image of a partition that verifies OK (checked twice) but fails about half-way through the restore with the message "Restore failed. Image corrupted".

I have reformatted the destination partition and checked it with chkdsk. No problems reported. I have "looked" at the destination partition with other utilities and all report as Good or Healthy or OK. I have written data to the partition, deleted data, moved data..... all functions OK. There is no indication that the destination disk or partition is faulty.

What is really concerning me is that TI9 can verify an image as OK and then in the restore phase report that the image is corrupted.

Any thoughts...

 

Two thoughts in no particular order:

1. Memory problem, when restoring different locations are being used and there is a faulty location. Also, the system is not running under the exact same conditions when doing a restore compared to a verify.

2. TI is not known for specific error messages so perhaps the corrupted archive message is used for more than one situation. Perhaps the structure of the image is bad caused by backing up a faulty disk structure.

Number 2 would not be seen from the verify because all it does is compute checksum(s?); if it happily reads bad data it will compute a corresponding checksum for the file and the verify process would re-calculate it from the file contents.

Can you restore another image OK?

 

you don't say what you are restoring from. I have one USB drive which acts up and gives me the error you have reported - yet if I copy the image to another partition on the main machine the image restores just fine.

 

Does it verify OK while on the USB drive?

IMO, restoring from a partition on an internal HD seems to be the least troublesome. However, if you have a USB drive that works OK it will likely continue to work fine.

 

yes the image verifies ok. I have 5 different brands of external USB - with only one (Pika One) giving a problem and even then not all the time. As a matter of practice I keep daily system and data images on these externals but always keep a system image on a hard drive partition for a quick system restore.

 

Tks for the feedback.

Source Disk
The Source disk was very carefully prepared prior to imaging. Disk cleanup, defrag, chkdsk. All OK no problems reported.

The image source is on an external USB 2.0 drive. The drive has been 100% reliable with no errors ever reported. Time-lags that are an inevitable consequence of USB drives, seem to be correctly handled between the drive circuitry and the motherboard. If this is the problem then it is a concern because neither WXP nor any applications (other than TI9) are experiencing any issues.

Destination Disk
Again, very carefully prepared. Destination partition re-formatted and checked with chkdsk. All OK.


Memory
RAM is 1GB which should be more than adequate. Checked RAM with a specialist memory-checker and also using the normal BIOS startup RAM check. Neither have reported any problems.

Operating Conditions
seekforever :

Well it should be. I have specifically used the Linux kernel to create the image, verify the image and restore the image. So there should be virtually no difference in the operating conditions. The TI9 Linux kernel is not even a full OS, it is only a subset of Linux with just enough functionality and driver support to perform the TI9 functions.

USB Issues
Long View :

Fair enough. In an emergency this would be a valid option. However, I think any of my customers (who in the main are not technical) would find it unacceptable to have to go through this type of procedure. And what if it is the system disk that failed? You cannot just restore a system partition to any partition on any disk. And TI9 does not give the user the option to Copy or Move .tib archives, you can only Restore them.

Failures like this make it difficult to recommend TI9 as a completely reliable system and data recovery solution. I still think it is the best-of-breed and way better than competing products but as a consultant, if I recommend a solution, then I had better be prepared to put my reputation on the line if the wheels come off.

 

Close but not identical. A restore is a read, decompress, write operation whereas a Validate is a read, (decompress?). There is double buss traffic which may show up timing problems and there may be increased loading on power supplies with the extra disk activity. Not a large amount for sure but maybe just enough to cause a dropped bit.

Have you considered doing the BartPE recovery disk with the included TI plug-in? This will give you a Windows environment just in case there is a problem with Linux drivers etc.

 

Does the length of cable used matter ? or does it matter how many USB devices are being used ?

the only other time I have seen Acronis issues is with a set up involving making an image from One external USB to another. eaxh device alone worked fine but when both were plugged in Acronis failed to "see" one of the devices. I believe that the problem was caused by a USB extension cable that was just too long.
Anyway replacing the cable with a shoter once solved the problem.

 

Computer signals are typically fast pulses which means that you need to have a good quality cable and properly designed system for the pulses to be received as intended. Short cables are always preferable to long cables because the signal does not degrade as much. Short pulses with fast-rise edges will become mis-shapen long pulses with slower-rise edges as they are sent down a too long cable. This is why systems have a cable length specification. Note that one of the things to try with a problematic USB drive is to use the rear ports of the machine rather than the front; the front ports likely have an extra foot or two of cable.

Plugging in two devices could cause various conflicts but it wouldn't be easy to say exactly what the actual problem is.

 

I discovered that a USB enclosure compatibility problem may not always manifest itself as a plain go/no-go situation.

After using all known precautions (disconnecting every other USB device, plugging into rear port etc.) my previous enclosure would be seen in rescue environment, would let me validate the image stored on it and would let me select the image for restoration, but the drive would stubbornly refuse to show up in the drives' list as a destination option (the internal HD being the source in that instance). And it wasn't a capacity issue, it would be listed quite normally with TI running from Windows.

 

It's absolutely incredible to me that Acronis has this slimy excuse for validated discs failing at restore time! I have NEVER had a successful image restore (individual files yes, not entire image). I verified CDs many times, these are new CDs, plain vanilla computer, and yet it always fails on some CD that supposedly verified. What's the point of verifying a CD set if you can't be assured that it will restore? If the verify sequence is only a subset of the restore sequence, what joke is Acronis pulling to give us poor sap users a false sense of security that a restore will actually work?

 

The response by seekforever

is correct in terms of purely technical considerations.

However, this is one of the reasons why computer systems deploy buffers. The software that is being used to perform a specific task (in this case TI9) sets up an area in RAM where it writes > verifies > reads data. Buffers to a very large extent are the "magic pill" that makes the whole thing work. Almost every component within a system will have different bus speeds and consequently data throughput. Without the buffer there would be chaos.

Even with buffers, errors can potentially still occur. That is why software like TI9 or Windows Backup always include a verification utility. This is the insurance that the data is good.

I am having great difficulty in understanding how TI9 can in the first instance verify an image and pass it as OK and then in the very next action partially restore the image and then terminate the process because the image is "corrupt". And then immediately afterwards verify the exact same image as being OK... !!! The mind boggles

Either the image is good or it is bad it cannot be both.

There are too many posts on this Forum where supposedly "good" images will not restore because they are corrupt.

It is not - in my view - acceptable to put the blame on USB devices or cables or bus speeds or anything else..... If the system is rubbish then TI9 should NOT VERIFY THE IMAGE. Fail the image. Tell the user that their system is rubbish (I tell my customers that when necessary).

But if TI9 accepts a system configuration, creates an image and then verifies an image, it is then totally unacceptable if immediately afterwards TI9 refuses to restore the image because it is "corrupt". (And if immeditely checked again verifies the image as being OK !!! )

This does not give the user confidence in the product.

 

The question I was answering was whether or not cable length can matter and my explanation dealt with that. Buffers are used to increase speed (buffer can be filled while other things are happening) and to rectify mismatched input/output speeds but if your cable is too long or poorly built the buffer does nothing for the mishapen pulse problem.

I quite agree that if the image validates it should be OK during the restore and it certainly does erode confidence when it doesn't behave that way. Since I don't work for Acronis I have no idea of under what circumstances the corrupt image message is generated during a restore. All I know is that when the archive is validated outside a restore, the program calculates a checksum or checksums and this result will cause the message to be produced if bad.

Doing a restore is not exactly the same as doing a validate since the destination disk is being created. Does the message mean that the internal contents don't make sense to TI or is it just the checksum now giving an error? There is also more traffic in the computer because of the writes as well as the read when doing a restore. Is this uncovering some marginal hardware? Maybe.

I don't have any magic answer for why images pass and then fail. All I do know is that TI really loads memory and disks systems and if the hardware is not in top shape it isn't going to work. I have no idea to what extent motherboard architecture influnces the success rate with TI either because of hardware design or TI program design. All my MBs are Asus and it works well with them but I also tend to restore strictly from internal HD. If somebody is having trouble the first thing they should do is see if the problem persists using an internal partition since this rules out the additional problems of optical disks and USB chipset/drivers.

 

Thanks for your feedback seekforever

Words of Wisdom from one who is obviously more patient (and probably wiser) than I.

 

I would hate to find out my image couldn't be restored after it was validated OK.
This may be paranoia, but would it make sense to have both major imaging products (Acronis and "the other one") back-up my system at different times, just in case?

I've used Acronis for years and thankfully only needed to restore once--but it worked when I needed it to.

 

Hello Tabvla and Long View,

Thank you for choosing Acronis Disk Backup Software.

Please accept our apologies for the delay with the response.

First of all, please make sure that you use the latest build (3633) of Acronis True Image 9.0 Home which is available in the Product Updates section of your account at Acronis web site.

You can find the full version name and build number by going to Help -> About... menu in the main program window.

To get access to updates you should create an account then log in and use your serial number to register the software.

Please uninstall any previously installed build by following Start -> Settings -> Control Panel -> Add or Remove Programs -> Acronis True Image, prior to installing build 3633.

Note that you should create new Bootable Rescue CD after installing the update.

If the problem still persists then please boot your computer from Bootable Rescue CD created using the latest build (3633) of Acronis True Image 9.0 Home with "acpi=off noapic" parameter as it is described in Acronis Help Post and try to restore the image located on the external UBS hard drive once more.

If that does not help either then please try to use the next tips in order to solve the problem you encounter:

- Try unplugging all unneeded USB devices prior to booting the computer from Bootable Rescue CD;

- If your external USB hard drive is connected to the computer through a HUB then try connecting it directly;

- Try using another USB port(s).

If nothing of the above helps then please create Acronis Report as it is described in Acronis Help Post.

If your computer is not bootable at the moment (e.g. system crash occurred) then please create Acronis Report in the way described below:

- Download Acronis Report Utility and run it on any "healthy" computer;

- Select the "Create Bootable Floppy" option;

- Insert a blank floppy disk in the A: drive and proceed with creation of the bootable floppy;

- Boot the computer having the issue from this beforehand created diskette and wait for the report creation process to finish;

- Collect the report file from the floppy.

Please keep your external USB hard drive connected while creating Acronis Report.

Please also provide us with the following information:

- Let us know the exact vendor and model of your external USB hard drive;

- Are you able to successfully validate the image in question by means of the embedded Validate Backup Archive tool both when the latest build (3633) of Acronis True Image 9.0 Home is running from under Windows and when your computer is booted from Bootable Rescue CD create with the latest build (3633) of Acronis True Image 9.0 Home?

- When exactly do you receive the error message stating that the backup is corrupt?

- Describe the way you restore the image in detail;

- Copy the image in question from the external USB hard drive to any other location (e.g. any internal, external or networked drive) then try to validate\restore it once more and inform us about the result.

Then please submit a request for technical support with the subject indicating that you want to contact Alexey Popov. Provide the report.txt file and information collected in your request along with the step-by-step description of the actions taken before the problem appears and the link to this thread. We will investigate the problem and try to provide you with the solution.

Thank you.
--
Alexey Popov

 

Hello Alexey

Thank you for your detailed reply. As always you have provided good support information - and I compliment you for that.

However, I think that the major point is being overlooked. If TI9 has accepted the components of a system and has verified an image then it is essential that TI9 restores that image. All the potential failure areas need to be checked before the restore stage.

When I tell a customer that they should include Acronis TrueImage as part of their backup strategy, all they want to know is whether it is 100% reliable and whether they can do it for themselves. You must remember that my customers are non-technical - if they were technical they would not need me. To persuade a customer to implement Acronis TrueImage I need to show that once I have installed the product and given the customer a couple of hours of tuition, they will then be able to backup and restore their system without the need to employ me. And that is the way it should be.

But take your response as an example. None of my customers would be able to do any of that, therefore they would need to call me. Your "solution" is potentially a lot of work which means a lot of expense for the customer, not only in terms of my charges but perhaps more importantly the potential down-time of the customer systems.

Inevitably this brings up the question from the customer "....What benefit is there to me of using a 3rd-party backup utility rather than the one included with Windows which is simple and reliable?...."

Sometimes it is very difficult to answer that question.

 

Hello Tabvla,

Thank you very much for your kind remark. I'm always at your service

Yes, I do understand this. Moreover, I fully agree with your viewpoint. However, this problem is unknown to us and therefore requires a deeper investigation. In general, there are two possibilities available: there is a hardware-level problem with device where backup archive is stored or there is a problem with Acronis True Image itself not allowing the program to do a reliable validation. Obviously, something different happens when Acronis True Image validates this particular backup archive and when it restores it. Otherwise, the results would be identical. Probably, some internal errors occur during the restore procedure causing "archive corrupted" error message to appear (e.g. some hard drive I\O errors). Whatever the case, it needs an additional clarification. So, if you want us to investigate the problem then please provide us with the information I have requested.

Thank you.
--
Alexey Popov

 

Hello Alexey

OK. I will talk to the customer and do some further investigation. The customer won't pay for this so I will need to do it when I have some time available.

Whatever the outcome I will get back to you with a result.

 

In reply to Alexey of Acronis Support and for those who may be interested.....

The issue in this thread was that a critical system image would not restore even though TI verified the image and other disk tools verified that both the source and destination disks were OK.

The problem has been resolved but not to the customer's satisfaction.

The setup was that the customer had 2 external USB disks. The intention was to use USB_1 disk as the Backup disk, where all TI9 images would be located and USB_2 disk as an emergency bootable system disk containing the OS and the programs. The purpose for this setup was to ensure that the customer could be "up-and-running" very quickly in case of a catastrophic system failure - something which is important to this customer.

TI9 had no problem in creating and verifying the system image on USB_1 disk. The problem was in restoring the system image to the USB_2 disk. The restore would start and run for about an hour and then terminate with the message that the source image was corrupt.

The "solution" was to restore the image from USB_1 disk to an internal disk rather than to the USB_2 disk. Under this setup the image restored without any problems.

It is almost impossible to find a logical reason why the image will not restore fully to USB_2 disk but will restore without any issues to an internal disk. Obviously the image is not "corrupt". So the error message is not providing any useful information to determine the exact cause.

Perhaps Acronis Support could do some tests to determine if there is a generic issue within the software that results in incomplete restoration when an image is restored from one USB drive to another USB drive. If this is an issue then either it needs to be addressed in a future build or a note needs to be added to the User Guide telling users not to attempt USB to USB restoration.

TiA

 

Hi Tabvla,
I have come across this kind of problem when transferring data form one USB drive to another. I had a Windows message on failure that the operation was at "Too deep a level" and it had to be aborted. They were 15 GB files which happened to be .tib files but I am certain that this was a Windows limitation and had nothing to do with TI. This may be of no relevence to your customer's problem but it may be worth checking out.

The solution I have adopted to speed up the whole of the imaging process and to have a replacement hard drive " ready to go" is to use exchangable hard drives.
I leave USB hard drives out of the equation altogether.
Images are stored on a slave drive and after one is complete the hard drives are swapped and a restore is made to the replacement drive. So there is an updated drive in the computer and its "twin" at that point in time that can be inserted to take care of any Hard drive disaster that may happen.
Under Windows and True Image internal drive working is a lot faster than to USB drives. There are other advantages such as, Image validation is no longer needed and there is no time consuming cloning.There is also the considerable advantage that each image is Proved after its creation giving the ultimate in security. The time taken to do an actual restore after imaging is less than that when validating.

Xpilot