Jump to content

twickland

Members
  • Posts

    1,684
  • Joined

  • Last visited

  • Days Won

    39

Everything posted by twickland

  1. What exactly does "seems to grind to a halt" mean? What error messages are you getting? Is there anything else noted in the log? What is your hardware setup, what OS are you running, and what type of backup set? Retro 8.2 should also simply log a "client not found" or "network communication failed" error and move on when a client is unavailable. The fact that it's not doing so in your case indicates something is wrong.
  2. Retrospect 8.2 is pathetically uninformative as to what it's up to during a restore. I have found that sometimes the only way I can find out that the restore is actually in process is by opening Activity Monitor and watching the amount of memory taken by the Retrospect Engine increase stepwise. If that's not the issue in your case, you may want to try uninstalling and reinstalling the engine and console. That process remedied some otherwise inexplicable misbehavior for us.
  3. In our setup, the network connection name is "Default" with just a dash and multicast works fine. You might try increasing the multicast time-to-live in Retrospect's Preferences/Network/Advanced... from the default 1; try upping it to 2 or 3 and see if that helps.
  4. Are you saying that your source is a specific user's individual user folder, or is it the Users folder?
  5. This is just the opposite of the rule you asked about in one of your prior posts. How you write the rule depends on how many files in addition to those in /Library you wish to include. If you only want the files in /Library, the rule is simple: "Include Mac Path is /Library/" (assuming that the desired volume(s) is your source). Because Users/[username]/Library is not contained in /Library, it will, of course, not be backed up. If you want everything on the source volume, including the contents of /Library, but wish to exclude the user libraries, you would leave the Include section blank, and would write an "All" conditional in the Exclude section with the following subconditions: 1) Mac Path contains /Users AND 2) Mac Path contains /Library. If you want to back up something in between, of course, your rule will need to be more complex. (In general, it's usually simplest to incorporate your most global conditions in the Include section, and the more narrowly tailored conditions in the Exclude section.) Hope this helps.
  6. All your actual results are what I would have expected. This rule is looking for a file whose name is or ends in "Music." As Steve Maser notes, to indicate a directory (i.e., a folder, which will contain your desired files and perhaps subfolders), your pathname needs to end with a "/". This is looking for a folder at root level with the name "Music," which presumably doesn't exist. It would appear that whatever algorithm Retrospect is using to determine "like" is actually delivering sensible results. Again, the only thing that should be excluded is the contents of a root-level folder named "Music." Since that folder doesn't exist, nothing is excluded.
  7. Back in the Retro 6 days, when one created a selector (i.e. rule), the starting point was obvious. Until changes were made, the selector read: Include Everything and Exclude Nothing. That made it clear that any conditions placed in the Include section are restrictive. Retro 8 has the same starting points except that it doesn't tell you so; in other words, leaving the Include section blank unintuitively gives you a starting point where everything will be selected. (Retro 6 also provided the options is/is not and does/does not, which made it considerably easier to create complex selectors without having to futz with "None" subconditions as Retro 8 now requires.)
  8. Under Exclude, have an All conditional with two subconditions: 1) folder Mac path contains /Library AND 2) a None conditional with the following single subcondition: Mac path contains /Users.
  9. One thing to check is whether the Config80.dat file is being updated/modified as expected. Among many other things, Rules are included in this file, which is located at /Library/Application Support/Retrospect on the Engine computer. In our original installation of Retro 8.2, we were finding that this file would not reliably update itself automatically, meaning that recent modifications to scripts, preferences, etc., would not take. We had to manually stop and restart the Retrospect Engine to force it to update. (A reboot, of course, would also achieve this.) The solution for us was to uninstall and reinstall both the Retrospect Engine and the Console. We were able to retain the Config80.dat file, which as far as we can tell was uncorrupted by the prior odd behavior of the Retrospect app.
  10. That's only partly true, at least in our experience. If a client is added by direct IP address and then happens to be offline during a backup, Retrospect reports a -519 error instead of a -530. This anomaly would of course not apply in a situation where the client computer is on line unless, say, the client's firewall were enabled between the time that the client was added and when the backup occurred.
  11. Actually, we've managed to create some pretty complex rules. Our normal backup rule, designed to exclude a whole raft of different files, currently has over 50 different conditions and subconditions, including multiple "All" conditions. Getting to this point was neither easy nor straightforward, however. A couple of hints: You can't create an All condition at the top level of "Include" or "Exclude" (at least, we've been unable to to so). For an "All" condition, you need to create a new condition under "Any" and then incorporate your subconditions under this new condition. When creating a complex set of conditions, Retropect will sometimes change the subconditions under previously-created "All" conditions. These changes range from promoting subconditions to a higher level, to deleting them entirely. The solution is to keep scrolling up and down the rule as you edit, correcting and recorrecting the undesired changes that Retrospect has made. Following this iterative process, we were finally able to achieve the rules we wanted In our experience, a rule, once saved, remains stable; they have only changed unexpectedly for us when we were in the process of actively editing the rule.
  12. Retro 6.1 isn't supposed to get stuck and if it's behaving correctly, it should log a 519 network communication failed error and move on after 5 minutes or so. It may be that the Retro.Config file has been corrupted, or it may be an issue with the client app. If you'd like more advice on this angle, post your question in the "Desktop, Workgroup and Server for Mac OS X " forum.
  13. This did not work in my case, even after quitting/stopping/relaunching the console and engine. Fearing the worst, today I quit the console, stopped the engine, and dragged the offending catalog to the desktop. I then attempted unsuccessfully to perform a fast catalog rebuild. (See my other post about that failure.) I then moved the original catalog back into the Retrospect folder. The net result of all this hocus-pocus is that all the backup sessions visible in the media set window are now available in the restore window. That one backup session, visible in Past Backups but not for the corresponding media set, still persists, however. Can't say all this flaky behavior inspires much confidence.
  14. According to the user's guide, "Retrospect has a feature, found in the Options tab of a Media Set, called Fast Catalog Rebuild where, every time it starts a tape after the first in a Media Set, it writes the current Catalog to the beginning of that tape. This speeds rebuilding of the Catalog by only requiring the last piece of media belonging to the Tape Media Set to be scanned by Retrospect." Has anyone been able to get this feature to work? We have an LTO-3 tape media set that supposedly has this feature enabled. When I performed a test, inserting the last media member of the set and clicking "rebuild," Retrospect considered only that member. While it listed all five members in the rebuilt backup catalog, it indicated that the first four were lost. Unchecking "lost" made no difference; the files from those four earlier members were not included in the rebuilt catalog, as I confirmed by attempting to locate one of those files during a mock restore.
  15. I'm almost afraid to ask, but what does it mean when a backup session appears in the Past Backups list, where it can happily be browsed, but does not appear in the current Backups list for the corresponding (tape) media set, nor in the list of sessions that can be retrieved for the media set? I thought that both of these lists referenced the backup set's catalog. The session in question does appear in the list of snapshots available for restores (which is encouraging), but scarily, there are also a number of sessions that, while they appear in our media sets' lists of backup sessions, do not appear in the list of sessions available to restore from.
  16. Are you using SCSI? What host bus adapter? We used this model successfully for years on a G5 dual-processor with Retrospect 6.1, OS 10.4.11, and an ATTO UL4S SCSI HBA.
  17. There are 9 graphics files in the same folder, each about 64 MB. The filenames differ only in having a different sequence number at the end (obj1037, obj1038, etc.). All 9 files back up in Retro 6.1. Only 6 of the 9 files back up in Retro 8.2. I'll try updating the client software and see if it makes a difference.
  18. Hitting "Refresh" doesn't refresh the log. The only thing that works is closing and reopening the log window. Under previous versions of Retrospect, the log always updated dynamically, which from what you say apparently doesn't happen under Retro 8. However, it would seem that "Refresh" should enable updating. In our case, it did so once and then never again.
  19. Does anyone know the meaning of error -1105, " can't read, improper seek?" We are finding this error with a few files on one Mac client, a Mac Pro running 10.5.8 with client version 6.2.234. The files in question are able to be backed up without a problem in Retrospect 6.1.
  20. OK, you have answered my question; the operations log should be updating automatically. In our case, for example, an overnight series of backups with dozens of sessions will not be displayed in the main log the following morning unless the log window is closed and reopened. (Log entries for specific sessions in the Activities window do update, or at least can be refreshed, during the backup session; they just don't get added to the main operations log.) Given the apparent fragility of Retro 8.2 and the fact we have finally got it to function only after a couple of uninstalls/reinstalls and config rewrites, I think we will try to live with this inconvenience.
  21. Is the operations log supposed to update itself automatically in 8.2? Barring that, is it supposed to update when you hit Cmd-R ("Refresh")? The only way I can get the log to update is to close and reopen the log window. I tried replacing the log (after stopping and restarting the engine and console). The fresh log didn't update automatically, but it did respond to the Refresh command--once. Then it went back to needing the log window to be closed and reopened. Retro 8.2 (399), Mac Pro 3.2 GHz quad core, 6 GB RAM, 10.6.4 desktop.
  22. In Retrospect 6.x, when creating a file browser from a volume or backup session, one had the option of viewing the folder structure or viewing the files sorted without folders. Unless I'm missing something, there seems to be no option for doing this in Retrospect 8's browsers. Can anybody enlighten me?
  23. I was attempting to rebuild a 6.1 file backup set in 8.2. I understand that Retrospect will convert all the data to 8.2 format; not just the catalog. Unfortunately, Retrospect wants to perform the conversion onto the same volume as the original, which doesn't have enough capacity for both the old and new files. The UI offers no option for specifying a different destination for the converted copy. Does anyone know of a workaround?
  24. Any estimate of tape capacity is just that--an estimate. The amount of data you can actually get on a tape depends on a lot of factors, including the compressibility of the data (assuming you're using compression), how close the rate of data you're supplying matches what's optimum for the drive (too little data results in the drive having to constantly backhitch), etc. LTO-3 tapes have a native capacity of 400 GB. In our setup with network backups, we typically get 500-600 GB on a tape with our data mix, so your numbers do seem a bit low. You aren't by chance using LTO-2 tapes in your drive, are you?
  25. An update on this issue: I was finding that the only way for me to get Retrospect to write to Config80.dat was to stop the engine. Starting with a fresh Config80 or a fresh plist brought no improvement. I finally uninstalled and reinstalled the complete software (engine and console), though I did retain the Config80.dat file I had painstakingly built and saved. Since that time, Retrospect seems to be behaving pretty much as I had expected. Changes to Retrospect's preferences now cause an immediate write to Config80; otherwise, Retrospect updates the file periodically (looks like every couple of hours). The frequent engine crashes have also stopped.
×
×
  • Create New...