Apparently there is a QRecall manual. If so, where can I get it? If it's on the site it's not obvious...

So far I'm impressed with QRecall running on Lion. I use a Windows 7 virtual machine almost daily, and had told Time Machine not to back it up since it's 20G in size and your backup disk fills up rather quickly at 20G/hour, even with some compression. Of course I had to restore my boot drive and the VM wasn't on the backup and I had to recreate and configure it from scratch, which is a pain.

Based on what I've seen so far with my QRecall trial, the advantages Time Machine has are:

1. Somewhat simpler U.I. (Of course it does less, too, but the QRecall interface can still be a little daunting, especially when you open a folder with a lot of files and see all those "timeline lines". It's kind complex visually.)

2. Its deep integration with OS X means you can do things like recover individual Mail messages. And you have the option of restoring directly from a Time Machine backup when you install OS X.

3. Time Machine consolidates backups (i.e. hourly backups for the last 24 hours, daily backups for the last week...) and automatically deletes older backups as space is needed.

I can work around #1; it's just a matter of learning the interface. I realize that a third party developer simply can't duplicate #2, and that's OK, too.

For #3, the backup consolidation doesn't seem necessary with QRecall since the incremental "quantized" backup means the individual backups are typically much smaller. But what happens when the backup disk fills up? Do I delete older backups manually somehow?

David Ramsey wrote:Apparently there is a QRecall manual. If so, where can I get it?

In the QRecall application, choose Help > QRecall Help. The QRecall help was recently rewritten in its entirety, so feedback is welcome.

So far I'm impressed with QRecall running on Lion.

We're very glad to hear that.

Based on what I've seen so far with my QRecall trial, the advantages Time Machine has are:

1. Somewhat simpler U.I. (Of course it does less, too, but the QRecall interface can still be a little daunting, especially when you open a folder with a lot of files and see all those "timeline lines". It's kind complex visually.)

I'm compelled to note that you can turn timelines on and off as desired (View > Show/Hide Timelines).

2. Its deep integration with OS X means you can do things like recover individual Mail messages. And you have the option of restoring directly from a Time Machine backup when you install OS X.

Absolutely. Apple can do things with Time Machine that third party developers can't touch. Apple has even changed how the HFS filesystem work, just to make Time Machine's job easier.

Apple's overriding goal with Time Machine, however, is simplicity. Which is great. We think everyone should be making backups, and anything that makes that easier is welcome. QRecall's goals are data integrity and efficiency, and we think there's room in the universe for both approaches.

3. Time Machine consolidates backups (i.e. hourly backups for the last 24 hours, daily backups for the last week...) and automatically deletes older backups as space is needed.

...

For #3, the backup consolidation doesn't seem necessary with QRecall since the incremental "quantized" backup means the individual backups are typically much smaller. But what happens when the backup disk fills up? Do I delete older backups manually somehow?

QRecall can/will do exactly the same thing (it's called "rolling" your incremental backups). The different between QRecall and Time Machine is that in QRecall you can specify exactly the scope, frequency, and granularity of the roll. And like Time Machine, you can also make these actions conditional on the amount of free disk space available (or not). Again, you get to decide the strategy that makes sense for you.

I'd suggest using the Capture Assistant (Help > Capture Assistant) to create a backup strategy. The assistant will create actions that "roll" your incremental backups on a regular schedule. You can then open those actions and see how they are set up and adjust them as you see fit.

To read about automating QRecall in general, see the Guide > Automation > Action section in the QRecall Help. To learn more about rolling your incremental backups, see the Guide > Automation > Actions > Rolling Merge section.

James Bucanek wrote:In the QRecall application, choose Help > QRecall Help. The QRecall help was recently rewritten in its entirety, so feedback is welcome.

I finally noticed that!

James Bucanek wrote:I'm compelled to note that you can turn timelines on and off as desired (View > Show/Hide Timelines).

Oh, I knew that; it just seemed as though leaving them off by default might be better. But it's easy to turn 'em off.

James Bucanek wrote:QRecall's goals are data integrity and efficiency, and we think there's room in the universe for both approaches.

I used Retrospect for close to 20 years before the Mac version ran off the rails. It's nice to have something sophisticated again...

James Bucanek wrote:QRecall can/will do exactly the same thing (it's called "rolling" your incremental backups). The different between QRecall and Time Machine is that in QRecall you can specify exactly the scope, frequency, and granularity of the roll. And like Time Machine, you can also make these actions conditional on the amount of free disk space available (or not). Again, you get to decide the strategy that makes sense for you.

I think I've got it: created one action to handle to backups and another to handle the rolling merges. I think I'm gonna like this!

David Ramsey wrote:I think I've got it: created one action to handle to backups and another to handle the rolling merges.

Correct.

It's also recommended that you schedule compact and verify actions to run periodically (approximately once a week). The compact action performs housekeeping, consolidation of unused space, and optimization. A verify action confirms the data integrity of the entire archive and will alert you of any data corruption that might have occurred.

OK, next question. Whilst browsing my archive, I noticed I only seem to have two layers: they're dated May 12 and May 19. But QRecall backs up every day (I can see the backups in the log), with weekly verifications and compactions.

I can recall items from either of these layers, but can't find a way to expose later layers. Pulling the shade control lets me exclude the latest layer, but that's it.

Obviously I am missing something terribly obvious. "Reveal all Layers" is disabled in the Layers menu, so that's not it. So...where are the other layers?

David Ramsey wrote:I can recall items from either of these layers, but can't find a way to expose later layers. Pulling the shade control lets me exclude the latest layer, but that's it.

Obviously I am missing something terribly obvious.

It's not obvious at all, David, or I'm sure you would have found it.

Excellent question. The answer is that QRecall is "helping" you by automatically hiding layers unrelated to the items you're currently browsing.

There are two ways to see the other layers:

Go browse a different folder, or better yet, a volume.

Go to the View menu and check Show All Layers. You should now see all of the layers in your archive, and you'll notice that all but two are grey.

When you browse a particular folder, QRecall finds all of the layers that contain copies of items in that folder. The folder that you happen to be browsing contains items that were captured in two layers. None of those items have been recaptured in any other layers. The remaining layers are dimmed, to indicate that they don't contain anything related to the items in that folder; or if you happen to have the Show All Layers unchecked, they are hidden altogether.

The idea is that when you browse a particular folder, the layers list and the graphic view on the left are trimmed down to just those layers that are relevant to the items you're looking at.

In that case, I think I am Doing Something Wrong. For example, the Documents folder contains my Parallels virtual machines. I see QRecall thrashing through my Win 7 VM almost every day (because I use it frequently), but no backup of it is shown past May 19.

A better example might be my Desktop folder. It changes daily, and yet it doesn't show any changes past that date either (and yes, I am running a Hackintosh. Now that I'm retired I can't justify new Mac Pros any more. I don't think this should make a difference, though...)

David,

Here are some thoughts:

Did you change your identity key or replace/reformatted a drive around May 19?

Go to the very top level of your archive and make sure you only have one owner and one volume. An "owner" is defined by an identity key. Everything you capture belongs to that owner. If you change your identity key, a new owner will appear at the top level of your archive and all items captured after that will belong to the new owner. The same thing can happen to volumes if you replace/repartition a hard drive. If that's the case, you can "fix" this situation with the Combine Items... command. It stitches together the history of two owners or two volumes which actually represent the same item.

Also double check your capture actions to make sure they are capturing the right things. Actions keep track of the items they capture using OS X aliases, which are very smart but can occasionally be fooled into referencing the wrong item. If that's the case, simply remove the incorrect items and re-add the items you want to capture.

If you still think that items aren't getting captured, or are getting captured but not showing up, post again and we can dig a little deeper.

And...that was it. I suspect the new archive was created when I added the identity key.



I suppose I can simply delete the lower archive dated 5/14...

David Ramsey wrote:I suppose I can simply delete the lower archive dated 5/14...

Select both owners and choose Combine Items....

Done. Man, I'd like to know the database architecture you have underlying this. Something tells me it's not an SQL-type relational with BLOBs...

David Ramsey wrote:Something tells me it's not an SQL-type relational with BLOBs...

No, it's not.

Conceptually, it could be. QRecall's archive is organized very much like a database. The structure, however, is a custom one, designed for speed and efficiency in performing the billions of lookups need to recapture files. It's also designed to detect and survive random data loss caused by inadvertent writes, data corruption, or media failure. The latter requirement is why QRecall isn't based on an existing database engine.

James,

1. Does one need to "Schedule" the action for Rolling Merges or is specifying the periods of merging layers sufficient?

2. You mentioned weekly COMPACT and VERIFY actions. Should one VERIFY before COMPACTing or does COMPACT also verify?

Thanks,

Jon

Jon Lindemann wrote:1. Does one need to "Schedule" the action for Rolling Merges or is specifying the periods of merging layers sufficient?

No action does anything until it's run, either manually or by scheduling it to run periodically. The time periods in the rolling merge action simply determine the granularity of the merge when it is run.

So the answer is "yes." You need to schedule your rolling merge action to run periodically. I suggest once a day, if you make a lot of small captures during the day, or once a week otherwise.

2. You mentioned weekly COMPACT and VERIFY actions. Should one VERIFY before COMPACTing or does COMPACT also verify?

It doesn't really matter which runs first.

All actions verify the data they use, but only the data necessary to perform their work.

Only the verify action checks the integrity of the entire archive. And that's why it's a good idea to run a verify action from time to time, just to make sure nothing has been corrupted. How often you verify your archive is up to you.

Thanks James.