Jump to content
mattzees

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?

 

 

Share this post


Link to post
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?

Share this post


Link to post
Share on other sites
Thanks, that would be helpful.

 

The files are on their way as a ZIPped attachment to an email named "ZIP files from Mattzees".

 

Let me know how it goes.

Share this post


Link to post
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.

Share this post


Link to post
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

 

 

Share this post


Link to post
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.

 

 

--M

Share this post


Link to post
Share on other sites

It could, but I doubt it. I have a feeling our spam filters may have modified the files. I will email you FTP info to try and FTP me the .zip file.

Share this post


Link to post
Share on other sites

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).

 

Thanks.

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites

Mayoff,

 

I'm seeing the same behaviour on our 7.5 MultiServer, and especially picture files. Is there a working patch out for this problem or should i try the MD5 workaround?

Share this post


Link to post
Share on other sites

Ah, that's great news! How long would it take before a beta goes to stable release? I usually don't install betas on production-servers.

 

Thanks in advance

Share this post


Link to post
Share on other sites

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:

http://download.dantz.com/archives/beta/Retro_EN_7_5_516_1.exe

 

 

An FAQ document for this beta is found at:

http://forums.dantz.com/showpost.php?post/104247/

 

 

 

 

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

 

BUG REPORTING

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:

 

http://forums.dantz.com/showforum.php?fid/98/

 

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:

 

http://forums.dantz.com/register.php?

 

Users with existing forum accounts can login at:

 

http://forums.dantz.com/login.php?

 

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.

Share this post


Link to post
Share on other sites

Is an update that fixes the "didn't compare" errors any closer to release?

I am getting this error on 2 JPG files and also on 2 PDFs.

I am running v7.5.508 Single Server with the v7.5.14.102 update on a Windows 2000 server.

 

Share this post


Link to post
Share on other sites
It is fixed in the beta found in the forum.

I see that. Any idea when it will be out of beta? This is a production server and I'd rather not put beta software on it.

 

Share this post


Link to post
Share on other sites

Yesterday i downloaded Retrospect 7.6 that should have fixed the compare bug.

 

After running our nightly backup i can only say that the bug remains.. Same files doesn't compare..

 

Anyone seeing the same problem?

Share this post


Link to post
Share on other sites

If the error continues with 7.6, then you may have an actual problem copying the file. Which verification method are you using?

 

If you copy the file in Windows explorer and do another backup, do you get the error on both copies of the file?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×