I have my long-term Archive on external disk A along with other backup stuff. This disk A is cloned to disk B for off site storage.
When I connect Disk B QRecall's Actions start capturing to the cloned Archive. While this makes some sense (the Archives on both disks are identical after all) and there's no harm in a capture, there might be issues I'm not aware of.

Things seem to change with beta 1.2.0.57/58: The status window clearly distinguishes between the Archive on disk A and its clone on disk B. They show up as different archives with different status (as there was no verify on disk B yet).

This is at least confusing. I would prefer QRecall's actions to leave the clone alone.

But maybe my clone strategy is simply not compatible with QRecall's philosophy. What would be your advice?

Johannes

QRecall uses an alias—a standard Mac OS structure for keeping a reference to a file or folder—to identify the archive associated with an action.

Aliases can be tricked into pointing to the wrong file, and it drags QRecall along with it. When you mount your Disk B, the OS sees what it thinks is the original archive that belong to the action and QRecall uses that archive.

There's no real harm in this, beyond wasting time. QRecall archives are just documents and are completely self contained. You can copy, move, and rename them as you like.

The duplicate status information is an artifact of the upgrade. The original and cloned copy of the archive were separately updated with status information (since neither had any) and have been assigned different status identifiers. The next time you clone the archive (overwriting the clone with the original), it will also clone the status info and the duplicate status indicator will disappear.

I would prefer QRecall's actions to leave the clone alone.

QRecall treats all archives the same, and has no way to know that an archive is a copy of another archive.

I have on the drawing board some plans to implement rotating and cascading archives, so that QRecall understands the master/slave relationship of this style of backup solution. But for now, it's very egalitarian.