Search the Community
Showing results for tags 'digest'.
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.