Jump to content


  • Posts

  • Joined

  • Last visited

Everything posted by shadowspawn

  1. 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. 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.
  16. For interest: what did you boot from to run Carbon Copy Cloner? Did your CCC restore use the Retrospect duplicate as the master? Was the original firewire Retrospect duplicate bootable? Did you get any error messages from the failed Retrospect restores? I have not done a lot of whole-system restores, so this is an opinion formed on reading the Dantz documents and forums and limited personal experience. My impression is that Retrospect struggles to do a live-system restore, that is over the top of a running system. The system must be the "exact same system" as the backed up system, presumably because Retrospect can not safely replace system components which are different but are in use. This can be a major pain as it is a lot of work doing multiple updates to get everything back into the same state. I have had one live-restore work perfectly, and one live-restore choke on restoring the Retrospect client itself which I worked around with partial restores. What I am not clear about is whether it is much easier to restore onto a clean drive by getting the computer accessible from another source (like booting off a firewire drive, or using Target Disk mode). The Retrospect user guide says to install the "exact same version of Mac OS X" but goes on to describe a live-restore. Retrospect 5.1 and 6 have a bootable CD to allow clean disk restores if the original backup is accessible. Perhaps someone with direct experience can confirm whether clean-disk restores work smoothly in Retrospect, and whether there are limitations in older versions (like 5.0.238)?
  17. I have been hit with the "duplicate dirid" problem once, and did not get to the bottom of it. (I thought there were some known causes, but it sounds like you have checked the archives?) In my cases there were only a couple of folders, so I made new folders, moved across the contents, deleted the original now empty folders, and the problem has not recurred. So I don't know what the actual cause of the problem was, but for me there was an easy work-around.
  18. Short version: I think you need Retrospect 6. Long version. Retrospect 5 has a hard limit of 2 GB for the file catalog size, and 1 TB for the amount of data in the backup set. You are probably close to both! I personally have hit the 2 GB limit and I was very confused by the way Retrospect failed, with problems much as you describe. Large backups always gave the out-of-sync error because Retrospect could not add the information to the catalog. Small backups would actually work, because Retrospect could squeeze the information into the remaining space. I trashed a whole backup set because I thought there was a corruption problem, when in fact the problem was the backup set was "full".
  19. Is the computer set to go to sleep? Have you shifted Retrospect from where it was installed?
  20. I don't think you can turn that notification off. It is to give a user sitting at the computer a chance to defer the backup in case it would be inconvenient to have their computer busy at the moment. (For example they might be about to reboot, or are doing performance critical work at the moment.)
  21. The bad news is that there are a number of ways to shoot yourself in the foot with mounting network volumes, as Dave concludes. Two suggestions 1) Switch to the Reports tab in the Retrospect Directory window and click Reports. Find your problem volume in the Backup Report. How many elapsed days since it was last backed up? 2) Can you post the log entries from a backup that says no files needed to be backed up from your problem volume? Two observations 1) I personally much prefer using a Retrospect Client rather than using network mounted volumes. 2) FileMaker Server supports scheduled exports of databases. These backup copies can be backed up by Retrospect since they are not open by FileMaker. This avoids needing to shutdown FileMaker Server which has had some bugs leading to corruption when closing databases!
  22. A couple of comments: 1) The modifier key to force-stop the client is holding down Command while clicking the Off button. (You said Option, which might be a typo, or might explain why it did not work as well as expected!) 2) When I see a client hang and show still active, it has always been because the server crashed or I got a network error during the backup. (Like the 505 errors you have seen.)
  23. Nice one jalex, the route commands mean I can now access clients without altering network settings on desktop/Retrospect Server. Good luck with your problem!
  24. I was just looking at the same problem today with a somewhat different setup, and you have got further than me. I assumed because changing settings on the server fixed the problem that the server was at fault, but perhaps the client is implicated too. I suspect "Configure Subnet Broadcast" might help, but for me "This feature requires a more powerful application license code". :-) (I look forward to a solution that does not mean I have to turn off internet access on my desktop computer to back up clients on the local network.)
  25. Quote: Then why am I having this problem? I am using Mac OS 10.3.2 and HFS+. If the OS is not changing my inception dates, what's the deal? This is only my opinion and informed guesswork, don't take this as gospel. My expectation is that Retrospect stores a single modification time for each file, perhaps implicitly in current local time. There is likely to be some historical complications based on what was available when Retrospect started, and there are certainly some modern complications too. On HFS+ the internal representation of the modification date is in GMT. However, when an application asks the operating system for the date through any normal API what it gets back is in local time, since this is what the user expects. So after a daylight saving change, Retrospect gets back a different answer for the modification time (although nothing about the file has changed on disk). Although asking for the modification date is a simple question, it is surprisingly complex to answer. Leaving aside even what the "right" answer is, in practice the modification date returned for a file may depend on the operating system of the file server, format of the hard drive, time zone, daylight saving, etc. Some combinations are smart and try to return an answer based on the daylight savings at the historical date, rather than based on the current date. Some return the GMT-based time in local time (e.g. HFS+ with Mac OS X). Some actually patch the times on disk when the change is first noticed (e.g. Mac OS 8.1). This affects other applications too, cvs has ongoing fun and games because of the same issues even just on Windows ( Beating the Daylight Savings Bug ). So while I am disappointed Retrospect does not do better on MY configuration, which is after all simple and obvious to me, there are some hard issues.
  • Create New...