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.

David,

Sorry to hear you're having problems. I'm sure there are going to be some edge cases to work out, but I have several computers here running Big Sur and they're all capturing files as I type this.

Next step is to send a diagnostic report and take a look at exactly what those errors are.

David,

Thanks for the diagnostic report.

Your logs indicate that there's a corrupt value in the layers.index file. This is an auxiliary index file that summarizes the directory structure of the entire archive.

A reindex of the archive should fix it.

Your logs also show that you started a repair on 11-16 a 12:25. It was canceled about 50 minutes layer, and it promptly stopped at 13:11.

I suspect that starting another repair, and letting it finish, will fix the problem.

If not, please send another diagnostic report after the repair.

Done! Duh...

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!

It might be something to do with Big Sur. Or it might just be a coincidence.

The next step is to see if it happens again, or to other users.

Update: Probably not a coincidence.

So when I said "other users" ... that was me.

I haven't run into this error on any of the hundreds of captures performed by my regular machines running Big Sur.

But ... I just ran into the same error while debugging some new QRecall 3.0 code. So there's probably a Big Sur related glitch lurking somewhere.

David,

So there was a problem. It wasn't, technically, specific to Big Sur, but Big Sur is what drove QRecall over the edge.

The layers.index file stores a compact summary of the directory structure for all of the archive's layers. There was an assumption that a folder wouldn't have more than few hundred subfolders. If a folder has more than 65,000 subfolders, the file would get corrupted, and that's what was happening.

The metadata daemon in Big Sur creates temporary folders inside /private/var/folders (the standard UNIX location for temporary and cached data). But unlike Catalina, the Big Sur version creates a lot of subfolders. And I mean, hundreds of thousands of subfolders?all in a single folder. (It's clearly taking advantage of APFS's hashed directory structure, but it was unexpected behavior.)

So if you happened to capture a volume while the metadata daemon was working particularly hard, there was a possibility that you'd capture a folder with too many subfolders.

The latest version of QRecall (2.2.9), expands the subfolder limit to 4 billion.

Update at your leisure.