Steven,

Unless you reformat your boot volume, or transfer your boot drive to a new drive, it won't make any difference at all. QRecall primarily identifies volume by their UUID, and unless you migrate to a new partition/drive, your UUID won't change and your volume's name is largely immaterial.

If, in the future, you do reformat or migrate your boot volume so it has a different UUID, QRecall will then try to match the volume in the archive with your boot volume using a combination of the volume's name, the date it was formatted, and its size. So if you replace your startup drive (now named El Capitan), and later want to dig back into your archive (when it was still named Yosemite) and try to restore an item, QRecall might not be sure where to restore it to. In this case, you'll have to recall the item and manually locate the original item to replace.

That's the worst case scenario.

Marc Bizer wrote:Are you familiar with the backup utility Arq? It doesn't do data deduplication, but I'm pretty sure that it just keeps an archive of files on Google Drive, Amazon S3, etc. with some sort of index on one's local hard drive. I don't know whether it's possible to send just quanta via these cloud APIs -- have you checked Google's for example?

We continue to explore these technologies. The problem is they either fall largely into one of two kinds of solutions: file storage or databases. The file storage solutions don't scale well, and the database solutions suffer from unacceptable latency or huge index key sets. But we continue to look at them...

Another question: if I stored the QRecall archive on an NAS or Time Capsule, would QR automatically mount and unmount the storage volume?

Yes. If the archive for a scheduled action is not mounted, the scheduler will attempt to mount it before running the action (and will attempt to unmount it again when the action finishes).

I see QR as a great replacement for Time Machine -- except that you can't use it to restore an entire hard disk, right?

Absolutely, you can. See the help section QRecall Help > Guide > The Basics > Restore Items and Restoring a Volume to a Different Volume. For more sophisticated restore solutions, see QRecall Help > Guide > Troubleshooting > Restoring OS X.

Marc Bizer wrote:Sorry to persist, but if the user isn't supposed to know what is underneath, why have the UI rely on a terminology that is keyed to what is happening underneath rather than to what the user is experiencing?

So you don't mis-apply preconceived notions about what's happening.

Besides, the UI doesn't hide what's happening. If you use the upper and lower shades to isolate a single layer, you don't see a "snapshot" of your files that day. You see a positive delta of what changed, which is the essence of layers.

Marc Bizer wrote:What about macupdate.com? They still list version 1.2.3 as the most current.

That's odd, because until recently MacUpdate.com was subscribed to our version RSS feed. They'd often have our latest version and release notes within minutes.

I'll make a note to update their listing. Thanks for the heads-up.

Marc Bizer wrote:I appreciate your precision, but in terms of interacting with the software (UX), does it really matter what is happening underneath?

We certainly like to think so!

Marc Bizer wrote:So what about plans to allow backup to online servers, such as Google Drive, Box, and Amazon S3?

Investigation is ongoing, but we don't have a solution yet.

The problem with most of these networked file synchronization solutions is that they are file oriented. In other words, you make a change to a local file and that file will be uploaded?in its entirety?to the server. Later, it will be downloaded?in its entirety?back to your other devices.

The bulk of a QRecall archive is a single database file that contains all of your captured data. So if you added a 150K image file to a 100GB archive, a file synchronization service would dutifully re-upload your entire 100GB archive file. This is not only horrifically inefficient, but ludicrously wasteful, and you still need enough local disk space to keep the copy of the on-line archive.

We are actively exploring three different solutions. The first is a simple "cascade" feature what will allow you to incrementally synchronize an off-site archive with a local one. Another is a client/server version of QRecall allowing you to efficiently capture to a QRecall service over the network. And finally, we're exploring leveraging massive database services like Amazon DynamoDB and Redshift, but we've yet to prototype a workable system so we don't know what the performance is yet.

Marc Bizer wrote:I'm curious as to why the developer has adopted these terms. The standard equivalent for "layer" and "capture" is "snapshot," for example. If one wishes to use "capture" as a verb, then why not just use "backup"?

Excellent question!

It was a conscious decision to use different terms because, in the very early stages of development, it became clear that the standard terms ("backup," "copy," "clone," "snapshot," and so on) were inaccurate and carried too many preconceived notions.

We never use the term "copy" because QRecall does not copy files. We don't use the term "snapshot" because QRecall never makes a snapshot of your existing files.

QRecall maintains a database of discrete, individual, unique, blocks of data we refer to as "quanta". A file is a collection of quanta. When you capture a file, it's disassembled into its quanta and added to the database in a manor that never stores the same quanta more than once.

