Jump to content

Specific MD5 error remains


Recommended Posts

I started backing up to a new drive.


Out of 300k+ files, two generated an MD5 error:


Generated MD5 digest for file ... does not match stored MD5 digest.


The documentation says this kind of error will cause Retrospect to store the file again in a later backup.


Three backups in a row get this same error on the same two files. To me, that suggests the files are NOT being re-backed up.


Any suggestions? This sounds like a subtle defect in Retrospect.


If it is an equipment error, there's no reason the exact same files, in their stored version, would always be the ones getting generated-MD5 mismatches.


Link to comment
Share on other sites

If 2 files reported the error, then something is preventing those 2 files from being successfully backed up. Retrospect is doing exactly what it should do. Would you rather your backup software NOT tell you when something doesn't look right? MD5 is a math calculation for the file. 1+1 isn't equaling 2, it might be 1.99999 instead.


Try switching to thorough verification to see if the byte by byte verify reports a more detailed error.

Link to comment
Share on other sites

Wellll.... it's nothing in my system.


I wonder if it could relate to file names or the length of the path or something like that.


I ran more backups w/ byte-compare, same error, now with error -1129 listed (which is not in the KB nor help file AFAIK.)


The files are fine (tif - fully usable).

I made a copy of the files without trouble.

Did binary compare - no problem.

Backed up the copies - no problem.


(And since we use the default of only backing up one copy of the file, that was enough to make the error disappear.)


So: we have not really resolved the issue. I found a workaround but would love to really resolve things like this...



Link to comment
Share on other sites

Sorry, I guess I was not clear enough before. As I noted in my 10/11 6:48pm reply:


* No other errors were or are being generated


* I was able to open and copy the file without any errors. A non-Retrospect binary compare was successful.


* Re-running a backup did backup the copy, without any error. And since the copy is a duplicate, it no longer attempts to backup the original, and therefore no longer reports an error.


Two questions:


1) Are you actually asking about non-Retrospect logs, i.e. Windows ctrl panel/admin event log? If so, I'll go look this evening.


2) Is there a way to retest the original file backup without wrecking our overall backup?


My thought on #2: I did the backup-the-copy using a *.tif filter that only looked at the folder tree in question. Perhaps I can delete that session, thus deleting the copy-backup from the backup set, and restoring the problem?


Whatever the trouble is, I'm hoping that I can replicate the problem. Much easier to debug that way ;)



Link to comment
Share on other sites

  • 2 weeks later...

Hi Austin. Seems I have same issue starting about 2 weeks ago. There is one file which always generate this error. I can normally work with that file, delete it, copy it again. If I created copy of this file with different name, it generated error for booth - original and copy. No other file is causing any troubles, just one.


In case you are interesed, you may take a look at that file here:




Regards Ondrej

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