Messages posted by: David Ramsey

I've been using QRecall for years, and my only complaint is the performance: on a boot volume with about 1.2TB of data, even incremental backups can take quite a while. From NVME->NVME, it can take upwards of 20 minutes, even if less than a gigabyte of data has changed since the last backup.

Carbon Copy Cloner, which I also use, has recently introduced a "Quick Update" feature that uses the operating system's transaction records, so that rather than doing a complete walk of the directoty tree, it can ask the OS which files have changed, and only back those up. A 20-minute backup with QRecall takes under 30 seconds with CCC.

(Yes, I realize they're doing different things.)

Still, it seems that implementing this feature has the potential to make backups much faster.

It seems strange that after months of problem-free backups, two separate computers developed identical problems at their first Big Sur backup...

But I'll give the full repair a try and let you know!

Done! Duh...

In general, doesn't seem to work. The backup operation may or may not succeed; if it does, merge and other operations will fail.

The reported error is always that the archive is damaged and needs repair. Disk Utility reports no problems; QRecall repair operations never seem to finish (>12 hours).

This has been observed on two computers so far; neither has been able to successfully back up since Big Sur.

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!

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..."

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:

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...

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.

D'oh!

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...

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...

I did try closing the "QRecall Monitor" application to prevent this from happening; however, closing it is impossible: that is, you can close it, but it just pops right back up.

It's possible the Monitor apps is just a monitor. However, if it's involved in actually starting scheduled actions, it sure would be nice to close it and have it stay closed.

I had occasion today to restore my entire Mac OS user folder from a QRecall backup. As it happens I'm back from a trip and the computer's been turned off for a while, thus, many backup/verify/compress tasks have queued up.

Restoring my user folder will take a while, and the scheduled backup task tried to trigger while the restore was going on. The message that popped up said something along the line of a scheduled action needs the currently open archive, which must be closed for the action to proceed. If I didn't do anything the archive would be automatically closed in 60 seconds or so.

I don't know if this would have actually happened or not, but in any case I cancelled all the pending actions.

It seems to me that scheduled tasks should never interrupt a currently running task. If the scheduled actions had actually stopped the restore process, the backup would have then backed up a user folder that was only partially correct.

Well, I ran Disk Utility (which I discovered can now repair your boot drive, yay!) and it reported no problems, after going through a number of checks I'd never seen before, but thus is the brave new world of NVME and APFS, I guess.

It reported no problems. But this evening QRecall ran its backup in less than 4 minutes.

As I look over at my Apple //e system, I fondly recall when I knew what EVERY F**KING BIT IN MY COMPUTER DID. Ah well!