Search the Community
Showing results for tags 'md5'.
The search index is currently processing. Current results may not be complete.
To All Retrospect Users, can you please read the following feature suggestion and offer a +1 vote response if you would like to see this feature added in a future version of Retrospect? If you have time to send a +1 vote to the Retrospect support team, that would be even better. Thank you! I contacted Retrospect support and proposed a new feature which would avoid redundant backups of renamed files which are otherwise the same in content, date, size, attributes. Currently, Retrospect performs progressive backups, avoiding duplicates, if a file's name remains the same, even if the folder portion of the name has changed. However, if a file remains in the same folder location and is merely renamed, Retrospect will backup the file as if it's a new file, duplicating the data within the backup set. This costs time and disk space if a massive number of files are renamed but otherwise left unchanged, or if the same file (in content, date, size, attributes) appears in various places throughout a backup source under a different name. If this proposed feature is implemented, it would allow a Retrospect user to rename a file in a backup source which would not subsequently be redundantly backed up if the file's contents, date, size, attributes did not change (i.e., just a file name change doesn't cause a duplicate backup). I made this suggestion in light of renaming a bunch of large files that caused Retrospect to want to re-backup tons of stuff it had already backed up, merely because I changed the files' name. I actually mistakenly thought Retrospect's progressive backup avoided such duplication because I had observed Retrospect avoiding such duplication when changing a file's folder. For a folder name change, Retrospect is progressive and avoids duplicates, but if a file is renamed, Retrospect is not progressive and backs up a duplicate as if it's a completely new file. If you +1 vote this suggestion, you will be supporting the possible implementation of a feature that will let you rename files without incurring a duplicate backup of each renamed file. This can allow you to reorganize a large library of files with new names to your liking without having to re-backup the entire library. Thanks for you time in reading this feature suggestion.
I have seen this behavior since v9, and it seems to be rare, but about the same. You can see my post about this in: http://forums.retrospect.com/index.php?/topic/151548-verify-vs-copy-and-data-errors/ ( and http://forums.retrospect.com/index.php?/topic/151193-error-in-the-log-what-does-it-mean/ and http://forums.retrospect.com/index.php?/topic/150803-what-does-verify-error-mean/ ) In short, I get MD5 errors in media sets that remain even after the media set is copied, and seem to be repeated if the same file is backed up again. It is as if there is something about the file that the MD5 algorithm can't handle correctly. A verify of the media set will reliably complain of the MD5 error. A restore of file with the MD5 error will succeed without error, and if I copy the media set, the copy operation will see no MD5 error, but the resultant copied media set will show the MD5 error on the same file when I do a verify on the copied media set. I would normally blame this on hardware - bad disk, bad cables, flaky hardware, but I have seen this on several disks and several computers, and the problem does not appear to be hardware. The pattern appears to be a software problem in MD5 generation (or verification). The error usually happens on files with very long "garbage" file names. (generated by some sort of hash) I can't pin this down, nor reliably reproduce it. If I can, I'll do so.
Hello, I was running a backup onto a NAS which got stuck half way through the 'compare' stage. 1) Am I correct in understanding that 'Verify' on the media set in question will check the media set against the MD5 digests of the original source files which were made during backup? 2) If the MD5 wasn't created for comparison will I be told in the log? The manual says the file will be checked if it can be read if it can't be compared, but it would be nice to know. I'm essentially trying to avoid repeating a rather long backup which got stuck on the compare stage and would like to know if the 'Verify' is doing the compare for me? Thanks
I recently have taken to running a "verify" on all my backup sets on a schedule, so I get some notification when the HW starts having trouble reading the media. On the most recent rotation, I see this: - 5/11/14 2:58:58 PM: Verifying v9_iCompute_last !Generated MD5 digest for file "Quantum18G/Household/Parties/dot75party.sitx" does not match stored MD5 digest. Remaining: 1 files, 0 B Completed: 508006 files, 57.8 GB Performance: 5,651.9 MB/minute Duration: 00:11:05 (00:00:36 idle/loading/preparing) What does it mean? When I restore from this set, I see this: + Restore using aRestoreTest at 5/13/14 (Activity Thread 1) To volume z-junk... - 5/13/14 3:54:08 PM: Restoring from v9_iCompute_last, Snapshot Joy, 4/28/14 4:22:15 AM !An error occurred during the verification step. The MD5 digest for the file "Quantum18G/Household/Parties/dot75party.sitx" did not match, error -1129 ( MD5 digest mismatch) 5/13/14 3:58:21 PM: 1 execution errors Completed: 31118 files, 9.2 GB Performance: 2,370.9 MB/minute Duration: 00:04:13 (00:00:13 idle/loading/preparing) There is a clearly an error of some type. I can't re-do the backup, since this was copied over from another set, and the original backup source has changed. Is there a way to "fix" this?It looks like I have one file that somehow has a bad/missing checksum. Is this because the copy operation from the other backup set dropped a bit? Is it a Retro bug? Inquiring minds want to know.