Jump to content

twickland

Members
  • Posts

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. What selection parameters are you using in your Copy Backups script? Is there any possibility these may have changed recently? Do you obtain any different results if you try running a Copy Media Set script rather than a Copy Backups script? If you do a verify, I'd select the option "Verify entire media set." In my experience, a verify operation either does not recognize bad media set headers or it ignores them, as they are not noted in the log. My biggest concern is the bad media set errors you're encountering with the tape copies. That suggests something subtle may be amiss with the disk media set, since you are apparently able to restore successfully from that set. If the above suggestions lead nowhere, I'd be inclined to open a support case with Retrospect.
  2. Are you able to refresh or locate the client in the Sources window? Are you performing regular scheduled backups in addition to the proactive backups, and do the scheduled backups run correctly? (If you're not doing this already, try creating and running a regular scheduled backup as a test. You will get an error message if the backup fails, which could help in your diagnosis.) Are the problem clients located in a different subnet than the clients that back up correctly? How are you attempting to connect with the clients: multicast, subnet broadcast, or direct IP?
  3. The matching/don't add duplicates options are controlled by your backup scripts, and not by the source- or media set configurations. Simply forgetting and re-adding a source will not cause it to be backed up in its entirety (unless, of course, that is what your script had been set to do).
  4. I would try forgetting and then re-adding Media Set A to see if that helps. Go to the Media Sets window, highlight the media set and click "Remove." Then click "Locate" and navigate to the media set's catalog.
  5. 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.
  6. 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?
  7. 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.
  8. 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.
  9. "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.
  10. 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.
  11. 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.
  12. 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.
  13. 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 .
  14. 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.
  15. 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.
  16. 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.
  17. 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?
  18. During a Restore, after Retrospect has copied the requisite files, it then works on "Completing restore." My assumption is that this operation, for which there is no public documentation (c'mon Retrospect, Inc.), and which can go on for quite some time, is probably restoring file and folder metadata. Because this process is lengthy, there is the distinct possibility that a client computer goes to sleep or is disconnected from the network during the "Completing restore" phase. (It's happened to us a couple of times.) Unfortunately, there appear to be nothing in Retrospect that is designed to recognize or handle this kind of exception; it will blithely say it's "Completing restore," apparently forever until the engine is stopped, long after there is no longer any response from the other end of the line. Thus far, our users haven't experienced any noticeable issues after their "Completing restore" operations were interrupted. However, I consider Retrospect's inability to deal with this issue a pretty significant lack.
  19. 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.
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. 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.
  25. 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.
×
×
  • Create New...