Problem with TI-10 Home

Hello all, I hope you can help:

I recently purchased my first Acronis product TI-10 Home, retail and things were going great. I'd do seperate images of C: and D: (partitions on the same IDE physical drive) to a separate 80GB IDE internal drive used only for games and images. I'd turn on the "verify after image" and both worked great.

Wanting to save some time and begin to experiment with more of the features, I tried doing a full system backup, dropping check marks on the C: and D: drives (leaving E: blank of course) and of course I wanted the image verified. Well, it failed verification. So, I tried exactly the same thing again after having deleted the supposedly flawed image, it too failed the automatic verification. Being curious, I tried the verification process manually, and that same image that failed the auto test now passed?

Obviously I'd like to have the auto-verify work, but more important this instant is, is the image I have truely good? I'd experiment with a restore but I'd be livid if it failed and I had to re-install everything for no good reason.

Any tips, clues, hints? Like I said, the most important thing is determining if the image that failed auto-verify but passed manual is good or not, I can "work around" (not do auto but do manual following completion) it for the time being, but the final goal is to figure out what it takes to make the auto process work so I can do an scheduled image in either incremental or full mode.

One last hint: I originally started with a 30GB drive since this is a spare machine and I didn't think I'd be putting much on it. Well, that changed in a hurry, so I used one of the TI-10H images to restore to a partitioned 160GB drive and it seemed to go perfectly. Could this "upsizing" have messed up something with the original TI-10H install?

Thanks much,

Varmint

 

Probably not, but run CHKDSK /R on both partitions and see if it reports any problem.

After that, if you repeat the imaging of just one partition with auto-verify on, do you still get a good automatic as well as manual verification?

 

Thanks, chkdsk reports no issues, I should have mentioned I tried that before posting.

