mattzees Posted February 28, 2008 Report Share Posted February 28, 2008 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 More sharing options...
Mayoff Posted February 28, 2008 Report Share Posted February 28, 2008 The error "file didn't compare" on image files is a bug in Retrospect that we are investigating and urgently would like to resolve. You can try to turn off the option in preferences to track MD5 hash data. http://screencast.com/t/oKGpzfbcT Link to comment Share on other sites More sharing options...
Mayoff Posted February 29, 2008 Report Share Posted February 29, 2008 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 More sharing options...
mattzees Posted February 29, 2008 Author Report Share Posted February 29, 2008 Let me clear this with my client, and I'll see about getting you some ZIPped files. Link to comment Share on other sites More sharing options...
Mayoff Posted February 29, 2008 Report Share Posted February 29, 2008 Thanks, that would be helpful. Link to comment Share on other sites More sharing options...
mattzees Posted March 6, 2008 Author Report Share Posted March 6, 2008 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. Link to comment Share on other sites More sharing options...
Mayoff Posted March 6, 2008 Report Share Posted March 6, 2008 I got it and sent it to engineering. Hopefully we can reproduce the problem. Link to comment Share on other sites More sharing options...
mlenny Posted March 6, 2008 Report Share Posted March 6, 2008 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 More sharing options...
Mayoff Posted March 6, 2008 Report Share Posted March 6, 2008 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 Link to comment Share on other sites More sharing options...
mattzees Posted March 8, 2008 Author Report Share Posted March 8, 2008 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 Link to comment Share on other sites More sharing options...
Mayoff Posted March 10, 2008 Report Share Posted March 10, 2008 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. Link to comment Share on other sites More sharing options...
mlenny Posted April 2, 2008 Report Share Posted April 2, 2008 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. Link to comment Share on other sites More sharing options...
Mayoff Posted April 2, 2008 Report Share Posted April 2, 2008 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 More sharing options...
lejzer Posted April 17, 2008 Report Share Posted April 17, 2008 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? Link to comment Share on other sites More sharing options...
Mayoff Posted April 17, 2008 Report Share Posted April 17, 2008 We hope to release a beta version next week that contains the fix. Link to comment Share on other sites More sharing options...
lejzer Posted April 17, 2008 Report Share Posted April 17, 2008 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 Link to comment Share on other sites More sharing options...
Mayoff Posted April 24, 2008 Report Share Posted April 24, 2008 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. Link to comment Share on other sites More sharing options...
FuzzyJohn Posted June 19, 2008 Report Share Posted June 19, 2008 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. Link to comment Share on other sites More sharing options...
Mayoff Posted June 19, 2008 Report Share Posted June 19, 2008 It is fixed in the beta found in the forum. Link to comment Share on other sites More sharing options...
FuzzyJohn Posted June 19, 2008 Report Share Posted June 19, 2008 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. Link to comment Share on other sites More sharing options...
lejzer Posted July 1, 2008 Report Share Posted July 1, 2008 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? Link to comment Share on other sites More sharing options...
Mayoff Posted July 1, 2008 Report Share Posted July 1, 2008 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? Link to comment Share on other sites More sharing options...
mlenny Posted July 3, 2008 Report Share Posted July 3, 2008 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 More sharing options...
FuzzyJohn Posted July 17, 2008 Report Share Posted July 17, 2008 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 More sharing options...
Mayoff Posted July 17, 2008 Report Share Posted July 17, 2008 Which verification method do you use? Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.