wdroome Posted August 8, 2013 Report Share Posted August 8, 2013 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 0.0.0.0:22024 proto=608/08/2013 10:35:27 AM Retrospect[319] [ENGINE] connected to '127.0.0.1' (127.0.0.1:22024, 10.2.0.201)08/08/2013 10:35:28 AM com.retrospect.retroengine[382] Assertion failure at "db.cpp-170", on threadID 0x107C1000008/08/2013 10:35:28 AM Retrospect[319] Server::updateBackupSetsCache exception: MacRequestor::Request: connection closed by remote endpoint08/08/2013 10:35:28 AM com.apple.launchd[1] (com.retrospect.retroengine[382]) Exited with exit code: 25508/08/2013 10:35:28 AM Retrospect[319] Server::updateSetsChangeCounter exception: MacRequestor::Request: connection already closed08/08/2013 10:35:28 AM Retrospect[319] Server::updateScriptsCache exception: MacRequestor::Request: connection already closed08/08/2013 10:35:28 AM Retrospect[319] Server::updateScriptsChangeCounter exception: MacRequestor::Request: connection already closed08/08/2013 10:35:33 AM Retrospect[319] connectViaQueue: exception "MacTCPconnection::Connect: connect() failed with error 61: Connection refused" connecting to 127.0.0.1:22024 I found the following assert error in the retro log files: Thread ID: 0x0000000004384000, Name: Server threadrax:0x0000000000000001 r8:0x000000005203aa77 r12:0x0000000104380bf0 rip:0x00007fff8484e466 cs:0x0000000000000007 rflags:0x0000000000000202rbx:0x0000003000000000 r9:0x000000010437fad0 r13:0x0000000100823083 rsp:0x000000010437fae8 rbp:0x000000010437fb20rcs:0x000000010437fae8 r10:0x0000000000000347 r14:0x00000001007ca5a0 rsi:0x000000010437fb0f fs:0x0000000000000000rdx:0x0000000000000000 r11:0xffffff80002e4730 r15:0x0000003000000000 rdi:0x000000000000000c gs:0x000000000000000fModule 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 3 Quote Link to comment Share on other sites More sharing options...
BDMSTUDIOS Posted August 8, 2013 Report Share Posted August 8, 2013 Hi Wendy, Delete the current 127.0.0.1 server, reboot and add it back again! Worked for me using Retrospect on Mac Pro 3.1 OS X 10.8.4 (12E55) & Apps on iPhone4 and iPad3 [iOS6.1.3] Good Luck and Cheers! Quote Link to comment Share on other sites More sharing options...
wdroome Posted August 8, 2013 Author Report Share Posted August 8, 2013 How do I delete the server? Just remove /Library/Application\ Support/Retrospect/RetrospectEngine.bundle Or is something else required? Quote Link to comment Share on other sites More sharing options...
Mayoff Posted August 8, 2013 Report Share Posted August 8, 2013 This error typically happens if Retrospect is trying to load a catalog file for a backup set that failed during a recent grooming operation. Some users have been able to start the Retrospect engine, and then click Pause for all executions. You can then perform a catalog rebuild for the backup set that is corrupt. You can also remove the problem catalog file from your catalogs folder and then start the Retrospect engine. If the engine stays running, then it means you need to rebuild that catalog file. This will be fixed in the next release. Quote Link to comment Share on other sites More sharing options...
BDMSTUDIOS Posted August 8, 2013 Report Share Posted August 8, 2013 Hi Wendy, Here are some screens for your purpose. Cheers! Addendum: Quote Link to comment Share on other sites More sharing options...
wdroome Posted August 9, 2013 Author Report Share Posted August 9, 2013 @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 Quote Link to comment Share on other sites More sharing options...
BDMSTUDIOS Posted August 10, 2013 Report Share Posted August 10, 2013 Hi Wendy, Sorry I could not be of any help! Hope the RS 10.2 GURU's can help you out with your problem! Cheers and have a great TweakEnd!!! Berend Quote Link to comment Share on other sites More sharing options...
DMS Posted August 13, 2013 Report Share Posted August 13, 2013 Dead here as well. My engine and data are local on a Mac Mini Sever. 10.1.2 worked flawlessly. Sorry I upgraded. PZ Disher Music Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted August 18, 2013 Report Share Posted August 18, 2013 I use "backup to external disk" You put that in quotes, but there is no such setting in Retrospect. Are you saying that you are using Disk Media Sets? and I keep the catalog on the external disk as well as the backup files. You shouldn't do that. Why? Because a catalog is upwards of 15 gigs, and that's a significant bite out of my laptop's hard drive. If you don't have adequate space for the Retrospect Catalog file on your boot drive you should store it on another volume, just not on a Member volume of the same Media Set. I also use time machine, and I don't want TM re-writing those catalogs every day or so. Then simply Exclude the folder that contains the Catalog file from TimeMachine. I know that isn't the "recommended" way to set Retrospect up, but it's worked for many years. More then just not recommended (there are those quotes again!), it's against the design of the program. Retrospect has _always_ been designed to maintain the Catalog file separately from the copied data, with the exception of File Storage/Backup/Media Sets which were deigned specifically to provide the functionality you're looking for (within the constraints present for the various versions of the program). It's like running your classic engine on unleaded gas; sure it'll work, until it doesn't anymore... In any case, apparently all knowledge of "the backup sets" and "catalog locations" is hidden somewhere in the server's data files. Since the manager of Retrospect tech support suggests loading of corrupted catalogs is a possible cause, are you certain there are no Catalog files on your boot drive that Retrospect might be trying to load? You've searched exhaustively for ".rbc" files? Quote Link to comment Share on other sites More sharing options...
wdroome Posted August 19, 2013 Author Report Share Posted August 19, 2013 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. Quote Link to comment Share on other sites More sharing options...
bdunagan Posted August 28, 2013 Report Share Posted August 28, 2013 Sorry for such a late reply. Thanks for the log information in the initial post. We've had other reports of this error ("Assertion failure at db.cpp-170"). It would be fantastic if you could contact our support team (www.retrospect.com/support) and send us your assert log, found at /Library/Application Support/Retrospect/assert_log.utx, referencing this forum thread. Also, there's nothing wrong with your setup. 15GB catalog files are large even for today's boot drives. Quote Link to comment Share on other sites More sharing options...
prl Posted August 29, 2013 Report Share Posted August 29, 2013 I was a bit puzzled about CallMeDave's comment about not storing the catalog files on the same volume as the media sets. If the disk does/volume is hopelessly corrupted, or if the media sets are accidentally deleted or corrupted, having the catalog files elsewhere doesn't really help. If the catalog files are corrupted/accidentally deleted, then they can be reconstructed from the media sets. What shouldn't be done IMO is having the Catalog (only) stored on a volume that is backed up my the media sets that that Catalog represents. Having backup copies of the catalog is also a good idea. Especially, I don't think it's a good idea to (only) store the Catalog for the backup of a Retrospect server's boot volume on the server's boot volume (as is the default). Quote Link to comment Share on other sites More sharing options...
twickland Posted August 29, 2013 Report Share Posted August 29, 2013 I was a bit puzzled about CallMeDave's comment about not storing the catalog files on the same volume as the media sets. If the disk does/volume is hopelessly corrupted, or if the media sets are accidentally deleted or corrupted, having the catalog files elsewhere doesn't really help. If the catalog files are corrupted/accidentally deleted, then they can be reconstructed from the media sets. When both the catalog and the data reside on the same volume, you have the problem with the volume filling up with data files at the same time the catalog is growing larger. When the volume gets full, you can't add another member (because there is no space for the catalog to grow further), and you can't perform a groom (because you need free space for the grooming operations to the data files and to the catalog). While you could limit the amount of space that Retrospect is allowed to use for the media set member's data, it's preferable to partition the drive into two volumes if you want to store the catalog and the data on the same hard drive. What shouldn't be done IMO is having the Catalog (only) stored on a volume that is backed up my the media sets that that Catalog represents. Actually, this is not an issue. Retrospect automatically excludes a catalog from the backup if it's "busy;" it will only back up catalogs from those media sets that are not currently in use. Quote Link to comment Share on other sites More sharing options...
CallMeDave Posted August 29, 2013 Report Share Posted August 29, 2013 When both the catalog and the data reside on the same volume, you have the problem with the volume filling up with data files at the same time the catalog is growing larger. When the volume gets full, you can't add another member (because there is no space for the catalog to grow further), and you can't perform a groom (because you need free space for the grooming operations to the data files and to the catalog). Actually you could use the feature of limiting the percentage of the volume used for the Media Set (if that feature were reliable), to avoid the Catalog file being the cause of the volume filling. One problem is that with the Catalog on a Member you can't add another Member without having _both_ members online. The original poster described her system being a "laptop" (MacBook?) with a (single?) external drive. Maintaining the Catalog this way would preclude the ability to span the Media Set onto any additional physical media unless she was willing to physically connect two external drives each time the backup ran. There are other problems, too. Dave Quote Link to comment Share on other sites More sharing options...
wdroome Posted October 13, 2013 Author Report Share Posted October 13, 2013 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.