Of late I've been seeing random "Could not capture file" errors in my backups. The files are invariably system-specific files located deep in the folder structure.

Action 2025-03-24 20:01:37 Failure cs_pc_a/evt_journalAttr_38CC956E-31E0-4AAE-A6ED-331771D2BED4_44652778_459.journal

...or...

Action 2025-02-04 10:10:44 Failure speakerRecognition/24D60-915b2b7b58cda908d393076c1774553c56bf6550_15.1033.1-int8_conformer_matrix_split-15.1033.1-en-US.bnnsir


The files that are not captured are not consistent; they seem to cluster around different aspects of the system each time.

This problem just started showing up a couple of weeks ago. Does anyone have any ideas?

Using QRecall 3.0.7(7) on my 2013 Mac Pro running Sonoma 14.2.1 (via Opencore Legacy Patcher), I'm unable to create a new archive on any volume. Trying to do so results in the spinning color twirly of death, and the application stops responding and must be force-quit.

Any ideas?

3.0.6 did in fact cure the problem!

I just downloaded QRecall Version 3.0.5(1) (3.0.5.1), and ran into an immediate problem using the Capture Assistant.

When I invoke it, I click the "Create an automated capture strategy" option, and then click Continue. The problem is that the text from the next pane overlays the text from the previous pane-- that is, the contents of the previous pane are not cleared. I can squint and make it past this point, but successive panes continue overlaying the existing text.

I have a screen shot of this but the forum software throws a MySQL exception when I make an image attachment, so....

I should note that I'm running Mac OS Sonoma on my Mac Pro 6,1 "trash can". Since Mojave is the last supported OS on this hardware, I'm using OpenCore Legacy Patcher to make it work; one of the things is does is patch the old Radeon drivers-- removed from post-Mojave systems-- so that the old Radeon FirePro D700 cards will work.

I realize this probably is a situation where I'm going to have to accept that QRecall won't run on my spoofed hardware, but hope that there's a possible fix.

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