Jump to content

shadowspawn

Members
  • Content count

    215
  • Joined

  • Last visited

Community Reputation

0 Neutral

About shadowspawn

  • Rank
    Retrospect Junkie
  1. shadowspawn

    Painfully slow network back-ups

    Short version: I am seeing good speeds with latest software. Long version I had a lot of performance problems with the beta versions of Retrospect 8. I'm just getting set up with the release version. Initial backup speed was awful, but I discovered the external hard drive was showing up as USB 1 which rather crippled performance! Switching it to firewire and running full backups... Retrospect Server running on iMac with 1 GB RAM (Console v8.0.608.1) Local backup from internal hard drive to external firewire hard drive Completed: 540819 files, 119.1 GB Performance: 860.8 MB/minute (687.7 copy, 1150.2 compare) Duration: 04:50:18 (00:07:11 idle/loading/preparing) Backup of client v6.3.019 running on PPC Mac Mini over 100 Mb ethernet Completed: 340507 files, 30.2 GB Performance: 210.8 MB/minute (137.0 copy, 456.8 compare) Duration: 05:05:09 (00:12:05 idle/loading/preparing)
  2. For reference, these other two threads cover the same issue: 2 copies of Retrospect started by scheduler Scripted backup complains about locked files jwarthman observed there: I have a bit more information. I have observed that, for me, this problem ONLY happens the first time Retrospect runs a scheduled backup after the Mac is restarted. This was the case for me too, but I have so few observations points that it is scarcely a confirmation. Can some of the people having a repeatable problem confirm whether they ever see the problem after the first launch following a restart? (mbizer in this thread only sees the issue with one script, which is a surprising development!)
  3. Note that a likely work-around is to leave Retrospect running (as Twickland mentioned). I do this on my home machine, I got into the habit when there were issues with Retrospect launching from the login screen. I have only ever seen the two-retrospects issue twice, from times I did not have Retrospect already running, once today! The only scripts I use are backup server scripts. Retrospect 6.0.212, only scheduled script is a Backup Server script. Just confirming that I have a single RetroRun, and it is the same copy of Retrospect running. [Thumper:~] john% ps -auxwww | grep Retro root 1401 1.0 2.2 91940 19988 ?? S 2:57AM 50:34.37 /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Retrospect 6.0/Retrospect/Contents/MacOS/Retrospect root 1403 0.0 2.6 113540 23924 ?? S 2:57AM 47:53.51 /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Retrospect 6.0/Retrospect/Contents/MacOS/Retrospect root 1425 0.0 0.0 28588 208 ?? Ss 2:57AM 0:06.75 /Library/StartupItems/RetroRun/RetroRun john 1791 0.0 0.0 27384 436 p1 S+ 10:56AM 0:00.01 grep Retro
  4. Glad the console messages are fixed but it might be a couple of days before you can tell whether the performance problems are gone, fingers crossed. A problem with the client is moving or renaming the client after the install. I expect there are similar problems with the Retrospect application. A reinstall is a simple fix. If you hit the performance problems again, I suggest checking for whether the CPU is being hogged, using Activity Monitor. This doesn't explain why only some applications are affected, but I have seen Retrospect burning the CPU when confused about hardware status.
  5. shadowspawn

    Any VXA users on Mac OS X?

    On the whole I liked using VXA-1 tape drives, but did have some issues. I sometimes have problems getting the VXA unit recognised, but a reboot with the device turned on always works. I did have some hardware issues with the VXA drive over the years, but Ecrix were very responsive about getting the unit repaired. I do recommend staying away from SCSI -- it can be hard to find a supported SCSI card that plays well with your operating system, computer, and tape unit. (Currently most of my backups are to external firewire drives. The VXA-1 unit is seldom used, too small now!)
  6. I am not seeing the same issues. I am running Mac OS X 10.4.2, Retrospect 6.0.212 and Retrospect 6.0 Driver Update 6.5.102. I checked for Console messages and interaction with FileMaker 7. IMHO, the console message suggests an installation problem. Retrospect reconfigures the background scheduling application (RetroRun) when it is launched, and this might be failing. Have you tried reinstalling Retrospect? And more speculative questions: Do you have devices connected for backup use, like tape drives or libraries? Is Retrospect idle when you launch it? (Sitting at the Retrospect Directory window.) Is the logged in user an Admin user? Is there only a single user logged in? What is running before and after you launch Retrospect? Try "ps -auxwww | grep Retro" in Terminal. When I try this without Retrospect running I see a RetroRun process owned by root. john% ps -auxwww | grep Retro root 2113 0.0 0.0 28588 432 ?? Ss 4:29PM 0:00.00 /Library/StartupItems/RetroRun/RetroRun john 2120 0.0 0.0 18060 260 p1 R+ 4:29PM 0:00.00 grep Retro and then after launching Retrospect I see a new RetroRun, and Retrospect, both owned by root. john% ps -auxwww | grep Retro root 2142 0.4 1.0 97636 8828 ?? S 4:33PM 0:06.66 /System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp /Applications/Retrospect 6.0/Retrospect/Contents/MacOS/AuthenticateUser.app/Contents/MacOS/../../../Retrospect root 2149 0.0 0.1 28592 608 ?? Ss 4:33PM 0:00.03 /Library/StartupItems/RetroRun/RetroRun john 2157 0.0 0.0 18060 236 p1 R+ 4:37PM 0:00.00 grep Retro
  7. You can change the script. You can run multiple scripts to the same backup set. You can mix manual and scripted backups. You are probably safer to let the iPhoto library script run every day rather than remembering to run it when required. If nothing has changed, then nothing gets backed up.
  8. I do not try and "transfer" the client as such. Instead I sort out the old computer and new computer separately, both fairly simple. 1) If the old computer is being decommissioned then uninstall the client. Otherwise, rename the client to match the new owner: connect to the client and from the configure tab, use the Rename button. 2) Install a Retrospect client on the new computer and set it up as normal.
  9. The "trust nothing" moral is a good one for backups. However, I haven't learnt anything from your posting about what to avoid. How were your backups affected by a drive name change? Only backup files matching some selector? Specific volume listed as source? Backing up only selected volumes in Client setup? (I don't like this one because it is fragile and invisible.) Mounting a volume over file sharing? (I much prefer using a client!) Backup script? Backup Server script? In my experience drives don't just disappear from backup scripts, although it is certainly possible to have backups fail in quiet ways. Part of "trust nothing" is finding out how to monitor whether things are working. The log tells you about some problems, but not all. The Report window is a good place to browse for volumes or clients that have been lost due to configuration issues.
  10. There was a problem if the Retrospect client installer was run off a network volume. The installer would fail to authenticate properly, which could lead to partial installs that were not fully functional. Copying the installer to the local hard drive and running it from there works fine.
  11. You get the option on the script because some of the clients may be running Mac OS 9. It has never applied to Windows clients. Personally I now don't shutdown any of my computers, it is so convenient coming back to the computer and having it instantly available. I do still have some computers set to automatically sleep though. There are (at least) two options to allow backups to run despite having clients asleep. One option is using the "Wake for ethernet network administrator access" setting. Retrospect does not support this, but third party utilities do. Another option is to use the Energy Saver settings to have the client automatically wake up for a period when the backup server is active.
  12. Like Dave said. In fact leaving the computer at the login window is pretty good for the Retrospect client, less chance of file contention, lots of resources available for Retrospect. I expect the same is probably true of the backup, but the manual only mentions restores: Quote: For ideal restoring conditions under Mac OS X, log out so the login window appears. Leave the client Macintosh at this window, do not log in, shut down, or restart.
  13. I had the same problem, and admit I never fully diagnosed the problem after I found a work-around which suits me. I login and launch Retrospect, then switch to the Login Window. Then the backups run fine (since Retrospect is actually already running). This only works if someone does it after each reboot though!
  14. The number one reason for this is that the client application was shifted after the install. When the computer reboots, the startup script does not find the client and launch the background daemon (pitond), and no backups until you start it manually using the client application. Reinstalling (as Natew said) is the easy way to get the startup script and the application location back in sync.
  15. Quote: Any idea why client will not open up? I think the installer does not authenticate correctly when run from a file server. If you copy the client installer to the local disk before running it, things work correctly. I suggest reinstalling the client (running the installer from the local disk) and see whether this fixes the problem.
×