Jump to content

dherr

Members
  • Content count

    4
  • Joined

  • Last visited

Community Reputation

0 Neutral

About dherr

  • Rank
    Occasional forum poster
  1. Retrospect has many great features, but after maintaining it in a SMB environment for several years there are a number of areas where I'd like to suggest improvements. The following feature requests, in no particular order, would go a long way towards making Retrospect much more enjoyable to use. 1. Separate the UI process from the backup processes (not just different threads). It doesn't happen frequently, but on fairly regular occasions the UI crashes at unexpected times. When it happens while a backup is running, it usually corrupts a catalog file and sometimes an entire disk backup set. The UI crashes have occurred at different times and were often unrepeatable (opening a help file, saving a selector, reconnecting to the Exchange server, etc.). UI crashes are maybe not completely avoidable, but they shouldn't impact a running backup. While you're at it, make the backup processes run as a Windows service. For now, I try to avoid using the UI while backups are running. 2. Ability to repair a catalog file without removing the backup set from all the scripts. I recently reported this in another thread. 3. Ability to select and forget multiple snapshots at a time in a disk backup set. When a client is renamed or deleted, its last 14 snapshots remain in the backup set forever. Removing them one at a time is very tedious, especially in large backup sets where it takes several minutes for each. 4. Ability to sort by any column in history, sessions, and snapshot lists. Might as well support it in all grid-style lists. 5. Report that shows all volumes sorted by time since last successful backup. 6. Export and import settings to/from user-editable text files. This would be especially useful for scripts and selectors, to make it easier to create, edit, verify, document, and back them up. 7. A single report that shows all settings and configuration data. Similar to #6, it would be very useful for documenting, troubleshooting, and restoring backup settings. 8. When a selector excludes a particular path, completely exclude it. Currently, it seems to scan files and folders under excluded paths and stores them in the catalog, even though they are never backed up. This can greatly increase backup times and the size of the catalog file. We have a folder containing a large number of small files (>1 million) that we back up with other methods, and we'd like Retrospect to simply skip over it. 9. Show backup sizes in bytes (or KB, MB) in History, Sessions, and Snapshots lists. Backup time, performance, and file counts are also useful, but when verifying a script or selector I usually want to see byte counts. Thanks.
  2. Ok. To me it's a bug and to you it's a feature. As a programmer I'm familiar with that argument. I have been using Retrospect for years and know that this behavior is how it has always been. I decided to finally report it as a bug because I have come to consider it a very serious flaw in the design of the UI. It has burned me multiple times, and when it happens my scheduled backups don't run. I only caught it this last time because I actually remembered to check if that specific backup succeeded the next day. There was no error, no warning, no e-mail, only a single sentence on p. 324 of the User's Guide and one missing entry (among dozens per day) in the history log. If I hadn't thought to check it that day, it's hard to say how much time might have passed before I noticed the missing entry. There's a good chance I wouldn't have noticed it until someone asked me to restore something. I agree with JMcIntire that at minimum there should a clear warning pop-up whenever scripts will be automatically altered in any way. Don't assume everyone has read and remembers p. 324. But even then, having to manually go back and fix numerous scripts every time I recreate a catalog is still a major annoyance. It takes time figure out which scripts were affected and then fix them. It also makes it very easy to miss a script, or to accidently change something else while trying to re-add the deleted backup set. A much better solution would be to simply ask the user if he'd like the scripts to be automatically modified. The current design is obviously meant to preserve referential integrity between the scripts and the backup sets. In this case, however, I'd argue that it's better to allow the possibility of a broken reference in a script. A broken reference would at least generate an error when the script runs, rather than failing silently as in the current design. When recreating a catalog, the reference should only be broken temporarily, if at all. I think the central flaw in the UI is that a user doesn't naturally associate repairing a backup set with forgetting a backup set (even though I now realize that's how the repair works internally). The fact that I'm trying to repair it would seem to imply that I do NOT want to forget it. In summary, I guess it all boils down to two requests: - Allow the user to repair a backup set without forgetting it. - Never modify scripts without asking the user. Scripts are sacred. Once they're tested and working, they should never be modified behind the scenes. Thanks for all your responses.
  3. The wizard asks if I want to "forget" the existing catalog file, not the entire backup set. The catalog file is corrupt, so of course I want to forget it. There is no indication or expectation that performing a routine maintenance/repair operation on a backup set will corrupt my scripts. I call it a bug because we're talking about backup software and the issue has caused me to miss numerous "scheduled" backups. If you want to call it a feature request, fine, but I really hope the feature that allows me to fix a catalog without breaking the scripts gets implemented before I lose data. (Or better yet, fix whatever issue corrupts the catalogs to begin with.)
  4. Since switching to a disk-disk-tape backup strategy about 8 months ago, every month or two we end up with a corrupted catalog file on a disk backup set. I should know better by now, but I always seem to forget that recreating a catalog file also removes the backup set from all scripts. I doesn't make any logical sense from a user's perspective that repairing a backup set would remove it from the scripts. The end-result is that by fixing one problem (repairing a corrupted catalog) I inadvertently cause more problems (scripts with a missing source or destination). At best this is an annoyance, because we have about a ten different scripts that we have to manually fix each time. But it's also a very serious issue because a missing item in a script means data is not being backed up. Even worse, it does not cause any errors to be logged and the problem can go unnoticed for days or more. Last night our main server backup script had no Destination, and failed without any notification, after I "successfully" recreated a catalog file yesterday afternoon. I strongly suggest this issue be moved near the top of the list as a "bug that causes backups to fail silently". In the meantime, is there any way to recreate a catalog file without corrupting the scripts? We're using Multi-Server 7.5.508.
×