Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by twickland

  1. twickland

    Ejecting Ext Drive #Annoyance

    It sounds like Retrospect may somehow be seeing that drive as a removable disk. Try ticking the box "Don't eject removable disks" in Preferences:Media and see if that makes a difference.
  2. twickland

    can't stop grooming

    If you stop and restart the engine, are you able to remove the problematic media set from the Media Sets list before the grooming begins?
  3. I've recently been seeing thousands of occurrences of the following error message in the operations log: [*] TLocalVolEnum::NextEnum: UMakePath error -43 on volume brettw The error messages are interspersed with other normal log entries and don't appear to be associated with any particular Retrospect activity, at least as regards the sequence in which these messages appear relative to the other log entries. There is no local nor client volume "brettw," though there is such a folder on a mounted server volume and brettw appears as a user on a number of client volumes ("brettw" is the account of one of our IT guys). The name doesn't appear in the Sources list as a volume or a favorite folder. I know error -43 as a file not found error, not something particular to Retrospect. Any ideas? Thanks.
  4. twickland

    Retrospect with LTO 6

    Are you really trying to use a new LTO-6 drive with Retrospect 6, which is probably a decade old? It would seem reasonable to expect that a piece of 10-year old software might not be capable of employing all of the necessary commands to communicate fully with a new tape drive. Please confirm which version of Retrospect you are running. (Perhaps you just posted this in the wrong forum.) Retrospect doesn't back up to a device; it backs up to a Backup Set/Media Set (the first name being used in Retrospect 6 and earlier; the second is the current designation). Assuming that Retrospect can communicate with the tape drive and sees the correct tape in the drive (that is, the tape that is the most recent member of whatever you have specified as the destination tape media/backup set in your backup script), it will back up to that tape. In recent versions of Retrospect, it is possible to specify which tape drive should be used for any given media set (this is referred to as binding the media set to the drive). I don't think there was any similar option with Retrospect 6. If a particular tape drive isn't specified, Retrospect will search all available drives for the appropriate media/backup set tape member that the script is calling for.
  5. "Copy Media Set" is for when you want to duplicate an entire existing media set. When you're looking at an ongoing process, "Copy Backups" is best. Unless you include parameters in your script that would exclude certain backups, you will copy over all backups. A "New Media" backup is a fresh start onto the new media set with the advantage of retaining your existing scripts and schedules. I presume that "all current files" is smaller than "all versions of any files that were ever backed up," but yes, the first backup to any new media set will typically be much bigger than subsequent incremental backups. Assuming you don't delete the catalog for your previous media set, searching for a specific file across multiple media sets is a simple task. The more files each media set contains, though, the longer the search will take.
  6. As you found, having only a single media set is risky. Having a 6 TB media set with years' worth of data will also make a complete restore (as opposed to retrieving specific files one or two at a time) potentially more cumbersome. We use three media sets. Set C is a single-member disk media set that is groomed regularly and is used to perform daily backups. It's also the primary source for restores, since it's relatively small. Sets A and B are multi-member tape media sets that are rotated on a weekly basis, with the inactive set being taken off-site. We use a Copy Backups script to copy daily from set C to whichever tape set is currently active. (In our scheme, sets A and B could also easily have been multi-member disk media sets, had we chosen to do that.) When media sets A and B become inconveniently large, we perform a New Media backup to each set. You do this by selecting the media action "Start new Media Set" when the backup script is run. The script you use to perform the new media action can be very simple; for example, backing up a small favorite folder. The advantage of a New Media backup is that all of your scripts will automatically change their destinations to the new set; there's no need to edit the scripts manually. Your media sets will also have a clear nomenclature history: for example, if the initial media set is named "Set A," the next one will be named "Set A [001]," and so on. We retain all of our tape media sets in case we ever need to retrieve a file from long ago. The set A series are all kept on-site and the set B series are kept off-site. With the above arrangement, you would lose at most one day's worth of data unless both set C and set A or B (whichever is on-site) were destroyed or became unreadable, in which case you would lose at most a week's worth of data.
  7. It sounds like the issue is with the client computer. My first thought is that the client may have added the non-boot volumes to the Privacy list in client preferences, which would make them invisible to the backup computer if the "Allow clients to exclude items from backups" option is selected on the backup computer. If that is not the case, I'd try uninstalling the client software, deleting the file "retroclient.state" from /Library/Preferences if it exists, and then reinstalling the client software.
  8. When you initially installed Retrospect 13.5, the installer should have placed a copy of the Retrospect 13.5 uninstaller script in the Applications/Retrospect folder. I would try manually trashing the Retrospect app folder and /Library/Preference Panes/Retrospect.prefPane, and dragging the folder "Retrospect" from /Library/Application Support to the desktop. Then reinstall Retrospect. If you are now able to enter the license code and access the engine, try quitting the Retrospect console and stopping the engine and dragging the Catalogs folder and the file Config80.dat from the Retrospect folder on your desktop to /Library/Application Support/Retrospect, as well as any public and private keys you may have created. Restart the engine, launch the console, and see if all is well. If it isn't, that would indicate that your configuration file Config80.dat is corrupt. In that case, if you don't have a good backup copy, you will need to recreate all your scripts, lists, and rules from scratch.
  9. Are you referring to this button? That button is not grayed out in my copy of Retrospect 13.5. It pulls up the past backups associated with the selected media set, and enables retrieving the actual snapshot. The GUI prior to Retrospect 8 (i.e., 6.1 and earlier) was completely different. Certainly, it wasn't so slick as the current version, but many of us found it more useful .
  10. I've always assumed that the "syncing" process was simply the console uploading information from the engine. We do not experience any modification to catalog files during this process.
  11. There is no issue with using multiple scripts to back up to a media set, nor for subsequent restores. You might want to use separate media sets for convenience in restoring, but there is no need to do so simply because you will be using several scripts.
  12. One downside to a proactive script is that you get no indication in the log as to why the client may not be accessible. Another is that if you want to limit the backups to a particular time window, any backup that's running at the termination time will just stop, with no verification step. (At least with regular scripts, you can select "When done," which in your case sounds like it wouldn't normally cause problems.) There are a lot of upsides to a proactive script, including the ability to back up clients when they are online and to back up to whatever media set(s) are available. We use a blend of both types of scripts to use their different advantages.
  13. We have seen this issue in the past in the Media Sets window (though not recently), but for us it was an annoying but cosmetic issue, as backups to these media sets would run normally. Quitting/relaunching the console would often fix the problem; otherwise, we could correct the display by stopping and restarting the engine. The problem went away for us after a version upgrade (I can't recall which upgrade it was, but it preceded 13). Sorry to hear that it still seems to be present in v13. Do your backups fail because the correct member is not available, or is it simply that you cannot view the member status of the media set?
  14. OK; I'm seeing what the problem is. Preview does work, sort of, but not as expected, and not in a useful manner. Normally, if one selects some portion of the files in a particular folder, Retrospect indicates this by placing a dash in the checkbox of the enclosing folder. However, when files in a Copy operation are selected using a rule, the enclosing folders do not display the expected dash until one drills down through the entire folder hierarchy to the level where the files themselves are displayed with their checkmarks. Only then do the enclosing folders show the dash. Clearly, a "preview" that gives no indication as to which files were selected, unless and until one opens every single folder to check the contents, is essentially useless.
  15. In Retrospect 13.0.1 (and possibly earlier versions), the Preview function in many cases does not display the correct files when using a saved Rule as the selection criterion in a Copy operation. Often, only a subset of the files that should be included are shown with a checkmark in the preview window, and actually with most of the rules I tested, no files at all are shown as being selected. If one proceeds with the copy operation without making any manual changes in the preview window, the actual copy seems to apply the selected rule correctly. The failure of the Preview function is very annoying, not least because this was the only way one used to be able to test the functioning of a rule without actually performing a backup or copy operation.
  16. Yeah, I just noticed myself that, as of Retrospect 13.0.1 (and possibly earlier—it's been awhile since I tried this), the Preview function for the Copy operation no longer reflects the proper application of the selected rule, though the copy itself seems fine. I'm not sure when this broke, but it's clearly a bug. Unfortunately, I don't know any other way to preview a rule.
  17. You need to be careful if you include a previously-created exclude rule in the exclude section of your new rule. In your case, Exclude Rule 2 would not back up files if client name was XYZ; i.e., it would back up files from any other source. If your new Ultimate Rule places in its exclude section the rule Exclude Rule 2, it would exclude files backed up from anywhere but client XYZ; in other words, it would only back up client XYZ, probably the opposite of what you want. If you want an exclude rule to function in its usual way when it's part of a new rule, it has to be placed in the include section of the new rule. Retrospect 6 (why do I have to keep going back that far to describe some desirable feature?) offered a simple way to test a selector/rule. In the current versions of Retrospect, you can do that in most cases by initiating a dummy Copy operation and then clicking on the "Preview..." button instead of actually running the copy.
  18. You can still configure a backup script to eject removable media when the script is finished, but I don't think Retrospect ever offered an option to unmount a hard drive volume at the end of a script execution. I see two potential problem you could run into: 1) the customer could unmount the destination hard drive while a backup is still running, and 2) a regular backup script will not run if the correct media set is not available. For issue 1, it would be best if you could set up the backup schedule to minimize the chances for that to happen. If by chance the customer does unmount the drive in the middle of a backup, Retrospect should eventually stop running the script (though we have sometimes seen a script get stuck under these circumstances). If issue 2 becomes a problem, you might use a separate script for each destination media set, enter a media request timeout in Preferences so the execution event will stop running if the correct media is not available, or switch to a proactive backup script, which will back up to whatever media is available. Whatever you do, someone needs to keep tabs on the backup operation. If the customer isn't going to check things himself/herself, Retrospect's preferences should be configured to send someone email messages for failures and media requests.
  19. twickland

    LTO4 Backup not filling up tapes

    I would contact the manufacturer of your HBA card. Based on the error messages, though, I would bet on the tape drive being at fault. We haven't had a whole lot of luck with repairing our tape drives, and have often needed to send them back two or three times to the drive rebuilder even after they assured us the drive was performing up to specs.
  20. Since upgrading to Retrospect 13, I have twice had a script become stuck for hours or days while attempting to back up a client. (The two instances were with different clients.) When in this stuck state, I was unable to stop the script execution in the Activities window. It was still stuck a half hour after clicking on "Stop." I had to stop the Engine. Here are the activities window and the relevant log excerpt from that window: I suspect the problem occurred when the client computer was taken offline during the backup, and the disconnection was not handled gracefully. In recent versions before 13, Retrospect has in our experience appropriately logged this type of connection failure and moved on in the script. The following may or may not be relevant to the above issue: In today's failure, after I restarted the Engine, Retrospect began running a pending script. While this was running, I went to the Sources window and, as an experiment, clicked on the button to browse the particular source (Favorite Folder "Documents and Settings") that had been in the process of being backed up in the stuck script. A window immediately popped up saying that the source was busy (with no numerical error code), even though in actuality that computer was offline. I would instead have expected Retrospect to have attempted to connect for a good minute or so before putting up a -519 error window. Curious, I then added that "Documents and Settings" source to an immediate backup script and ran it, setting it to back up to a different destination from the other script that was running. The backup appeared in the Activities:Waiting window, saying it was waiting for "Documents and Settings." I then removed the activity, shortly after which the Engine crashed. This time, after the Engine was restarted and I attempted to browse the "Documents and Settings" source, Retrospect's behavior was exactly as expected for an offline source: the attempt to connect for a minute and then putting up the -519 error window.
  21. twickland

    LTO4 Backup not filling up tapes

    The error message makes it pretty clear that there's a problem with the tape drive or somewhere in the SAS chain (cable or HBA card). I'm not sure what that message about the storage device not being licensed, though; I've never seen that. Is this the same tape drive you were previously using? Has that message ever appeared before?
  22. How did you perform the catalogue rebuild? Did you use Fast Catalogue Rebuild, where all you need to do is insert the last tape member? (You would have needed to have set up the media set in advance to take advantage of this option.) What Retrospect version was the original catalogue created in? Why were you trying to rebuild the catalogue for the "newest" version? Did this member (#17) appear to have contents when listed in the applicable earlier version? (And BTW, member #16 seems unusually small compared to the adjacent tapes.) I would first confirm that there are no problems in communication between the Retrospect Engine and the Console. Try stopping and restarting the Engine to see if the listing changes. I would then perform a new catalogue rebuild using just member #17 (or perhaps #16 as well). Before you do so, drag the existing catalogue to the desktop so you don't overwrite it, and also have Retrospect forget the media set by clicking "Remove" in the media sets window. If these tapes still show small or zero contents, that would suggest that something is wrong with the tapes themselves, I don't know any way for Retrospect to rescan an earlier tape member that it already knows about. If there is actual contents on that tape member, I think you will need to rebuild the entire catalogue. If you did use Fast Catalogue Rebuild, I would try performing the rebuild with an earlier member than you used before, and then perform a catalogue repair to add the subsequent members.
  23. The past several times I've performed Apple software updates that require a reboot, the Retrospect 12.5 engine has come back up in a condition that is not fully operational. The problems have typically included absent data for one or more media sets and a failure to recognize the correct tape in our LTO drive. Stopping and restarting the engine has always fixed these problems, but I have to remember to do this, or scheduled backups will not be performed. I've encountered this problem only after restarts that are part of updates made via the App Store; if I manually reboot, Retrospect engine always seems to launch and behave properly.
  24. I can confirm that this problem still exists in Retrospect 13.0.0.
  25. Do you mean the contents of a single tape that's a member of a multi-tape backup set? If so, the best way to do that is to search for all files with a backup date and time between the time that the tape was first written to and the time it was last written to. Unfortunately, that's easier said than done, as Retrospect does not make a tape member's date/time information accessible, even though it knows it. What we did (and still do) is label each tape with the date and time it was first written to. Luckily, there is a workaround. Mark all members of the backup set other than the one you want to view as "Missing." Then, prepare to run a restore, searching the backup set using the selector "All Files." (Afterwards, you can set all the members as "Found.")