Jump to content

rhwalker

Members
  • Content count

    5,089
  • Joined

  • Last visited

Everything posted by rhwalker

  1. Retrospect is trying to protect your data and will not write to the wrong tape. Think of the chaos that would occur if Retrospect were to write to random tapes - Restore would be a mess because the data would be all over the place (if it could be found). Get an autoloader. It will change your life. Really. It's the only way to do tape. Russ
  2. rhwalker

    Catalog File is locked

    It's also possible that ACLs are entering into the equation. An appropriate ls -aloe in terminal would be instructive.
  3. Yep. Exactly what are your matching options? Russ
  4. rhwalker

    Wake On LAN (WOL)

    See this thread here for a very good analysis of what happens and why it is broken: Wake on LAN doesn't work
  5. Did you enable optical support? See: Retrospect 8.x for Macintosh Optical Support
  6. Perhaps the following thread would help: Disaster Recovery CD with static IP Russ
  7. You may be seeing interactions between the Leopard firewall and Retrospect as well. Try with your Leopard firewall turned off.
  8. Details in these two Knowledge Base articles: Multicast KB article See the last paragraph in this KB article: Client discovery There's also a multicast diagnostic written by one of the Retrospect programmers: Multicast Ping If you still can't get it working, report back and we can go from there. It would be helpful to know your network infrastructure. Russ
  9. While I only use tape, I use a similar (but modified) version of your option (a). Specifically, set up the two media sets to alternate their backup days in the script. (e.g., MWF and TThSatSun) That way, you have a known schedule for doing the rotation. Or, depending on your rotation frequency, alternate by weeks. Understand that each media set will back up all changed files since the last time that media set was used, not just changed files from the previous backup session. Also, before making your decision, you really need to establish the requirements of your backup policy. That will tell you how you should do this. Here's a good list of the things to consider: What should a good backup policy address? Some browsers don't like the actual link, which is why I provide the TinyURL link. The actual URL is a bit odd, but here it is: http://iwiring.net/#[[What%20Should%20a%20Good%20Backup%20Policy%20Address%3F]] Another possibility is to consider a "Proactive" backup, which does the backup to media as it becomes available. This is one of the newer features of Retrospect 8. Right now, I'm trying to stay with the "tried and true" features until R8 becomes more stable. The Beta is looking very good, though. Russ
  10. rhwalker

    Upgrading from XProSP3 to Win7 64

    Well, you are certainly correct in [color:red]hoping[/color]. Usually it works.
  11. Sure that your version number doesn't have a typographical error? I don't believe that there was ever a Retrospect 6.1.32. The last released version of Retrospect 6.x was 6.1.230. This problem has been around for years. Search the forums. For example, see: Two Simultaneous Backups Running It was supposedly fixed in Retrospect 6.1.138. Try updating your copy of Retrospect 6.x and Retrospect Driver Update ("RDU"). The updates are here: Retrospect 6 Updates I used to see it often in the earlier versions of Retrospect 6, but only saw it about once or twice a year in Retrospect 6.1.230. I seem to recall that it would often happen when Retrospect would autolaunch to run missed backups when a server was restarted after a crash. It may be that you have a corrupted retrorunfile (the file that does autolaunch). With Retrospect quit, delete the "retrorunfile" file, restart Retrospect, then quit Retrospect, and it will regenerate a good retrorunfile. It's location is /Library/Preferences/Retrospect/retrorunfile Regardless, Retrospect 6.x is a dead product, end-of-life, and will not have any further bug fixes. Russ
  12. rhwalker

    Upgrading from XProSP3 to Win7 64

    Andrew, As I understand your question, you are about to upgrade the Machine on which Retrospect is installed to Win 7 64, and this will require erasing the volume (partition) on which Retrospect is installed. You want to know how to do this safely so as to preserve your Retrospect installation. See the section in the Retrospect Users Guide entitled "Moving Retrospect" on page 272. Here is the link: Retrospect 7.5 / 7.6 Users Guide Although that section discusses moving Retrospect to a new computer, you are effectively doing the same thing, and so the same files need to be saved/restored. Be sure to download/install the Retrospect 64 bit installer image here: Retrospect 7.7 for Windows downloads Russ
  13. rhwalker

    Src - Dest Date/Time off by seconds

    I understand. When Retrospect does the duplicate (copy), the NAS sets the dates. Then, when Retrospect tries the second duplicate, the times are different. Retrospect is just reporting metadata that it finds. Try copying by another mechanism (say, a shell script) and compare the times. Now, it's possible that Retrospect might be able to work around this by changing dates/times after the copy, but, as it is, Retrospect is at the mercy of the NAS and how the NAS decides to store metadata. You might want to check the timesync source on the NAS. You also might want to investigate the underlying filesystem type for the XP and for the NAS. For example, if the NAS has a unix/linux filesystem, it might not support the same timestamp metadata granularity as the XP. An interesting test would be to duplicate (copy) from the XP to another directory on the XP system. That would rule out different NAS timestamps. Try a bunch of the files that are reporting this issue. Russ
  14. Ok. That answers the question. It's not a Mail bug. When sending, Retrospect crafts the "Date:" header, which is wrong (see the raw headers). The bug is on the Retrospect engine machine, not at the mail server and not at the machine where the Mail is read. For some Reason, the machine that Retrospect engine is on thinks the system is CDT or EST (GMT-0500), not EDT. I believe this is a Retrospect bug, but you might want to check the settings on the Retrospect machine. Are the Retrospect engine's logs correct? My testing is still in the early stages on the Beta (using an isolated testbed), and I'm not sending emails yet. Russ
  15. Ok. From these headers (especially the first - bottommost "Received:" header, the email was accepted for delivery at 19:49:00 EDT: That shows that your mailserver is set up for EDT, and the Mail program seems to know that as well. Are you sure that these machines and also the machine on which you are reading your mail BOTH know that they are on EDT? That's a different question from both of them showing that they have the correct GMT offset of -0400. If it's an obscure bug, I might not be able to replicate because our Retrospect machine is also our mailserver. Seems that you have a different mailserver. Also, I know of a few bugs where Apple's Mail program incorrectly interprets the Date field. What does the "Raw Source" of the SMTP headers look like (Mail: Message > View > Raw Source) (so that the Date field won't be modified by Mail)? Russ
  16. rhwalker

    Src - Dest Date/Time off by seconds

    Retrospect is reporting the dates/times on the NAS file metadata, and those are set by the NAS when the files are duplicated. Check your NAS timeclocks. The right way to do this is to have one local timeserver that syncs to an external timeserver, then have all of your local machines (and NAS, etc.) timesync to the local timeserver. This problem does not occur when backups are made (a duplicate/copy is not a backup) because Retrospect stores the correct metadata in its database (the backup set). Russ
  17. It would be helpful to post the SMTP headers for the notification email. That will show where the problem occurs. Russ
  18. rhwalker

    Server Stopping/Crashing(?)

    Right. There never has been in the 17 years or so I have been using Retrospect. Many have made a request for such a feature over the years.
  19. rhwalker

    Finally Gave Up on Retrospect 8

    Be sure to post any bugs you find so that the actual release can have them fixed. Russ
  20. rhwalker

    Server not starting

    Please explain exactly how Retrospect was moved to the new machine. There is a section in the Users Guide on how to do this. Did you follow those instructions exactly? You don't say what version of Mac OS X you have. Presumably it's some version of 10.6.x if you have a new machine. Russ
  21. rhwalker

    USB Quantum DLT-V4

    Then the right place for your post would have been the Retrospect 8 forum. Here's the link: Retrospect 8 forum If you have problems, post to the Retrospect 8 beta forum. Here's the link: Retrospect 8 Beta forum I wouldn't waste my time with the Retrospect 8.1 release, the beta is a big improvement, many bugfixes. Not perfect, but it is much better than the Retrospect 8.0 and 8.1 release. Russ
  22. rhwalker

    Finally Gave Up on Retrospect 8

    Make your own assessment. However, if you start clean (with new preferences - delete the config80.dat and config80.bak files if necessary) and reconfigure from scratch, and if you don't have local volumes or "favorites" on 10.5.x clients, you won't see this bug, which, if you had posted the warning with its context, would be clear. I suggest that you read the entire thread for the Beta Read Me to understand the significance of this warning. Retrospect 8.2 Beta Read Me thread The 8.0 and 8.1 "releases" were premature. The 8.2 Beta, while not perfect, is a great improvement, and you should try it. Russ
  23. rhwalker

    USB Quantum DLT-V4

    yep. New devices will never be added to Retrospect 6, which is end-of-life. You might download a trial license copy of Retrospect 8 to see if it works there. I'd suggest using the Retrospect 8.2 beta rather than the 8.1 released version. Russ
  24. The problem with your workaround is that the share is presented with the credentials from the AFP login, and may not present the entire volume. That's the whole purpose of the Retrospect client, to run setuid root so that the entire volume can be accessed. You really ought to investigate the cause of this bug and get it fixed. Because you haven't provided any version information, we don't have a clue as to what version of 8.x.x you have, nor what version of Retrospect client you are running, nor what versions of Mac OS X are running on the Retrospect engine machine or on the client, or what architectures (PPC or Intel) are on the Retrospect engine or on the client. All of that information may be relevant to finding out the cause of this issue. Russ
  25. rhwalker

    Tape library stuck in endless loops

    I'm confused. I don't know which Intel xServe you have, but I was under the impression that both xServe slots (one half-length, one full length) were PCIe 2.0-16. Russ
×