Jump to content


  • Content count

  • Joined

  • Last visited

Posts posted by rhwalker

  1. Mine won't work either. It's 8.20 (399) Multi Server Unlimited so I assume this is the right forum.

    Nope. Here's this forum's description:


    Desktop, Workgroup and Server for Mac OS X

    For general discussions on Retrospect Desktop, Workgroup and Server for Macintosh. [color:red]Pre-8.0 versions.[/color]

    The Retrospect 8 forum link is here:

    Retrospect 8 for Macintosh


    I have tried numerous times to schedule a script for 2:00 AM three days in the future. At 2:45 this afternoon, I cannot enter any time before 2:45 PM and no time after 11:00 PM EVEN though I'm starting it three days from now.

    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.



  2. 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.



  3. Is there anyway(without setting them up individually and waiting a month on each as thats how long it seems to take when for it to have an issue) that I can see which configuration is causing the issue and remove that from the file?

    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.



  4. If I go in and delete all the config files and set all my stuff up again w/ the same media sets, it works fine but I refuse to continue doing this every month.

    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.



  5. 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.



  6. Thanks! I got it rebuilding the catalog.


    I realize I could search for this probably... but in 6.1, how do I then get the files out of the catalog and accessible on my hard drive?

    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.



  7. I am fairly new to retrospect and am trying to pull some information off of old DLT tapes made with an older version of retrospect. How do I get to the data on a new system with the dlt tapes? I can write to a tape, but how can I pull files off of a tape if it was made years ago with a different computer?

    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".



  8. adding this client via hostname...


    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.



  9. The point is, I can't change the names. Many files are linked with the file name as reference. Or they are received from clients and we are not allowed to change the file names.

    Agreed. I'm in the same boat.


    So then the ":" in the BSD filenames would be the real reason, depending which library retrospect uses to access directories and files.

    I think until OS9 ":" has been the folder character and "/" has been a valid filename character.


    Failing handling this files would be consequent, but this would upset users, because the software doesn't do what the user think it does:

    - securely backup ALL files on the system irrespective of the "beauty" of their file names

    - files can be automatically verified

    - files can be later restored to the same status as before.


    Otherwise this backup application is no secure way to backup your files.

    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



  10. 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.



  11. Uh, no. "/" is not a permissible character for OS X's underlying BSD subsystem.


    Yes, but the Finder is lying to you. If you inspect such a file using tools other then Finder, you'll find the actual character in the name is ":"


    Retrospect "Classic" was blind to OS X filesytem realities; it was simply a Carbonized version of Retrospect 4. The fact that it didn't choke is not related.

    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.



  12. So in the release notes for 8.2 is this phrase:


    [color:red]-The ability to restore from backups created with Retrospect 6 for Mac[/color].


    So I take this to mean that I can use tape catalogs in 8.2 without having to 'rebuild' them.


    So if I am CORRECT, how does one import these 6.1 catalogs into 8.2?


    If I'm WRONG, who's got time to rebuild all these catalogs from the tapes?

    This is a case where it helps to read the documentation. You stopped reading too soon.


    From the Roxio Retrospect 8.2 Read Me:


    Restoring from Retrospect 6.x backups


    Retrospect 8.2 can restore from Backup Sets created by Retrospect 6.x for Mac (except those of type Internet). However, it is not possible to add more data to these Backup Sets using version 8; Retrospect 8 treats version 6.x Backup Sets as read-only.


    [color:red]Before it’s possible to search or restore from a 6.x Backup Set using Retrospect 8, a Retrospect 8-style Catalog must first be created.[/color] To create a version 8 Catalog from the 6.x media, go to the Media Sets view in Retrospect 8, click on the Rebuild button in the toolbar, add the Backup Set members (like “1-Backup Set A†and “2-Backup Set Aâ€) that contain the backup data, click Next, and then click Rebuild. You will need to tell Retrospect where to save the new Catalog. Retrospect will then scan over the backup media and generate a new Catalog. [color:red]This will take some time.[/color] Once this process completes, you will be able to restore from that Backup Set.

  13. 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.



  14. 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.



  15. 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



  16. 2 - are subnet broadcasts blocked?

    if so then the Retrospect server can not send the needed network 'query' to find the clients on the 2nd subnet.

    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.



  17. 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.



  18. I disagree with Russ on one point: the utility of a full comparison verification can be useful even if volumes are changing. You may be perfectly fine with changed files, and because they are logged so that you can identify them the process can be useful.

    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.


    A file that does not pass verification is still backed up, it just did not pass verification.

    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.


    A project share may need to be backed up at night, but Marketing may be working on a presentation through the night so their one file may change. Yet, you still know at the end that the backup is intact, except for acceptable changes to the system (i.e. "yep- Marketing was working last night"). If you need (or rather, desire) full comparison backups then by all means do them- quite often the results are still useful, and they allow a more thorough backup check than MD5 alone.

    Again, see above. Your assumptions are wrong, causing your conclusions to be wrong.



  19. I suggest that, before you do the upgrade, you study the EMC Retrospect 7.7 for Windows Read Me:


    Upgrading from a Previous Version of Retrospect


    Older Backup Sets: If you are an upgrade customer, you can use your older Backup Sets with Retrospect 7.7. However, once you use a Backup Set with Retrospect 7.7, you can no longer access it from earlier versions of Retrospect.

    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.



  20. im not sure I see that this is any different than the disk file from v6. 1 large file contains everything, and I dont care about the underlying implementation - until or unless I have to rip it apart because something failed.

    You might want to RTFM. Retrospect 8 disk media sets are completely different from V6. And it's not one large file in R8.