Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Axiom

  • Rank
    Occasional Forum Poster
  1. Since you ask, I also have seen a stark slowdown recently, and that's why I'm here, looking for answers. However, I have not updated to 10.5.8; my server is still running on top of 10.5.7. Copy times appear to take the same amount of time as always, but scanning times have increased to the neighborhood of 6 times longer than normal. Here are the respective versions of what I'm running: Retrospect Server: 6.1.230 Retrospect Clients: 6.1.130 (mostly) and 6.3.019 (two Retrospect 8 clients, compatible with Server 6) OS X Server: 10.5.7 Retrospect 8 Server: 8.1 (build 150) Yes, I'm running 6 & 8 side-by-side, but I did read that this is supported. 8 Has been installed for months now without a problem. Slow scanning only began on Monday 8/24/09, according to my log. I have no record of changes to my configuration over the weekend, so I'm at a loss. My network team confirmed that all was well on that side of the equation. I'm interested to hear more about your own situation, buddyjack2.
  2. Has anyone else had problems with threshold settings and the new client? While attempting to backup a Mac network client updated to 6.2.229, the Backup Server script ends immediately, without scanning or attempting to copy data. In the log is this message: "The backup client is too slow (measured 0 KB/sec, threshold 60 KB/sec)". Earlier that same day, when the client was still on 6.1.130, the backup completed fine. I made no changes to the client except updating it to 6.2.229. I made no changes to the script. I updated the server to 6.1.230. Nothing else changed. In troubleshooting the issue, an Immediate Backup was successful, but of course it offers no threshold options. When I turned off the client threshold requirement for the original script, it scanned and copied completely - at a fantastic rate for our environment, I might add. A scheduled Backup script type with an identical threshold failed in the exact same manner as the Backup Server script. It would appear the problem lies with the server script threshold setting and the 6.2.229 client, as older clients backed up by that same server are not affected. I wish it wasn't necessary to set the threshold for my clients, but it's the only way to keep the script from camping all night on a slow client with an incorrect Ethernet configuration. Any ideas? Thanks in advance. P.S. Assorted technical info: -Retrospect Server: 6.1.230; XServe (2 x 2 GHz Dual-Core Intel Xeon, 2.0GB RAM); OS X Server 10.5.4 -Retrospect Client: 6.2.229; MacBook Pro; OS X 10.5.4
  3. Scotty321, Do you have any non-Intel Mac laptops running the Retrospect client in your environment? Because I have seen LOTS of problems with Retrospect server being unable to locate clients for a wide variety of reasons, with a slew of workarounds. Our biggest problems have very little to do with Intel, and lots to do with configuration issues related to portables. For example, in our heavily VLAN'ed large network environment, DHCP confuses our Retrospect server to no end. Also, I have seen battles on clients between Airport and Built-In Ethernet which render Retrospect unable to communicate properly with them. Finally, 10.4.9 was just released, and it purports to resolve specific network problems with Intel iMacs (such as duplexing). Since we have also been seeing identical networking problems with MacBooks, we plan to test this OS update and hope to the higher power that it addresses what we are seeing. Let us know if you learn anything more. Good luck!
  4. I've seen this numerous times on our clients. The most common cause I've seen is that the root account is not enabled on the Mac. To enable root, open NetInfo Manager from /Applications/Utilities, then choose "Enable Root User" from the Security menu. (Although some claim you have to install the client while logged in as Root, installing under an administrator-level login is adequate as long as root is enabled on the system.) You _may_ need to reinstall the Retrospect client before your situation improves. I have found this to sometimes be the case. On rare occasions, I actually have to reboot _between_ the uninstall and re-install before things go well. Good luck, and let us know if you get it resolved!
  5. I went through this same dilemma a while back. The above posters are correct regarding Mac Retrospect's features, but there are workarounds - at least for my situation. We use file backup sets (nightly incrementals) on our XServe RAID, and then back those up weekly onto LTO-2 tape for an off-site rotation. I wish I could say it's been bullet-proof, but it has been serviceable, and it is the best option we have right now. I have tried BRU, as well as NetVault - which are the only other network-client capable backup servers for the Mac platform - and they may have great features, but their interfaces leave a lot to be desired. I don't have time to learn them, so for now I stay with Retrospect.
  6. Chris, Any luck? It looks like you asked this question a while back. Me - I just got here. Here's a couple ideas we were considering in our own situation: -adding RAM to the client -completely rebuilding the hard drive - clone, erase, low-level re-format Good luck.
  7. Carillon, I have experiences not unlike yours. Do you know for a fact that the client Mac is on and awake at the time the backup takes place? Users don't always know what is needed of them; sometimes they log out or put the machine to sleep. You never know.... I did see a number of machines that acted strange like this, for a wide variety of reasons, including sleep, network, and corrupted client. Sounds like you've eliminated the 1st one. An uninstall / reinstall of the client as root took care of the last. I'm still working on the 2nd cause (network). Keep us posted. Good luck.