Corrupt images: is it a software or hardware problem?

I've been using TI9 for months without problems. I always make my backups from the Rescue CD and validate them after creation. I create the backups on an external Maxtor USB hard drive.

Last night I tried to create a differential backup based on the last full backup. TI reported that the backup files on the external drive were not TI backup image files and would not proceed with the backup.

I rebooted into Windows and began a Validate procedure and got no error messages (I didn't run a complete validate; I just wanted to see if TI in Windows would report that the image files were not TI backup images.

Then I erased the old backups and ran a full backup. When I awoke this morning I saw that there were erros during validation -- couldn't read certain sectors on the hard drive. Right now, I'm running a full Validate from within Windows; no errors so far and it's more than half done.

How likely is it that this external hard drive has gone bad all of a sudden? Or is it more likely that there is something wrong with TI9? I was surprised by the error messages because the drive always worked fine with TI9 - no driver problems in the past; the Rescue CD recognized the drive the very first time I tried it and every time since then. Speed has been good, too. (I'm wishing it's the hard drive going bad because I have a new, bigger one on order and that would eliminate the problem. Still, in my experience it's unusual for bad sectors to appear out of nowhere.)

 

Brief update: I ran the Validation in Windows and it completed successfully. So I have a situtation where Windows can read the backup with no problem, but the Rescue CD can't -- even though the Rescue CD created the backup. Of course, it's more important that the Rescue CD be able to read the backup because if I have to do a restore, I will be doing it from the Rescue CD.

I'll try validating again with the Rescue CD.

 

If I were you I would create another FULL backup right away. Personally, I never use incrementals or differentials .... they just give True Image another reason to hiccup.

 

That's what I did after getting the first errors -- created a new FULL backup. That backup led to the validation errors with the Rescue CD but not with the Windows version of TI.

I'm going to try a second validation with the Rescue CD when I get home; if that fails, I'll do another full backup. But this isn't encouraging.

 

Since you have had good luck running with the Rescue CD up till now, and the HD seems to be OK it rules out the infamous Linux driver issue. I'd wonder what has changed. Since it is a CD version issue then that pretty well rules out the Windows OS.

I'd run memtest86+, free from www. memtest.org. Overnight is best for increased confidence. The rescue CD is not using the same memory allocation as the Windows version so it could be there is a bad bit in a critical area. If you have more than one stick of memory and the machine will run on one at a time you can try them separately and see if it helps. You just have to eliminate possible causes.

I wouldn't say bad sectors don't appear out of nowhere. All it takes is for the head to come down and bad sectors are created. Next time that portion of the disk is accessed you see bad sectors. This problem is much more likely with an external drive since they get bumped more than an internal. The drive manufacturers will tell you the major risk to disk drives is shipping and handling.

 

It has been telling me there are bad sectors on my hard disk. I don't believe a word of it.

 

That's what I thought. Also, FWIW, I am already running build 3677 (the only build I've ever used). In addition, I just tried a Validation once more using the Rescue CD; it reported a bunch of bad sectors that it couldn't read, and then reported that the archive is corrupt. (This is the same archive that passed validation when running Validation from the Windows version of ATI.)

However, my research in this forum in connection with this problem raises a question. It appears that the validation process can give both false positives and false negatives; i.e., a backup can pass validation even if it's no good, and it can fail validation even if it's fine. If that's the case, (a) what good is validation, and (b) how can anyone ever know whether a backup is good?

I am getting very frustrated with ATI. I will run Memtest overnight, but I will not be surprised if there are no memory errors tomorrow morning. I am also running CHKDSK on the external drive. And my new external drive should arrive in a day or so and I can check ATI with that.

Of course, I have to cross my fingers and hope that nothing goes wrong with my primary hard drive in the interim, because if something should happen, I will be backup-less, despite having spent money on ATI. I just adore throwing money down the toilet.

 

There does seem to be more reports of problems with TI reporting bad sectors than usual. If it were TI10 I would be suspicious but it is TI9 which has now been around for a while.

I had a bad sector report with TI9 myself the other day but chkdsk confirmed that there was a bad spot on the disk.

 

I created a BartPE disk with the Acronis plugin and ran a Validate again -- and this time it passed with no errors at all, which suggest that there aren't really any bad sectors on the external hard disk.

Does that mean the backup is OK and the external disk is OK?

This is weird. Let's see what Memtest reports tomorrow morning.

 

Memtest ran overnight - no errors reported. What should I conclude about mr system and my backups (and my external drive)?

 

Welllllll, we aren't dead as long as we have one more thing to try!

I'll reiterate my understanding:
You have always used this version of TI.
You always boot up the rescue CD to create and normally validate the archives.
This worked well before but now has started to fail.

Did any hardware get installed/replaced between the time it worked and stopped working?

Did anything in the BIOS get changed?

Have you tried different USB ports? Preferably,ones on the back of the PC which tend to have shorter cables.

Take the external drive out of the picture by making an image to another partition on an internal drive. Do you have a second partition that can be used? If not, and space is available, you can make an image within Windows to the same partition. Ignore any warning message. I don't know if you can do this from the CD version. Once you have this image will it validate?

Try another external drive. (Not just the drive but the external box/usb interface as well.)

Try your external drive on another PC with the TI boot CD.

Even though you ran memtest86+, if you have multiple memory sticks, can you run one at a time? The diagnostic doesn't run in exactly the same environment without disks running.

 

Correct!

Nope.

Nope.

I haven't tried switching ports, but I've always had the external USB drive hooked up to a port on the back panel of the PC (direct to mobo, rather than through a hub).

I don't have room on the internal hard drive for a full backup. I do have room on the E: partition for a backup of C: so I can at least try that. However, since the external backup validates using either Windows or BartPE, I would be shocked if an internal partition didn't validate if I did the validation within Windows. If I did that validation with the Rescue Cd, then things could get interesting.

Conveniently, my new Western Digital MyBook 500 GB external USB/Firewire drive arrived via UPS today. I'll try a backup overnight with the Rescue CD. If it doesn't pass validation, I'll try it again with BartPE.

Unfortunately, I haven't got another PC to try with. My other computer is a Mac.

I'll give that a try as a last resort, just to avoid opening up the computer and playing with the memory.

Ultimately, of course, the goal is to achieve dependable, reliable backups, so if I can accomplish that using the BartPE/plugin disk instead of the Rescue CD, that won't be too horrible.

[As an aside: my understanding is that Firewire causes fewer problems with ATI than USB. Since the new drive has both interfaces, would I be better off using Firewire? (I'll have to spring for a Firewire card because the mobo doesn't have on-board Firewire, but I don't think that would be prohibitively expensive, and if it makes backups more reliable it would be money well spent.)

 

If you can get it to work reliable with BartPE that certainly wouldn't be too horrible. A guy I used to work for used to say, "You can't argue with success." when something worked that we didn't think should work. I would still find it a bit troubling that what used to work on your machine doesn't and I would be waiting for the other shoe to drop.

I have seen posts where USB and FW drives would work on one port but not the other. Some had luck with USB and some with FW so I wouldn't give a definitive FW is best answer. FW is much faster than USB1 but not very much faster than USB2.

 

Hi seekforever,

I'm probably splitting hairs here, but in terms of maximum theoretical speeds Firewire is slower than USB2.0. In real terms I expect the difference in negligible.

F.

 

Yes, you are correct for FW400 which is 400Mbits/s theoretical vs 480Mbits/s theoretical for USB2.

My reading indicates that when you get to sustained real-world transfers FW is a bit faster but even this is uncertain because it is determined by the implementation in the interfaces. I recently found that USB2 supposedly uses the CPU much more than a FW interface which would put another variable into the mix.

Like you said in real terms the difference is negligible.

 

I tried a backup last night using the Rescue CD and the brand new external hard drive. It failed with write errors.

Then I tried it using BartPE and it backed up with no errors and validated afterwards.

Later today I'll try backing up and validating internally using Rescue CD. If that fails, then I guess the problem has got to be with the RAM. If it works, then it might be the USB Linux drivers (although that doesn't explain why it used to work).

 

You are on track and hopefully it is the right one.

Was it a general write error or a "delayed write" error? Did you get a lot of them? Is this different behaviour than before - you were reporting validation errors previously?

If it isn't something like RAM or other HW then it is indeed a mystery why it used to work before.

I almost want to suggest you create a new TI boot CD although if the other one went bad it should have reported a problem on loading. Maybe save this one for later so we still have "One more thing to try".

 

Yes, previously the errors were at the validation stage; this time it was while doing the backup. And I believe it was a "general write" error rather than "delayed write" -- there was no mention of delayed write in the error message.

A few minutes ago I ran a backup of my C: partition onto my E: partition (all internal) using the Rescue CD (on the theory that if the Linux OS was revealing a problem with RAM that Windows didn't reveal, it would show up). The backup ran with no problems and validated with no problems. (I was almost hoping there would be some errors because it would at least point to a solution/diagnosis.)

I think I will try the same thing again a couple more times just to see if some errors pop up.

Are there any memory diagnostic tools that might reveal a problem that memtest doesn't?

 

There certainly are other diagnostics available but I can't give you a name.

My experience is that a marginal memory problem is more likely to fail in the "random" test rather than fixed pattern tests like "walking ones". So if you want to try that you can have memtest execute only the random test overnight which will give many more passes through that particular test.

Based on your last test, although it may have just been lucky that it worked, one might suspect the USB system. Even though you used a different drive, did you use any of the same cables? There is also a different port issue but if the problem is something failing in a common chip then changing ports may not show anything.

 

sorry, just ignore, wrong post. rgds

 

I say software issue. Same thing happened to me, USB hard drive plugged directly into the server I was restoring to. The backup was performed in this exact same hookup. When I tried to restore, I got a message telling me that the image was corrupt. I took the hard drive and plugged it up to another server with TI9.1 and was able to read the image just fine within the OS GUI. When I took the image and copied it to a network share and performed the restore, WALLA, it worked...

I contacted support, have not heard anything yet...

 

I certainly can't say it isn't a software issue. However, I don't see reading the USB drive on a different machine and restoring it by a different mechanism a definitive way of ruling out hardware.