I'd like to pass on some experience with Leopard and Snow Leopard in case it's useful to anyone. I back up two computers to the same archive, my MacBook Pro (Snow Leopard) and my wife's G4 iMac (Leopard). Until recently I had been switching the backup drive between machines, or sometimes leaving it attached to the iMac and backing up the MBP over the network, which worked fine. I've just installed an airport express and connected my backup drive though that, which caused problems.

I found that if I tried to back up the iMac after backing up the MBP, the archive header was corrupted and the archive needed to be reindexed. I reported it to James and he explained that it was caused by an OSX network volume cache bug where Leopard and Snow Leopard use different ways of caching as they move data to the hard drive. It's not a problem when the drive is dismounted and remounted between backups, apparently, but only when both computers alternately access the drive while it is connected to the same network. So dismounting and remounting the drive between backups would eliminate the problem.

That's not a good solution, though, because it would make it difficult to schedule backups for both machines while I'm asleep. But fortunately, the problem only seems to occur in one direction -- when I backup the iMac after backing up the MBP. So far, at least, dismounting and remounting the drive after backing up the MBP, then scheduling the nightly backups with the iMac first and the MBP second, seems to be working.

Ralph

Thanks, Ralph, for posting this issue to the forum.

Just to clarify, the issue I'm intimately aware of is when one Mac OS X system is acting a a file server (file sharing enabled) using a local QRecall archive and another is access that same archive via the network. There are cache synchronization problems—where changes made by one system aren't communicated to the other—if both computers are running an earlier version of 10.5 or one is running 10.5 and the other running 10.6. If both are running 10.6 or the latest version of 10.5, everything seems to work correctly.

The workaround is to periodically unmount the networked volume. This forces the remote computer to flush its disk cache and re-read the remote volume data. If you encounter this problem, eject your network volume and restart the action. If the volume remounts and the actions runs OK, then there was never anything wrong with your archive. (I should note that I have exactly that situation here, and have to restart the nightly capture on my 10.5 laptop about once a week.)

Ralph's situation is a little different in that he's using an Airport Extreme base station as the file server. The Airport runs a version of Apple's File Sharing service, but Apple doesn't document what version. Given that there are compatibilities issues between file sharing on 10.5 and 10.6, and between 10.6 and the latest Airport, I guess it's not surprising that there might be issues when one client is running 10.5 and the other 10.6.

I'm going to set up a similar configuration here and see if I can duplicate this problem.

I haven't invested a lot of time or effort into addressing this problems because (a) I keep hoping that Apple will simply fix the problem and it will go away and (b) it doesn't cause any data loss. It's just incredibly annoying.

I'm continuing to have problems backing up to a network drive connected to an Apple Airport Extreme. I run scheduled partial backups on my wife's iMac at 1am and on my MacBook Pro at 3am, into the same archive. Both have Qrecall 1.1.4.5 installed. Up till 12/22 both seemed to be working fine. On 12/22 the iMac log shows a "Scheduler Version mismatch" and "Autoupdate system components," so that may have been when I updated the iMac to 1.1.4.5. From the log, it looks like I had updated the MBP on 12/19.

On 12/23, the 1am iMac backup failed due to "disk full -- Capture ran out of disk space." The disk had more than 20gb free and the backup would have been less than 100mb. The 3am MBP backup later that night ran fine. Later that day I merged a bunch of layers to free up additional space in the archive, then turned the iMac and AE off and left for a vacation. When I came back on 12/31 I started things up again.

Since that restart, all the backup attempts on both computers have failed. The iMac shows "disk full" as the reason for failure, though there's always been plenty of space on the drive. The MBP shows capture as happening, followed by "Problem closing archive," followed by "Capture failed -- network or disk error encountered."

I unmounted the drive from the AE today and mounted it directly on the MBP. Qrecall was unable to open the archive. I scanned the drive with Disk Utility and it appeared to be OK. I then scanned it with TechTool Pro which reported "Validation Error Encountered -- Allocation File (Bitmap)" I repaired the volume structure and qrecall then opened the file and said the archive needed to be reindexed. Halfway though the reindexing it stopped and said the archive needed to be repaired, so I repaired it.

After the repair I have two distinct entries in the "owners and volumes" list for my MBP hard drive. One contains only recent layers which I haven't merged yet and the other contains all the layers that have been merged at some time with another layer. I also had one damaged layer at the end, with no date and only damaged content. I then did a manual full backup of the MBP. Both that and the scheduled partial backup look fine. I haven't yet reattached the drive to the AE for a backup of the iMac.