I did notice I need to update, but the service is unavailable at this time (as I've seen posted on other threads).

Like I said, I'd be happy to know if the image I have IS good, that only the first requirement though.

To be clear auto-verify as part of a backup job fails, manual verification of that exact same image completes without errors.

Varmint

PS: Going to image C: alone to test it as you suggest. Thanks again (edited by Varmint)

 

Update: imaging C by itself worked fine (auto-verify). I tried D with auto verify and it failed, tried it again and it passed. Still, every image that has failed auto-verify passes manual, so that's got to be a clue of some sort.

I'm going to do an extended ram test (maybe 48 hours) to see if the RDRAM is buggy.

Varmint

 

The eratic behavior is very annoying. Some autoverifies succeed and some fail. I wonder if you have some application or service running in Windows that is confusing TI.

You should also try booting from the Recovery CD and try verifying in the Linux environment. If the files all verify there, then I'd bet that they are all good.

You can also try mounting some of the files which failed the autoverify. If you can mount the backup image, that's good proof that it is a valid image.

Is there any unsual software or hardware on your computer that might be the source of the problem?

 

John, thanks for the reply.

OK, here's the rundown of my latest activities with TI-10. I was able to get the 4942 update and installed that over the top of the retail CD install on the machine. Just for curiousity I did another image of D that auto-verified fine, passed manual fine. I did the same image again, it failed auto but passed manual. So, no concrete change between the older retail version and the newer 4942 so far as this issue goes. I did have one manual failure out of all of this playing around, so I rebooted the machine tried again and it passed. Arghhh!

I booted from rescue media (CD created from 4942 build install, was happy to see the menu choice for "safe" and "full" since I selected both, very nice!), and verified all of the images I had. All were OK.

Since then the machine has been on memtest v1.70, 637 passes without any errors. Yes, the first pass or two matter the most, but I really want unquestionable confidence in the hardware/memory since the system is about 4.5 years old (2.4GHz non-HT P4, 512MB RDRAM, Gigabyte 8IHXP MB) and has seen some major use during that time. I'll stop the test after I finish this post, obviously it's churned enough memory butter to expose any oddities by now.

I'll close with the following, I hope someone else picks up on a pattern I'm not recognizing:

Never once have I had a failure to auto-verify an image of C: alone (4.22GB). Only once have I had an auto-verify of D: alone (16.78GB) fail. Every single time I auto-verify an image of C: and D: imaged as a set, it fails far enough along in the process that I know for certain it's the D: portion of the image that is the problem. CHKDSK has been run a total of 5 times (wow that takes some time!) and never once did it issue any warnings or do any repairs on either partition. C: was chkdsk'd once, D: was chkdsk'd three times, and E: was done once. Cabling is premium round shielded 80 pin cable for all drives, IDE0 is configured as 160GB master (C and D), with a Sony DRU-830A as the slave, IDE1 is a solitary 80GB on a single drive round shielded cable (80 pins of course) jumpered for Master/Single (jumper moved to unused pins per WD instructions).

As for services interferring, I'm pre-disposed to discount that as any service would likely affect C: more than D: since C: is the OS, and D: is largely my MP3's, litle movie clips, and that sort of data only stuff. The only even remotely system oriented thing I can see on D: is that's where the SP2 unistall files were saved. Oh, system restore, recycle bin, and indexing are all turned off, if restore killed (removed) the stuff that caused me to want to restore I'd use it, but leaving the "junk" in place as well as the every growing libraries of restore points is an unwarranted source of disk space growth that serves no meaningful purpose for me, thats WHY I use Images!

Thanks for the input, I sure want to get this working to the point to where I can have 100% confidence in an unattended scheduled image of C: and D: to E:!

Varmint

 

Hi Varmint,

Excellent testing. I can't see any reason for the behavior you are getting with autoverify failing sometimes. The backups are certainly good, and the verification from the Recovery CD is the most important since that's where you will be to restore the boot partition.

So far, no one else has chimed in with "I have the same problem.", so it looks like this is not common. That points to it being something specific to your machine but not a drive or memory problem.

Is there any possibility that a screen saver or power setting is kicking in during the longer backup and autoverify when you do the two partititons together?

How about an antivirus that interupts the process? You might try the autoverify with your AV off.

Do you have any external devices that might be accessing the system and confusing the autoverify?

Finally, some motherboards have problems with very large files. Obviously, the combined image is larger than either partition alone. You could try splitting the image so that it is not one huge file. Split it so that the pieces are smaller than either of the individual partition backups, perhaps 1/4 the size of the full backup.

I hope you can find the underlying cause of this odd behavior.

 

Varmint,

Aside from John's suggestions, do you have a BartPE boot cd you could try?

If you do, it would be interesting if the auto-verify function worked correctly when you do the backup from it. It uses Windows, but it's very clean and no other programs are installed that may cause problems. If it worked correctly from the BartPE cd, then you could figure that there is something in your current Windows setup that is causing the problem. If it fails from the BartPE cd, then it's probably a weird hardware problem.

 

Sorry to be getting back so late, when people are helping I hate to leave them hanging, please accept my appology.

Well, I ran into another issue on the machine, something went awry during a game install and it killed my menubar appearance. It looks to have turned every "pretty" feature -off- permanently, I had a grey start button and menu bar, all the "make it ugly but make it fast" stuff was done it seems. Well, pardon me but I do like it "pretty". Accordingly I just killed it all, didn't even bother going back to an image, and reinstalled XP and SP2 hoping to get a squeaky clean install.

Right now: XP, SP2, Intel INF, AC97, NVidia 93.71 for the 7800GS video, Acronis TI10-H 4942, literally that's all that's on it now, the D: partition and E: drive were killed at XP install (remove and recreate partioned space) so there was NOTHING left on either. Once the machine was up I formatted (NTFS long of course) the D: partion and the E: drive using admintools/diskmgt.

I just formatted a 5X DVD-RAM and imaged to it with verify checked. As you know by now, it failed, but in an unusual way. Went TI10 asked where I wanted it to image to, I clicked on the DVD drive, asked it to make a new folder, then typed the name of the image at the end of the line as always. Well, the verify failed complaining about not being able to find the individual archives. I browsed the disk in XP and the image was created at the root of the DVD-RAM, not in the folder that was also created! So, I did a manual verify of that image and it passes! I guess that's good but it sounds already like a BackToSquare1 issue. Yes, I realize the DVD-RAM is a new twist so it might not be fair to say nothing has changed until I do the images to the internal E: drive but I'm trying to mention EVERYTHING so that I don't discount the one detail that might solve the problem.

Thanks guys, and I'll be doing a bunch more during the day today (Windows updates, etc) then I'll get back to internal HD to internal HD imaging to see if anything has changed.

Varmint

 

Hello Varmint,

Thank you for choosing Acronis Disk Backup Software.

We are sorry for the delayed response.

Please download the latest version of Acronis drivers, unpack the archive, install unpacked MSI package and see if the issue persists.

If the issue persists, please collect some information necessary to investigate it thoroughly:

- Replace C:\WINDOWS\system32\snapapi.dll with the one from the downloaded SnapAPI archive;
- Reproduce the issue and collect the log file without closing any application windows (including the error message windows if there are any). The log file will be created at C:\ . The name of the log file will be snapapi [date-time].log

Please create Acronis Report and Windows System Information as it is described in Acronis Help Post.

Please also collect the application log of the operation:
- run the program;
- select Show log on the toolbar or from the Tools menu;
- select the log with error messages;
- click "Save the log entry to file" (the diskette icon).

Then 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 problem appears and the link to this thread. We will investigate the problem and try to provide you with a solution.

As for backing up to DVD-RAM media, please be aware that while DVD-RAM media allows similar to hard drive read-write operations (like creating folders), backing up to DVD media always creates the file in the root folder of the media. So, as the verification was pointed to the folder you created, it failed to find the backup file.

Please be aware that a successful validation nearly always (exclusions are negligible) means that the backup is consistent (i.e. data it contains is the same data that was read during the backup process). On the other hand, validation failure can be caused by many different reasons (even 1 faulty transferred bit matters). Please also notice that Acronis Bootable Rescue Media runs in a Linux environment (full version), which handles hardware differently from Windows. The successful validation from Acronis Bootable Rescue Media is what matters the most, as the system restore is usually carried when the system cannot boot by itself.

Thank you.
--
Marat Setdikov

 

TI 10 Home build 4942

I had this problem with file-backups. Turned out to be all System Volume Information folders. If I exclude (uncheck) these folders, file-backup validation completes OK.

This problem persists with drive-backups (drive images), of course, since you cannot exclude anything. I just do not validate drive-backups.