qrecall and filevault

I encrypted my MacBook Pro hard drive yesterday using Filevault 2, assuming that it should work with qrecall since the disk would be mounted when backing up. I then started my daily backup of User files, which usually finds a couple of hundred megabits and takes 10 minutes or so. After 2 hours qrecall had backed up 20gb (out of close to 300gb), with 99% duplicate. I concluded that it must be doing a total read of the drive and that it was probably so slow because the backup drive was connected through my Airport Express, so I stopped the backup intending to resume with the drive directly mounted on the MBP. When I tried to resume the backup it failed with a "network or disk error encountered." I repaired the drive with Disk Utility, which found that "Volume header needs minor repair" and repaired it. The drive now reads good in Disk Utility and and the archive will open in qrecall, but I keep getting the "network or disk error encountered" error when I try to backup. What should I try next? (I'll send you a qrecall report now.)

Are there any other issues I should expect using qrecall with file vault?

Qrecall started a second volume when I upgraded to Lion and a third one for the file vault backup. I think I remember you saying sometime that there was going to be a way to combine volumes like this. Is that possible yet?

Ralph

Ralph,

Sorry to hear you're having problems. I spent some time this morning investigating this problem. I have some information, but no definitive cause for your issue.

Let's start with QRecall and FileVault. The two have a rocky history, and I don't generally recommend QRecall for Filevault users. The original FileVault worked by replacing your home directory with a mount-point to an encrypted disk image. While arguably a very elegant solution, it trips up QRecall (and similar device/volume oriented backup solutions) in many subtle ways.

The new FileVault in Lion is actually much simpler, architecturally. Lion's FileVault encrypts the entire volume at the volume level. When mounted, the entire volume appears as a single, completely ordinary, volume to the operating system. Thus, as long as you're logged in, QRecall should behave normally. Testing this morning on an encrypted Lion volume would seem to confirm that conclusion.

So let's get to your specific problems.

First, it's not surprising that QRecall it taking a long to time recapture your volume. When you turned on FileVault, you essentially reformatted your hard drive; it now appears as "HSF+ (journaled, encrypted)" in Disk Utility. As a never-before-seen volume (from QRecall's perspective) it will be completely recaptured. As you rightly guessed, doing this to an Airport base station isn't the fastest solution, but also the added layer of decryption that has to happen means that everything is going to be little slower.

After you moved your archive to another volume you started getting a "cannot convert FSRef to path" error. Frankly, this just doesn't make much sense. It's an internal inconsistency error that should simply never happen, at least not where it would appear to be happening. By the way, thanks for sending the diagnostic report. That made looking into this much easier.

So I suspect something strange with the archive or the volume it's now on. Here's some thoughts:

- You mentioned that you were going to repair the archive, which I agree might fix something.
- I would suspect the volume, but you already repaired that so let's assume that's not the issue.
- Choose the volume that contains the archive it the Finder, choose Get Info, and check the "Ignore ownership on this volume" option.
- Alternatively, make sure you have the correct read/write permissions for both the archive package folder and all of the files it contains.
- Try opening the archive package (from the Finder, right/control+click on the archive choose "Show Package Contents") and deleting any "negative" index files you find. This is the file that QRecall can't see to locate. It's a nonessential file that's used to speed up certain indexing operations, and will get rebuilt automatically if it's missing.
- Perform a few captures manually, rather than using actions. If that works, try recreating your actions.

I repaired the archive last night, even though the error being reported was a "network or disk error" and the archive seemed to open find in qrecall. My automatic daily backup of Users files followed without a hitch. I'm now running a backup of the full drive and it seems to be proceeding normally, albeit slowly.

I had avoided the original Filevault because it seemed like too much of a kludge, and just kept important files on an encrypted disk image. The current implementation seems much more sensible, though, and nice to have on a laptop. Qrecall seems to be working fine with it now, and hopefully after the first long backup things will go back to being quicker. I'll send you another report after this backup finishes, in case there's anything in it that's useful.

Thanks again for your prompt attention and for the great support you provide. It's part of what makes Qrecall such a pleasure to use.

Ralph