Search the Community
Showing results for tags 'rename'.
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 am using Retrospect version 12.5 for Desktop. I have a LTO-4 5.25" SAS Drive (no autoloader) and 30 LTO-4 tapes that already labeled from the manufacturer. I want to add all the tapes to the same backup set and keep their unique names. Every time a tape is added to my single media set, Backup Set A, it automatically gets renamed to an incrementing number like 1-Backup Set A. After doing some research,I found a few people say that this will always be done by Retrospect. Unfortunately this is an inconvenience for me as my tapes are already nicely labeled like GHD633L4 so to label them differently in the software is just going to create confusion and more work for me. The way i see it, i am going to have to create a spreadsheet that says "GHD633L4" is "1-Backup Set A" and so on. Maybe I am missing something or still not understanding it. Is there a way for me to keep the unique tapes names in a backup set?
I experienced an annoying bug today while adding a Retrospect client. The client, a Windows 7 machine running client version 7.7.114, was successfully added via direct IP address. I then attempted to change the name to a name containing 31 characters. The name change window accepted the new name, but shortly after I clicked the Change button, the engine crashed. The crash apparently also wiped out the Config80.dat file, because when the engine restarted itself, it had lost a number of configuration changes I had recently made, which suggests it had restarted using Config80.bak. However, Config80.bak apparently was also corrupted in the process, as when I attempted to re-add the client, I got the always-helpful "An error occurred" message. I attempted reverting to ever-earlier backed up copies of Config80.dat (quitting the console and stopping the engine each time, of course), each time experiencing the same engine crashes and Config80 file corruption. It was only after 5 or 6 such attempts that I remembered that we had previously needed to truncate a client name in Retrospect 8. When I shortened the new name to 30 characters, I was finally able to successfully change the name and avoid crashing the engine. Obviously, the Retrospect 9 console either should refuse to accept a longer client name than is acceptable or should handle such an error more gracefully.