Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by rhwalker

  1. Well, being just a user I have no more insight into the future than you do, but this thread might provide some glimpse of the timeline that you seek: Glimpse of timeline for Exchange 2010 support Russ
  2. Nope. Here's this forum's description: The Retrospect 8 forum link is here: Retrospect 8 for Macintosh I suggest, when you repost in the Retrospect 8 forum, that you include a screen shot so that we can take a look at how the scheduling is being done. Russ
  3. Very insightful, Steve. The software needs to be robust enough (defensive programming) to handle bad media sets / bad catalogs. If I were on the Retrospect team, I would be trying to capture some of these bad catalogs / bad media sets so that the software weaknesses could be repaired. As long as we spend hours each month trashing media sets, rebuilding catalogs, re-creating preferences, without having these issues addressed, the problem will never get fixed. Russ
  4. Sadly, no. Many of us are just as perplexed as to the cause of the config file corruption. If it was an easy problem to solve, I believe that the programmer(s) would have solved it already. Remember, the 8.x code branch is new code, quite immature. We (and our data) are the guinea pigs. Sigh. Russ
  5. Ok, then you've narrowed it down to some bug that causes your config files to become corrupt, which causes the engine to crash. You've got so many variables in play here that I suggest you start narrowing things down with, say, a single client backup, to see if you can get a reproducible test case. I also suggest that you make periodic copies (whether finder copies, or Retrospect copy) of the config files so that you can restore them from when they were good and get back up and running quickly until the problem can be isolated. The program is known to be buggy and known to corrupt its config files. When that happens, the engine crashes. That's life in the Retrospect world right now. Russ
  6. Well, for a start, you could provide version numbers. Mac OS version (10.x.x) on each computer in play. Exact Retrospect version on each computer in play (8.2.x engine, 8.2.x console, x.x.x client). It's unclear whether you are backing up the "6 servers" by mounting their volumes on the Retrospect engine machine, or whether you are running Retrospect client on those "6 servers". It's unclear what the OS are on those "6 servers" (windows? version? linux flavor? version?). Is there any information in the logs? Any crash reports? Is the Retrospect console on the same machine as Retrospect engine? The program is very buggy. Let's at least get some basic information from you. Russ
  7. Again, an incorrect assumption. You assume that the code in /sbin/md5 is the same as used by Retrospect. The algorithm may (should) be the same, but the implementation may not be as fast in Retrospect. Russ
  8. You first need to understand the Retrospect paradigm. The backup set (Retrospect 6.x term) (Retrospect 8 terminology is "media set") is a database, and holds all of the backup information. The catalog is a database index into the backup set (media set). There are no files in the catalog - again, it's a database index. To get files out of the backup set (media set), you restore. To do this in Retrospect 6, from the initial "Retrospect Directory" screen, click the "Immediate" tab, then click the Restore button, choose a snapshot (or add a snapshot - i.e., have the catalog updated to include a database index for earlier sessions), choose files to restore, choose a destination, and let it fly. Russ
  9. First, you haven't indicated what version (x.x.x) of Retrospect you are running now. If you are running some version of Retrospect 8, you will need at least 8.2.x in order to retrieve from older tapes. Second, you haven't provided any information regarding how many years ago the tapes were made, or what version of Retrospect made them. If you are trying to retrieve from tapes made by Retrospect prior to Retrospect 6, you are out of luck. You will need to run Retrospect 6, convert the backup sets to Retrospect 6, then run Retrospect 8, convert the backup sets to Retrospect 8 media sets. I suggest that you read the Roxio Retrospect 8.2 Read Me, paying attention to the section entitled "Restoring from Retrospect 6.x Backups". Russ
  10. Does it even respect hostname other then for the initial lookup? Everything seems to show IP addresses (Engines and Clients) after they're added. I'll bet if you change the address of a machine and also change it's A Records, Retrospect won't find it. What an interesting insight. That might explain why those of us with "static map" DHCP configurations aren't seeing these issues, but those with true dynamic DHCP IP assignment are. Clients added by name should always be looked up by name, not merely on the initial client add step. Yes, perhaps that's for another thread. Russ
  11. Agreed. I'm in the same boat. Agreed. It's a bug. One of many. Perhaps someday some of the outstanding bugs will be fixed. I suggest that you file an incident report to make sure that this gets on the list and prioritized. These forums are user-to-user support. The official bug reporting page is here: File a support request Russ
  12. You don't say what version of Retrospect 8.1 you have (8.1.xxx). Many (but not all) bugs have been fixed. The Release Notes bugfix list is here: Retrospect 8.x Release Notes / bugfix list You are also aware that the Retrospect 8.2.399 update was released about 3.5 months ago, aren't you? Link is here: Retrospect updates Perhaps this is one of the bugs that have been fixed. No point in chasing fixed bugs. You might want to update and then report results. Russ
  13. Realize that multiple threads will block if competing for the same resources. Hint: Do you have all backing up into the same media set? You might want to split things up. Russ
  14. Consider the case of a terabyte of historical files brought forward from MacOS 7, 8, 9 and ASIP 4.x into MacOS 10.x, with historical backups from Retrospect 2.0, 4.x, 6.x, etc. I've got that existence proof with such oddly-named files. No, a script can't do a search and replace for legal reasons - the files have to retain their names. Agreed, it's a dilemma. Russ
  15. You are aware that these forums are user-to-user support, aren't you? That's explained in the Forum Rules. I don't use the "Express" version of Retrospect, so I'm not able to offer any suggestions on your problem. Russ
  16. This is a case where it helps to read the documentation. You stopped reading too soon. From the Roxio Retrospect 8.2 Read Me:
  17. This particular topic has cropped up again and again over the years. The magic phrase to remember is "Moving Retrospect" - that's the only clue in the User's Guide index, unless you have a photographic memory and can recall every page of the manual (I don't and can't). I seem to recall that the needed files are in different places for W95, XP, Vista, and W7. There was either an email post on the retro-talk list or in these forums a year or two back by one of the Retrospect people, giving the exact search order of where Retrospect looks for the various files. Sometimes it gets confusing if there are multiple copies of the files floating around, figuring out just which one is being used. Russ
  18. Ok, then it's possible that the problem is related to the Leopard (or more restrictive) Snow Leopard "application firewall", which is different from the standard ipfw. You haven't provided any details of your OS environment, so it's not possible to speculate on the problem or its solution. Whether by updates / upgrades, or for whatever reason, there may be a software firewall in play on one or both of the problematic computers. Without any configuration information, no way to tell. Russ
  19. You haven't provided the specifics of your environment (Windows version, Retrospect version, etc.), so it's not possible to give you a "cookbook" answer that would work in your setting. However, the answers to your questions are yes (it's possible) and no (you don't have to set it all up again). It's even documented. See, for example, page 272 ("Moving Retrospect") of the Retrospect Windows User's Guide. Here's the link: Retrospect Windows Users Guide Russ
  20. To aid you and/or your network person in diagnosing this issue, you might want to try the little multicast diagnostic that one of the Retrospect GUI engineers wrote: Multicast Ping on a Mac It takes Retrospect out of the loop when trying to figure out what is happening. Russ
  21. There are three possible explanations, and it's unclear from your testing which is happening: (1) Retrospect 8 is writing to the tape in uncompressed mode. This bug has been reported before. (2) Retrospect 8 is causing larger inter-block gaps on the tape due to the tape drive's data pipeline becoming starved (the drive will increase the inter-block spacing in such situations to prevent "back hitching" - rewind and get a running start again for next block) to keep the drive in streaming mode. (3) Retrospect 8's tape error routines are too sensitive, and are giving up, believing that the tape is bad when, in fact, it's just a soft (correctable) error. Issue 1 can be tested by using the Exabyte (Tandberg) diagnostics to erase the tape into VXA-2 compressed mode before using the tape with Retrospect. Blank VXA-2 tapes, for compatibility, indicate that they are uncompressed. This bug has been seen before (and fixed) with Retrospect 6, and might have resurfaced with Retrospect 8. I always barcode and pre-label blank tapes, so I wouldn't have run across this issue, but you might test. Issue 2 can be tested by running on hardware that is not compute bound. I would expect such large inter-block gaps if you are running on a G5 PPC, because that architecture has to do all of the byte-swapping to fix things up for Retrospect 8's Intel-native (little-endian) format. You don't say what your underlying hardware is. Retrospect 6, which was quite mature and optimized, didn't have this problem because there wasn't the byte-swapping issue (Retrospect 6 was PPC optimized for big-endian). Also, I've never used the Firewire version of this drive, only the SCSI version, so I don't have a clue whether there is a performance penalty (whether because of Firewire I/O speeds or because of overhead with Retrospect's Firewire driver interface). Don't know whether Retrospect 8 has been optimized for speed yet - right now, it just "crashes quickly". Issue 3 is harder to test because you will have to get error-free transfers. Use new tapes, use a cleaning tape before each backup session. This issue, if the problem, can only be fixed as Retrospect matures, if that happens. Russ
  22. You misinterpret what a compare mismatch means. It means exactly that the data version retrieved from the media set (backup set) doesn't match the data version retrieved from the source. No more, no less. Usually that means that the file changed since backup, but not always. For example, RAID 5 issues can cause successive reads of data to be different (an explanation is far beyond the scope of this forum), as can uncorrected memory errors, I/O channel errors, bit errors in tape or disk media, etc. In short, it doesn't mean that the file on the source changed; it only means that data retrieved from the source doesn't match data retrieved from the backup. Not true. The data in the backup set (um, media set) just doesn't compare with the data read from the source. Either or both could be changed. You don't necessarily have the correct data in the backup set. Again, see above. Your assumptions are wrong, causing your conclusions to be wrong. Russ
  23. See my response to your duplicate posting in another thread here: Is it possible to use the old back up that was creaed to 7.6 to 7.7 version Russ
  24. I suggest that, before you do the upgrade, you study the EMC Retrospect 7.7 for Windows Read Me: Many people have discovered problems with the Retrospect 7.7 upgrade, and have been unable to easily go back because of this, um, feature. I suggest you review the comments in the Retrospect for Windows forum on this point. Russ
  25. You might want to RTFM. Retrospect 8 disk media sets are completely different from V6. And it's not one large file in R8. Russ
  • Create New...