During the capture, a layer is created. A layer is not a "snapshot," it a set of positive deltas that describe what has changed. In other words, QRecall never stores any information about what is, but only what's changed.

I like to think that QRecall is to backups what holography is to photography.

QRecall works more like a modern version control system. And you notice that git never talks about "copying files" or "taking snapshots." git commits new nodes to a repository. The nodes represent deltas, and a repository is a network of nodes that can be used to reconstruct a set of files at a given point in time.

Now we don't object to the idea of "making backups" or talking about "snapshots" of your files, because at the end of the day QRecall is essentially copying files. And all of those positive deltas can be combined to calculate a "snapshot" of your files at a point in time (which is exactly what is happening when you see the "compositing" message in the QRecall item browser).

So if you want, feel free to think of QRecall as copying files, making backups, and taking snapshots. Just remember that that is not what is happening under the hood.

Bruce,

Excellent suggestion. I'll make sure they get a copy of the press release tomorrow.

The future feature I'm thinking of is the ability to execute a script, either before or after, an action runs. The script that runs before will have the ability to cancel the action.

It would then be possible to write a script that determines if the the database daemon is running and cancel the capture. You would then create a capture action for each MS Office application, and the script would prevent all but the last application to quit from running the action.

You could almost do that now with schedule conditions, but currently you can only attach one "ignore if application X is running" condition. I'd like to expand that too, so you can attach multiple application conditions. Using that technique, you could create an action the captures when you quit Word, but then ignore the action if any of the other MS Office apps were running. Again, the idea to let only the last application that quits trigger the capture.

Kenneth,

Yikes, that's a tough one.

You've obviously tried to create a capture action that runs when the Microsoft Database Daemon quits, and since that doesn't work it makes me think that the daemon app either isn't a standard Cocoa application or Microsoft is launching it using their own mechanism (which is not unlikely, Microsoft tends to do things "their way"). Regardless, the Microsoft Database Daemon seems to be flying under the workspace radar.

Unfortunately, this probably means my next suggestion won't work either. That suggestion is to create a set of actions that run when each application quits, and to each one add a one minute delay and a condition that skips the action if the Microsoft Database Daemon is still running. But if the workspace doesn't see the daemon app launch and quit, then it probably can't tell if it's running either.

Going a little deeper, it might be possible to script something that can test (via ps or some other tool) if the database daemon is running and then script the capture to start using the new qrecall tool, but I don't have any good suggestions on what might run that script in a timely fashion.

I have some enhancements on the horizon (probably in 2.1) that would solve this, but those are still on the drawing board...

Cody,

You are not alone. On a few systems, QRecall can't delete the old (1.2) QRecallService.service plugin in your ~/Library/Services folder.

If that's that case, it's an easy fix:

Quit QRecall

Open your ~/Library/Services folder (in the finder hold down the Option key and choose Go > Library)

Trash the QRecallService.service plugin

Launch QRecall again

That should allow QRecall to install the latest plugin, and the Capture Preferences service should then become available.

If you continue to have issues, send a diagnostic report.

Thanks!

2.0 took about 6 months longer than originally planned, but that seems to be the way software goes.

Yes, there are lots of new features and ideas in the works—enough to keep me busy for the next several years.

But the most enjoyable part of working on QRecall has been my customers. They're a smart, well informed, bunch who share a passion (some might say an obsession) with data integrity and security. It's been a pleasure, and I look forward to getting to know more of you.

Adrian Chapman wrote:Please can you clarify the value, or otherwise of using QRecall's redundancy feature if the archive is stored in a RAID 5 array or a ZFS Mirror.

There are no advantages. If you are using a filesystem or device that performs error correction, your archive's data redundancy should be set to "none".

QRecall's data redundancy in inferior to both hardware (RAID5) and filesystem-level (ZFS) error correction. It cannot protect against whole-device failures (like RAID5) and it cannot evenly distribute correction codes across the media (as ZFS can). (QRecall "encourages" the filesystem to distribute the correction blocks, but since applications have no control over how a filesystem organizes blocks, this can't be guaranteed.)

QRecall's error correction is intended for use on simple hard drives that lack any kind of error detection or correction.

QRecall 2.0.0(38) (A.K.A. release candidate 2) just went live.

Capture (or any other scheduled action) should be just fine. The probably is in the display code that shows items loading in the background when you open the archive window.