Unexplained error comparing files, Windows Multi Server v7

[jkbull]

I installed the time-limited trial version of Retrospect 7 Multi-Server on a Win2K Server. It consistently gets "compare errors" on the same 20 files out of our 12GB of data. The files are all .jpg except for three .eps files. (We have a lot of .jpg files, but not very many .eps, if that's a clue.) The files are not in use or being modified, and the errors always occur at offset 128 or 129. Here is a typical Retrospect log entry with the error:

 

File "F:\mim\MindsInMotion3.JPG": didn't compare at offset 128 in stream

":Q30lsldxJoudresxAaaqpcawXc:DATA"

 

 

I tried several different things. The problem still happens:

* Whether or not it is the original file or a copy.

* Whether or not the file is compressed via Win2K compression.

* Whether or not the file is on a Win2K-software-mirrored volume.

* Whether or not the Retrospect backup is done with compression.

* Whether or not the IDE controller is in PIO or Ultra DMA mode.

 

To try to isolate the problem, I took one of the mirrored hard drives containing the system and data volumes (on different partitions) out of the server and put it in an identical computer (except with 512MB RAM instead of 256MB, and without a CD-ROM drive) that we use as a workstation. Exactly the same problems happened. This with everything different except the software and the disk drive. Then I tried the _other_ mirrored disk drive (different manufacturer and size) and the problems _still_ happened!

 

The only thing I've tried that didn't cause the error was to try to back up, to the same server, a copy located on a Retrospect client computer. That worked fine.

 

Is anyone aware of issues with Win2K Server, Retrospect, or Intel D850GBAL motherboards with a 1.7GHz Pentium 4? The Win2K is fully up-to-date with all patches and drivers, and the BIOS and Intel drivers are also up-to-date.

 

Any deas?

[natew]

Hi

 

You may have tried this but just to be sure:

 

Copy the problem files to another physical disk or a network share, delete the originals then copy them back. Do the errors still occur? (if possible, defrag the hard disk before you copy them back)

 

I don't think it is a problem with hardware. Chances are the filesystem or inode information for those files is incorrect. As a result they get misrpresented to Retrospect during scan/copy/compare. I would still guess Retrospect is probably backing them up properly.

 

Believe it or not a disk defrag can sometimes help with this. It works because it rewrites the files to new physical locations on disk.

 

Thanks

Nate

[jkbull]

Thanks for your response. I wasn't able to try your suggestions immediately, but now I have.

 

From another computer X, I copied the problem files from the server to X's C: drive via the network, deleted the originals, and copied the copies back to the server. The problems still happened.

 

I defragged the drive (although I had done this before). The problems still happened.

 

I restored, to a different physical disk (an external USB 2.0 hard drive) and compared (with the command line "FC" command) a few of the restored files to the original "bad" files. They matched. This meant that the Retrospect "backup" operation was working; the error occurred during the "compare" operation.

 

I tried backing up the restored copies. The same problem still occured.

 

I emailed myself the files, and downloaded new copies from the emails. ***** THE PROBLEM WENT AWAY! *****

 

So, it is apparently something in the file "metadata" that is preserved by Windows when copying from one disk to another (even to/from a network share), and is preserved by the Retrospect backup/restore process, but that isn't preserved by emailing the files as attachments. Something in the metadata interacts with something in (my copies of) Windows or Retrospect, or the CPU, memory, or some part of the I/O system of the computer.

 

Well, it was interesting, and I have a way around it (replace the bad files with copies created via email. It still makes me nervous, though!

 

Thanks again for your help. Without your comment about the "filesystem or inode information" I wouldn't have thought to strip it away by using email.

 

If anyone from Dantz wants to look into this further, I could email a copy of a backup set whose restore will exhibit the problem. Just email me with instructions.

[seanbreilly]

Just a followup to this - I am getting this exact same error on a .jpg at the same offset.

Everytime I try to do a duplicate, this one compare fails on a set of 28000+ files, even

after resaving the .jpg, recopying, disk checking, defgragging. Weird.

 

- Sean