MAlexander

It's not fixed in 10.2.

This bug is minor, but very annoying. It's been annoying me since at least Retrospect 8, has it been fixed in Retrospect 10? I guess we won't know until next spring, unless someone down under can test it for us.

Has anyone figured out how to get the temporary promotion for people with expired ASM agreements that Robin Mayoff mentioned in response 2 in this item? I've EMailed and called and haven't gotten anyone to even respond, let alone tell me how to get the promotion. Can anyone verify that the promotion exists? My trial expires soon and I need the upgrade. On a positive note, version 9 does seem to be working better than version 8. There are still some cosmetic bugs, but the serious bugs seem to be mostly gone, at least the ones that I've hit in the past.

Another data point: I recently groomed (to "defined policy") a media set that contains about 9.7 million files after grooming and it took just 16 minutes short of 4 days. This, along with the other data points, seems to imply that grooming time is more or less linear with the number of files in the media set. This media set hadn't been groomed in quite a while. I don't know if it would have been faster if it had been groomed more recently.

This is actually a bit better than my test on Retrospect 8 (I haven't tried it with 9 yet). The "lots of metadata" test failed for me when I ran Backup Bouncer a while back. I looked into these failures at the time and decided that none of them really mattered all that much. Backup Bouncer is a tough test and Retrospect does about as well as most other backup software, and better than some. What version of Backup Bouncer did you use? There are several out there. The most comprehensive one seems to be the one on Mike Bombich's Carbon Copy Cloner web site at http://www.bombich.com/groups/ccc/wiki/7ba51/Improvements_to_Backup_Bouncer.html, but I don't think it will work on Lion yet. You might need to merge it with the version on GitHub.

One minor bug that hasn't been fixed in version 9 is that the "Date:" header on EMail messages generated by Retrospect is wrong, at least if daylight savings time is on. I'm in the US Eastern time zone which means that (for a few more hours) my time is UTC -4. A message Retrospect sent around 10:46 this evening has a date header reading Date: Fri, 05 Nov 11 22:46:41 -0500 Since my EMail client is set to adjust displayed times to my time zone this shows up as 11:46:41 PM, which was still in the future when I started entering this. This is obviously not a serious bug, but it is annoying and might be easy to fix. How do I report it so it gets added to the bug tracker? I'm running version 9.0.0.319, but this bug has been there since version 8.

Where can I find out more about this promotion? I searched the forum and retrospect.com and didn't see anything about it except this brief mention.

I'm getting the same assert failures and shutting down time machine didn't seem to help. What did seem to help is turning off my VXA 320 tape drive. It's a standalone (not tape library) firewire attached tape drive. When it is turned on, the engine gets this (or a similar) assert failure every few hours. With it off it ran for two weeks without a failure until I turned it back on. Then it failed within a few hours.

I get a lot of these assert failures too. So far the support folks haven't made much progress figuring out the cause. If you look in "/Library/Application Support/Retrospect/RtrExec.dir" on the engine machine after the crash and before restarting the engine you'll find log files for activities that were running at the time of the crash. These files will be deleted when the engine restarts so look before that. They really should be appended to the main log file on a restart instead of just being trashed, but that's a separate bug.

Note that the crash log says "Code Type: PPC (Translated)" which applies to the code in the process that crashed, not the machine it is running on. Since that process is running Retrospect 6.1, it's not surprising that it's PPC code. I agree that it's not clear why 6.1 is running. It also appears that the crash report is from about 4 hours before the kernel panic. Perhaps the two are unrelated.

I've seen this error regularly ever since I started using 8.1 but not so often that I can't just ignore it. I don't have any RAID volumes so it can't be that. I first saw it on a local volume attached to the machine running the engine (which at the time was a 10.5.8 Mac Pro). I've seen it again since moving to a Mac Mini running 10.6.4 and Retrospect 8.2. I don't know what volume it is working on when the error occurs now, the log is difficult to interpret. It bothers me to have errors I have to ignore like this. I wish I knew what the problem is.

I had this happen with a disk media set in 8.1. See Forum Topic 33111. I never did get it unlocked and eventually gave up and trashed the media set and created a new one without a password.

You can also sometimes get the firewall prompt and solve this sort of problem by Command-clicking on the "Off" button on the client interface and clicking on the "On" button. This will stop and restart the client process and at least sometimes this causes the OS to prompt to open the firewall for it. It's a lot quicker than reinstalling the client so it's worth a try.

Have you tried just cloning the disks using something like Carbon Copy Cloner? You might have to help Retrospect locate the media sets on the cloned disks, but I think this can be made to work.

That's not clear. A test restore from that media set showed missing files, but it's not clear that it's related to the verify anomaly. For one thing there were more missing files than showed up in the verify "remaining files" count. No one seems to know what's going on with either the missing files in verify or the missing files on restore, or whether they are related in any way.