One facet of my multi-tiered backup strategy is to keep a separate, bootable copy of my primary volume. QRecall is set to back up my primary volume to a dedicated backup drive, but I have a secondary dedicated drive that I use as a destination for Carbon Copy Cloner.

My primary driver's volume name is "Primary" and QRecall is configured to run daily backups of this volume to the archive "Macintosh Pro" on a volume called "QBackup".

My CCC destination is a separate volume called "CCC Backup".

So here's the problem: if I boot from CCC Backup, the instance of QRecall on that volume immediately starts backing up that volume to "Macintosh Pro" on "QBackup". If I look in the Actions window, the backup action is labelled "Capture volume CCC Backup" instead of "Capture volume primary".

This of course leads to problems with the backup archive since it starts layering information from a different volume...

It seems as though QRecall is saving the actions as something like "Capture [boot volume]" rather than "Capture [volume name]". I guess I can understand why: you wouldn't want renaming the volume to break backup scripts.

But is there some way I can stop QRecall from trying to run an immediate backup of CCC Backup every time I boot from it? Which isn't often, but still...

David,

Interesting problem.

QRecall uses "bookmarks" (the modern macOS replacement for aliases), and you are correct; if you create a bookmark of your startup volume, or an item on that startup volume, and later resolve that bookmark when booted from a different startup volume, it will find that item (first) relative to your new startup volume, not the original volume (even if it's online).

I believe you can exclude items from your CCC Backup. So the simplest solution would be to exclude the contents of the ~/Library/Preferences/QRecall/Actions folder. Then when you boot from your external drive, QRecall won't have any actions to run. (And don't forget to delete any old actions on your CCC Backup volume.)

That would work. It has the minor drawback of needing to recreate the actions if I ever restore from the backup volume, but that's not too hard...

David Ramsey wrote:It has the minor drawback of needing to recreate the actions if I ever restore from the backup volume, ...

But those action documents would still be captured in your QRecall archive, so you could just restore them from that backup.

D'oh!

Although...you know what would be cool? Some way to set up a macro or quick action or something along the lines of:

"Immediately restore [file(s)/folder] from most recent backup"

Something I could easily invoke to restore data without having to manually dig through a complex directory hierarchy...

Yes, I am indeed that lazy.

Lazy is good. Getting computers to do our work for us is how we got this far

You can use the qrecall command tool, which can be added to a Terminal/shell script, executed from an AppleScript, or about a thousand other ways.

qrecall restore <path_to_archive> '*:*/Users/<you>/Library/Preferences/QRecall/Actions'

Note: the shorthand syntax '*:*' (or just ':') works when you have only one owner with one volume in the archive. If you have more than one, of either, you'll need to see man qrecall section on <item> syntax for details about specifying the owner and volume you want to restore from.

I think I'm missing something:

[Caprica:~] dramsey% qrecall restore '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

Results in:

* restore process failed: folder not found in selected layers

The Actions folder and its contents are there; I can restore them manually. I've tried adding ".quanta" to the end of "Mac Pro Backup", and I've tried escaping the spaces with \ (removing the single quotes), but obviously I'm overlooking something...

David Ramsey wrote:* restore process failed: folder not found in selected layers

Hmm, it works here for me...

Basically, the command is saying that /Users/dramsey/Library/Preferences/QRecall/Actions doesn't exist in the latest layer. Are you also sure you only have a single volume and owner? Is /Users/dramsey on a different filesystem?

What happens if you try this:
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

You can try shorter versions of this (i.e. qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users') to try and narrow down where the missing piece is.

James Bucanek wrote:
What happens if you try this:
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

This happens:

* ls process failed: folder not found in selected layers

James Bucanek wrote:
You can try shorter versions of this (i.e. qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users') to try and narrow down where the missing piece is.

It's a mystery to me. The folder's there in the layer. Here's a screen shot:

It isn't obvious what's wrong, so go through each level one at a time to see where the break is:

qrecall ls '/Volumes/QBackup/Mac Pro Backup'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall'

The first two should only list one owner and one volume, respectively; if they don't, that's probably the issue.

James Bucanek wrote:It isn't obvious what's wrong, so go through each level one at a time to see where the break is:

qrecall ls '/Volumes/QBackup/Mac Pro Backup'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*' <-- Fails here.

I admit I'm confused about the syntax. For example, I'd expect the second line, when executed, to list the upper level directory of the volume "Primary", since that's what's backed up in the "Mac Pro Backup" archive.

Instead I get:

[Caprica:~] dramsey% qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*'
Frankenstein
2 items
Type Access Owner Group Size Modified Captured Name
volume 1023999787008 Feb 9 13:54 CCC Backup
volume rwxr-xr-x root (0) wheel (0) 999995129856 Feb 9 13:34 Feb 12 18:04 Primary

CCC Backup is the volume dedicated to CCC. Primary is the volume I'm backing up with QRecall.

I'm surprised to see "Frankenstein"; that was the name of my Hackintosh. This backup is running on a Mac Pro 6,1 called "Computronium". But when I look at the backup in the QRecall app I can see the hierarchy is "Mac Pro Backup->Frankenstein->Computronium..."

David Ramsey wrote:I'm surprised to see "Frankenstein"; that was the name of my Hackintosh. This backup is running on a Mac Pro 6,1 called "Computronium".

"Frankenstein" is the name of your identity key. When you first install QRecall, your identity key's name defaults to the name of your system. It will remain that until you change it.

To change your identity key, go to QRecall > Preferences > Identity Key and edit the name.

The full syntax for specifying an item in an archive is <owner's name>:<volume name>/dir/.../dir/item, essentially the path you see at the bottom of the archive browser window.

The convenient * syntax means "the one and only owner" or the "one and only volume". But you have more than one volume, so the * syntax can't be used.

There are two easy ways to solve this.

First, you can simply delete the "CCC Backup" volume. You were trying to solve the problem stopping captures of your "CCC Backup" volume, so this seems like the preferable choice. Once you're back down to a single volume, the * volume name will work again. In the browser, navigate to the owner level ("Frankenstein"), select the "CCC Backup" volume, and choose Archive > Delete Items….

Alternatively, you can specify the volume in the item path so there's no ambiguity: qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*rimary/Users/dramsey/Library/Preferences/QRecall/Actions'

Bingo, that was it! The erroneous inclusion of the CCC Backup volume was what was killing the command line restore thing. I deleted it from the archive and now have a shell script set up to do it. Thanks for your patience!