Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


wdroome last won the day on October 13 2013

wdroome had the most liked content!

Community Reputation

3 Neutral

About wdroome

  • Rank

Profile Information

  • Gender
    Not Telling
  1. #1: I've used retro 10.5 on MacOSX 10.9.1 for a month now. It seems to work well and it's stable -- although I have a very simple setup. Only two problems: RetroISA wants to scan any disk I connect, including flash drives. What's worse, RetroISA won't let go -- I can't unmount the drive until I stop RetroISA. So I just turned ISA off. Incidentally, with retro 10, you can disable RetroISA from the System Control Panel, rather than with a terminal command. The other problem is that I cannot always update rules. That seems to be a user permissions problem -- to change rules, I have to reboot and login as the admin user that installed retro. Logging in as another admin user doesn't work.
  2. The problem: Retro will not let me save rule updates. I get the rule-update screen, and I can add items to the list, but "SAVE" is greyed out. The problem is related to how I log in. Retro 10.5.0 (145), MacOSX 10.9.1, macbook pro. It's a single-computer backup setup -- the retro server and client run on the same laptop. I use two "Disk Media" backup sets, on two different external drives, in two locations. Background: when the laptop was new, I created a backup admin login, "xadmin", and used that to install Retro and setup my rules. I later created my normal login, "wdr", using migration assistant, and I use that for most work. "wdr" has admin privileges. If I restart the laptop and login as "xadmin", I can update rules. But if I do anything else, I cannot. Specifically, if I restart and login as "wdr", I cannot update rules. If I then logout "wdr" and login "xadmin", I cannot still update rules. So it's not just that I have to be "xadmin" to edit rules; it's more that if I ever login as any other user, it somehow poisons the pool and that persists until I reboot. Other than that, retro seems to work fine.
  3. For me, retro 10.2 was dead-on-upgrade -- totally useless. On the other hand, 10.5 works fine. And so far it's been very stable. One improvement I noticed: in 10.5, retroISA finally works properly. Before 10.5, the retroISA process created a steady background load on my hard drive (it read 1-2 megs/sec almost constantly). Furthermore, backups actually took longer when ISA was enabled. As a result, before 10.5. I always disabled ISA. With 10.5 and ISA, backups take 10-20% less time. - Wendy
  4. FYI: 10.5 fixed the problem. But auto-update didn't work. I had to download 10.5 from the web site manually. Here's how I managed to install it: * Stop the retro server (if running) and quit the retro app. * Copy the retro app from the dmg to Applications. * Start new retro app. It hangs "connecting", 'cause it can't contact the server. * Start the retro server (via System Prefs) * Wait for retro app to detect the server is old, and ask to upgrade server -- but don't click "yes" yet. * Stop server (via System Prefs), and wait for it to stop * Click "yes" to allow retro app to upgrade server * The server should start automatically once it's upgraded. So far 10.5 seems to work fine. - Wendy
  5. I use a "Disk Media Set". The files are all on one 1TB hard drive. I keep the catalog on that drive as well. I know that Retrospect recommends keeping the catalog on the boot drive. And if I spread the disk files over several different drives, that would make sense. But I don't. I realize that if the external drive gets corrupted, I'll lose the catalog. But if that happens, I'll lose all the backup files as well. Then what good is the catalog? Also, I'm backing up a laptop (yes, the Retro server runs on the laptop). I suspect it's far more likely that my laptop's drive will die than my external hard drive. Particularly because I only connect the external drive when I'm doing a backup. For redundancy, I have two separate disk media sets, on two different external drives, one at home and one at work. There are no .rbc files on the boot drive -- sudo find / -name '*.rbc' returned nothing. I realize this isn't what the Retrospect folks recommend. But it's worked up to version 10.1. And while the Retrospect designers have the right to design the program however they want, I have the right not to use it if it doesn't meet my needs. And right now, it's looking more and more like Retrospect doesn't. Time machine & SuperDuper may be sufficient.
  6. @BMDStudios: Thanks, but that didn't help. @Mayoff: The problem may be that not all of the catalogs aren't mounted. I use "backup to external disk", and I keep the catalog on the external disk as well as the backup files. Why? Because a catalog is upwards of 15 gigs, and that's a significant bite out of my laptop's hard drive. I also use time machine, and I don't want TM re-writing those catalogs every day or so. I actually have two external disk backup sets, one at home & one at work. I only connect the backup disks when I want to do a backup, and then I manually start the backup. Eg, I do not have any scheduled backups. I did enable "grooming," but I don't know if the server actually tried it. The backup disks are only 2/3 full. I've tried it with the "work" disk connected. The server starts ok, but when I start the UI app, it connects to the server, displays some info about the server .... and then the server crashes. The server restarts, the UI app reconnects, etc, etc, etc. I haven't tried it with the "home" backup set yet, nor have I tried it with both disks connected. Yes, I know that isn't the "recommended" way to set Retrospect up, but it's worked for many years. In any case, apparently all knowledge of "the backup sets" and "catalog locations" is hidden somewhere in the server's data files. The only way to access them is via the application -- and the server crashes 2 seconds after the UI connects to it. Any advice as to what to try next? - Wendy Roome
  7. How do I delete the server? Just remove /Library/Application\ Support/Retrospect/RetrospectEngine.bundle Or is something else required?
  8. I just upgraded from 10.1.0 to 10.2 (on MacOs 10.6.8). I used auto-update, and as far as I can tell, it upgraded the engine as well as the app. But now retrospect totally broken. I can start the RetroEngine, but when the app connects to it, after a few seconds, RetroEngine drops the connection. Mac console gives these errors: 08/08/2013 10:35:24 AM com.retrospect.retroengine[382] DAGServer:RegisterProtocal Protocal(GUID=200) 08/08/2013 10:35:25 AM Firewall[68] RetroEngine is listening from proto=6 08/08/2013 10:35:27 AM Retrospect[319] [ENGINE] connected to '' (, 08/08/2013 10:35:28 AM com.retrospect.retroengine[382] Assertion failure at "db.cpp-170", on threadID 0x107C10000 08/08/2013 10:35:28 AM Retrospect[319] Server::updateBackupSetsCache exception: MacRequestor::Request: connection closed by remote endpoint 08/08/2013 10:35:28 AM com.apple.launchd[1] (com.retrospect.retroengine[382]) Exited with exit code: 255 08/08/2013 10:35:28 AM Retrospect[319] Server::updateSetsChangeCounter exception: MacRequestor::Request: connection already closed 08/08/2013 10:35:28 AM Retrospect[319] Server::updateScriptsCache exception: MacRequestor::Request: connection already closed 08/08/2013 10:35:28 AM Retrospect[319] Server::updateScriptsChangeCounter exception: MacRequestor::Request: connection already closed 08/08/2013 10:35:33 AM Retrospect[319] connectViaQueue: exception "MacTCPconnection::Connect: connect() failed with error 61: Connection refused" connecting to I found the following assert error in the retro log files: Thread ID: 0x0000000004384000, Name: Server thread rax:0x0000000000000001 r8:0x000000005203aa77 r12:0x0000000104380bf0 rip:0x00007fff8484e466 cs:0x0000000000000007 rflags:0x0000000000000202 rbx:0x0000003000000000 r9:0x000000010437fad0 r13:0x0000000100823083 rsp:0x000000010437fae8 rbp:0x000000010437fb20 rcs:0x000000010437fae8 r10:0x0000000000000347 r14:0x00000001007ca5a0 rsi:0x000000010437fb0f fs:0x0000000000000000 rdx:0x0000000000000000 r11:0xffffff80002e4730 r15:0x0000003000000000 rdi:0x000000000000000c gs:0x000000000000000f Module Function + offset into function Args _______________ ________________________________________________ _______________________________________________________________________ libSystem.B.dyli read +0xa libmeson.dylib doTask(long long, long long (*)(...), Mo +0x769 libmeson.dylib TThread::TaskCall(long long, long long ( +0x37a libmeson.dylib TThread::MsgBlock(int) +0x8c libmeson.dylib msgInTask() +0x16 libmeson.dylib doTask(long long, long long (*)(...), Mo +0x769 libmeson.dylib TThread::TaskCall(long long, long long ( +0x37a libmeson.dylib loopInTask(int) +0x42 libmeson.dylib doTask(long long, long long (*)(...), Mo +0x769 libmeson.dylib TThread::TaskCall(long long, long long ( +0x37a libmeson.dylib TThread::MsgLoop(int) +0x4a libmeson.dylib serverThread() +0x98 libmeson.dylib doTask(long long, long long (*)(...), Mo +0x769 libmeson.dylib TThread::TaskCall(long long, long long ( +0x37a libmeson.dylib modThreadRoot(void**) +0x208 libmeson.dylib modThreadHelperRoot(void*) +0x4d libSystem.B.dyli _pthread_start +0x14b libSystem.B.dyli thread_start +0xd Any ideas before I give up and see if I can restore to 10.1? - Wendy Roome
  9. Does anyone know whether Retro 8 works with MacOS X 10.5.7?
  10. wdroome

    Waiting for media

    I have to disagree with this as a blanket statement. Yes, Disk Media Sets have compelling features that make them more powerful in most all regards. But what has always ben powerful about File Storage/Backup/Media sets is the integration of the catalog and the data. Depending on the user's needs for access, for speed, for versatility of storage, having all the digital data necessary for a Restore in one place (without the need to take time to rebuild a catalog) can be a compelling feature. Although the developers discourage it, you can keep the catalog together with the backup data. I'd been using file backups in Retro 6, and I switched to disk media backups for 8. I create a top-level folder called "Retro 8 Backups" on my backup drive, with folder "Catalogs" under that. When creating a disk media set, I tell retro to put the catalog under Catalogs, and when I create the first (and probably only) member, I point retro at "Retro 8 Backups." It's worked fine so far. The advantage is that instead of having one continually-updated 100+ gb file, I have a lot of write-once 600 mb files. That makes it practical to copy the backup files to some other disk for off-site storage.
  11. I've run into some problems with Disk Media Sets. I don't know whether they're bugs or not-yet-implemented features. Or maybe I've missed something fundamental. Or maybe I'm just want them to be something that the Retrospect developers never intended them to be. I think of Disk Media Sets as a better implementation of File backups for backups to hard drives. The advantage is that Disk sets break the backup into small files, instead of one huge file. That makes it practical to copy the pieces to some other drive, or to CD/DVD/etc. Here's how I thought Disk Media Sets worked. The set has a number of members. Each member is a folder with a bunch of backup files. And I could have multiple members on the same hard drive, each with a max of (say) 4.7g of backups, so they're be easy to roll out to DVD. So my backup hard drive would have: /Retrospect --/MyBackup ----/1-MyBackup ------ 4.7 gigs of data files ----/2-MyBackup ------ 4.7 gigs of data files ----/3-MyBackup ------ etc I could have sworn that some Retrospect documentation, or maybe one of the videos, said I could have several members on a hard drive, just as above. My problem: I can't get Retrospect to create more than one member on a hard drive. Okay, I can if I create a folder for each member, and let retrospect create three layers of folders under each one, but that's TUTL ("Too Ugly To Live"). Any suggestions? Is there some trick to creating multiple member on the same drive, but I just missed it? Is this a not-yet-implemented feature? Or should I accept that a drive has one member, period, and live with it? That does seem to work. And while eventually that folder could have a thousand or more files, I could deal with that if I had too. But it seems so much cleaner to have multiple, smaller, members per drive.
  12. Max HFS+ file size is 2**63 bytes. Yes, really: see http://developer.apple.com/technotes/tn/tn1150.html I suspect that (say) a single terrabyte file is less efficient than 1000 gigabyte files, but I don't know if you'd notice the difference in practice. The advantage of a Disk Set is that it splits the backup into smaller, more manageable pieces. You can copy those pieces to other media (DVD, hard drive, whatever), for extra protection or for off-site storage. A Disk Set can also span volumes. Another disadvantage of a File is that it "puts your eggs in one basket," so to speak. If that file gets corrupted, you're dead. With a Disk Set, if one file gets corrupted, you lose whatever's in that file, but the rest of the backup should be okay. However, that may be an illusion. After all, anything that clobbers a disk will probably take out all the files on that disk.