I don't know if this is a recall problem or some instability in my system or backup drive, but it does seem related to the 1.1.4.5 update. I'm sending you reports from both machines with the logs.

Ralph

Ralph Strauch wrote:I'm continuing to have problems backing up to a network drive connected to an Apple Airport Extreme. I run scheduled partial backups on my wife's iMac at 1am and on my MacBook Pro at 3am, into the same archive. Both have Qrecall 1.1.4.5 installed. Up till 12/22 both seemed to be working fine. On 12/22 the iMac log shows a "Scheduler Version mismatch" and "Autoupdate system components," so that may have been when I updated the iMac to 1.1.4.5. From the log, it looks like I had updated the MBP on 12/19.

Ralph,

This is indeed the message that you get when QRecall updates itself. The log files you uploaded confirm that this is the date you updated QRecall on that system.

On 12/23, the 1am iMac backup failed due to "disk full -- Capture ran out of disk space." The disk had more than 20gb free and the backup would have been less than 100mb. The 3am MBP backup later that night ran fine. Later that day I merged a bunch of layers to free up additional space in the archive, then turned the iMac and AE off and left for a vacation. When I came back on 12/31 I started things up again.

You've run into another known problem with OS X and the Airport basestation. Basically, some Apple File Servers don't handle file pre-allocation requests correctly. The bug is in older versions of OS X, the Airport basestation, and some NAS storage devices.

Your "disk full" problems can probably be solved by setting the QRFilePreallocateDisable expert setting in the Terminal:

defaults write com.qrecall.client QRFilePreallocateDisable -boolean true

You'll probably want to do this on all of your systems, particularly those encountering the out-of-disk-space problem. This problem was recently mentioned in the Preallocation failed thread.

Most of what you describe after that makes sense. The file allocation bug caused QRecall to abort abnormally, leaving the archive in an invalid state. It may have also caused the volume allocation map to become corrupted—operating systems have notorious difficulty dealing with disk-full conditions. Repairing the volume and then repairing the archive probably cleaned everything up.

After the repair I have two distinct entries in the "owners and volumes" list for my MBP hard drive. One contains only recent layers which I haven't merged yet and the other contains all the layers that have been merged at some time with another layer. I also had one damaged layer at the end, with no date and only damaged content. I then did a manual full backup of the MBP. Both that and the scheduled partial backup look fine. I haven't yet reattached the drive to the AE for a backup of the iMac.

The two volumes in the Owners & Volumes drawer is odd. This usually happens when you resize/reformat a volume. Even though it has the same name, QRecall identifies it as a different disk drive. I'd be interested to know if QRecall continues to add layers to the "new" volume or the old one.

The damaged volume/layers in the repaired archive can be ignored or deleted. In your case they are simply artifacts of the repair process.

James Bucanek wrote:You've run into another known problem with OS X and the Airport basestation. Basically, some Apple File Servers don't handle file pre-allocation requests correctly. The bug is in older versions of OS X, the Airport basestation, and some NAS storage devices.

Your "disk full" problems can probably be solved by setting the QRFilePreallocateDisable expert setting in the Terminal:

defaults write com.qrecall.client QRFilePreallocateDisable -boolean true

You'll probably want to do this on all of your systems, particularly those encountering the out-of-disk-space problem. This problem was recently mentioned in the Preallocation failed thread.

Done! If it doesn't solve the problem, I'll be back. I don't know if it's significant, but I find it interesting that the problem manifested differently on a PPC iMac running Leopard (disk full error) and on an Intel MBP running Snow Leopard ("Problem closing archive . . . Capture failed . . .").

BTW, the "copy to clipboard" link for your code above doesn't work. I get an alert telling me that the code is now on my clipboard, but it isn't. I used the "view plain" link to display the code and then copied it from there.

The two volumes in the Owners & Volumes drawer is odd. This usually happens when you resize/reformat a volume. Even though it has the same name, QRecall identifies it as a different disk drive. I'd be interested to know if QRecall continues to add layers to the "new" volume or the old one.

Having two volumes in the Owners & Volumes drawer isn't new. I've had them for some time, I think since I switched from the beta registration key to a normal key when qrecall was officially released. What changed, though, is that the earlier volume now contains everything up to 12/11/09, which was my last full backup and the the latest layer that was included in a merge, while the later volume contains only partial backups since then and the full backup I did last night. It isn't because I merged lots of older stuff into the 12/11 layer, though. I still have several earlier 2009 layers that I'm sure used to be in the newer volume.

Having the two volumes isn't a problem and I don't need to do anything about it, but just thought it was worth mentioning.

Thanks again for your extremely prompt and useful reply. The support you provide is outstanding.

Ralph