Jump to content

Files do not compare


Recommended Posts

I just upgraded one of my clients from Retrospect v6.5 to v 7.5. Much better. Except now I get 68 errors on the server every day. These errors are user files (not system files) that "do not compare." These files are usually pictures or AutoCAD documents. Why would they suddenly begin failing verification? What would cause a file to suddenly "not compare" when this wasn't happening prior to the upgrade?



Link to comment
Share on other sites

Mattzees, can you email me one or two image files having this problem? Our engineers are having a hard time finding a reproducible configuration.


If you can .zip up a couple of files and email them to me at emcinsignia_forums@emc.com, it will help us get this issue fixed faster.


Did the files originate on Windows or were they originally created on a Mac? If so, how did they get copied to Windows?

Link to comment
Share on other sites

Hi, I'm following this thread too as I have the same problems with graphic files (ai, eps, psd, jpg, etc, although also with the occasional doc and other non-graphic file).


I found the suggestion to turn off MD5 digests didn't work and I still got all the "didn't compare" errors (between 100-250 each night).


However, turning MD5 digests back on and then going to the scripts and changing from Thorough Verification to Media Verification removed all errors completely on last night's backups, save the usual few I'd expect to do with sharing violations on active OS files on our Windows system drives.


So it seems to prove the MD5 digests are a true reflection of the contents on the tapes, but a direct comparison with the original files fails. Obviously successful comparison with the digests doesn't necessarily mean the tapes hold the correct data - it could just mean that the tapes and digests have both recorded the original data incorrectly.


If anything, you'd always expect direct comparison to be the most definitive check on the data integrity of what's been written to tape - and that's what's failing.


Anyway, hope this gives some additional clues for your engineers.

Link to comment
Share on other sites

We are still looking for a few examples of files that will reproduce the issue. I could not reproduce it with mattzees' files.


Feel free to send me a couple of problem files to emcinsignia_forums@emc.com




Is it possible that the folder structure might have something to do with it? Some of those files were buried many folders deep.




Link to comment
Share on other sites

  • 4 weeks later...

Verifying the MD5 digests has been successful for us, so I'm not getting any errors anymore. Thorough verification will still bring errors back, though.


Is it possible to get an answer regarding how "bullet-proof" it is to verify just against the digests as opposed to thorough verification against the original files?


Trying to decide whether we need to prioritise resolving the problem with thorough verification.


If you still need example files, I can try and dig up some by referencing the older logs when we were getting the errors on thorough verification. Let me know and I'll see whether we can release them (confidentiality, and all that).



Link to comment
Share on other sites

We have reproduced the problem and we are working on a code fix.


MD5 verification is very safe. I give you an exact value of reliability. Byte for byte verify is 100% identical to the original file. MD5 doesn't look at the original file.


I am sure a google search can provide more detail on the specific reliability of MD5 hash verifications, the process is not Retrospect specific.

Link to comment
Share on other sites

  • 2 weeks later...

A few weeks ago, EMC Insignia announced the Universal Client Beta #2 for Macintosh. Today this beta is being updated with a new beta version of the Retrospect for Windows Application. Universal Client Beta testers will want to replace 7.5.513 with this new update. Beta testers should continue to use 6.2.222 Client beta and Retrospect 6.1.222 Mac application data.


This beta update is version 7.5.516 for Windows and contains some important bug fixes for Windows users of Retrospect.


Changes Since 7.5.513 beta

-Fixed a "file didn't compare" error for .jpg and other image files.

-Fixed an MD5 verification error when spanning backup disks. Reported by Jason Z.

-Fixed a long standing -540 error with Linux Clients.

-Fixed a problem seeing mailboxes with two exchange servers in the same domain.


Changes Since Beta #1 or 7.5.508

-Fixed a hang when polling Exchange mailboxes

-Fixed a catalog out of sync error when adding members to a disk backup set

-Fixed a problem seeing multiple instances of SQL on the same computer

-Fixed a WMI Repository error when backing up Windows XP systems


This update does not require a RDU.rpx file. All prior RDU updates have been added to the 7.5.516 application


Download this beta from:




An FAQ document for this beta is found at:






We're excited about our new features and hope you will test them, but please remember to put safety first. Although we have tested these features thoroughly, it is Beta software. Please do not rely on this release for your primary backups.



Reporting Bugs



It is extremely important that you report any problems you find immediately. This ensures a final product release that best meets your needs. Please report all bugs on the Public Beta section of the Retrospect Forum.


Support for this beta product is NOT available by calling technical support. All support is handled via the forum. You will find the Forum at:




Before you can post your issue to the forum, you must create a user account, if you don't already have one. New account registration can be found at:




Users with existing forum accounts can login at:




We're excited about our new features and hope you will test them, but please remember to put safety first. Although we have tested these features thoroughly, it is Beta software. Please do not rely on this release for your primary backups.

Link to comment
Share on other sites

  • 1 month later...
  • 2 weeks later...

I have run Retrospect 7.6 for three nights now with thorough verification turned back on. Since March, we've been comparing the MD5 digests instead to circumvent the 'compare error' problem.


In the last three nights, we are still getting up to 15 compare errors per run, but that is waaaaay down from the up-to-250 compare errors we were getting back in March.


What I can't say is whether we would get the same reduction on 7.5 anyway, because of some other external factor that may have changed at source since we last tried thorough verification.


Kicking myself for not trying a backup using thorough verification again prior to 7.6 upgrade to ensure the problem hadn't changed in nature/disappeared altogether.


I could down-grade to 7.5 again to try it, if that's useful? Will this cause problems with my config files, catalogs, etc though? Don't know if 7.6 alters their structure in any way that complicates down-grading to an earlier version.

Link to comment
Share on other sites

  • 2 weeks later...

I had one JPG file that had no problems running Retrospect Single Server v6.5. After upgrading to v7.5 I started getting the "File did not compare error". A week ago I installed v7.6 and the error remains.

I made a copy of the file and the copy also fails to verify. I resaved the file and the newer version verifies OK. I have no problem ditching the original (which did not compare) but I am uneasy as this may still come up with other files.

The verification method I use is the default.


Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...