Search the Community
Showing results for tags 'file'.
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 got an error on a restore today. The log: Log for Script: Restore Assistant - 1/17/15 12:15 AM... Date: 1/17/2015 + Executing Restore Assistant - 1/17/15 12:15 AM at 1/17/2015 12:17 AM (Execution unit 1) To volume Shared_Files2... - 1/17/2015 12:17:55 AM: Restoring from v9_SharedFiles, Snapshot root, 1/10/2015 1:01:06 AM FScSetWhichNodeInfo: USetWhichNodeInfo failed: -5000 1/17/2015 1:45:31 AM: Execution completed successfully Completed: 1018 files, 36.6 GB Performance: 428.6 MB/minute Duration: 01:27:35 (00:00:21 idle/loading/preparing) 1/17/2015 1:45:31 AM: Script "Restore Assistant - 1/17/15 12:15 AM..." completed successfully The restore seems to have worked, but the error message gives me the creeps. What operation failed? It would be nice to list which file/directory/operation actually failed. If it did fail, why does it say the script "completed successfully"? The the failure is irrelevant (script successful, right?) then why list it? Inquiring minds want to know. ;->
I noted an anomaly in my log: + Normal backup using daily_user_portable at 3/27/14 (Activity Thread 1) To Backup Set v9_daily_user... - 3/27/14 11:31:59 AM: Copying Users on agility 3/27/14 11:37:27 AM: Snapshot stored, 7.4 MB 3/27/14 11:37:32 AM: Execution completed successfully Completed: 16104 files, 2.3 GB Performance: 460.4 MB/minute Duration: 00:05:32 (00:00:29 idle/loading/preparing) - 3/27/14 11:37:33 AM: Verifying v9_daily_user 3/27/14 11:38:04 AM: Execution completed successfully Completed: 16143 files, 2.3 GB Performance: 4,983.8 MB/minute Duration: 00:00:31 (00:00:02 idle/loading/preparing) The odd thing is the diference between the files backed up, and the files verified. Why are there 41 more files verified than were backed up? ???????????????????????????? (Retro 10.5 engine running on Mac OS X 10.8.5)
The Mac OS X finder has a "go" option that will let you type in a file path to go directly to that file/folder without navigating through the (SLOW) GUI file selection dialog box. I was thinking today how much time that would save me! Such an option should be easy to implement, even cross-platform, and would be of enormous value to those of us who want to save time. ;->