Prion,

I'm assuming that the USB volume on the Mini is physically connected all the time, but not mounted all of the time (for whatever reason).

The QRecall scheduler running on the Mini should auto-mount the local USB drive before any scheduled action is started.

And, the QRecall scheduler running on the laptop should auto-login to a remote server volume before staring its capture.

However, if the USB drive on the Mini (the server) isn't mounted, a remote QRecall (the laptop) can't force that volume to mount on the server.

So that's the bad news. The good news is that there are still potential solutions.

Since QRecall on the Mini should auto-mount any physically connected device before an action runs, you could simply schedule an action that runs on the Mini to occur about the same time as the backup from the laptop. For example, if the laptop capture runs every night at 20:00, you could schedule a merge action on the Mini to run every night at 19:59. (A merge with nothing to do will complete within a few seconds, but has the side effect that the volume it mounts is still mounted a minute later when the laptop needs it.

For that solution to work, you'll want to uncheck the "Unmount volumes mounted by actions" scheduler option on the Mini.

A more "elegant" (read "nerdy") solution would be to attach a prolog script to the capture action that would use ssh to execute a script on the Mini that would mount the volume. This would require a script on the server to identify the device that the volume is associated with and use the diskutil command to mount it. You'd also have to set up ssh to connect to the Mini without a password (by generating and installing a public/private key pair).

A security update on our server inadvertently broke our diagnostic report server.

Some diagnostic reports (Help > Send Report, in the QRecall application) sent in the past week were successfully uploaded to our report server, but failed to be forwarded to our problem tracking database and have been lost forever.

So if you sent a report during the last week of January or the first week of February, 2020, and have not gotten a response, either send another report or contact support about your issue.

We apologize for any inconvenience.

Hanno,

QRecall only captures what's on the physical drive. So placeholders or links to items in the cloud (or even just a different volume) get captured as is; QRecall doesn't go out a try to read what that item refers too.

In this situation the cloud copy is really your "backup" and all reputable cloud storage providers have their own backup mechanism.

What you're describing sounds like a rolling merge.

A rolling merge is a merge action that groups older layers into time periods (days, weeks, months, years) and, as the layers age, automatically merges those groups into single layers.

In your example, a rolling merge something like

Keep most recent: 9 months
   Followed by:
        0 day layers
        0 week layers
        0 fortnight layers
        12 month layers
        1 year layer

would do approximately what you're asking. When you run this rolling merge action, any layers within the past 9 months would be preserved. Layers in groups of months, going back 12 more months, would be merged into single layers (one layer per month). Any layers in the pervious whole year would be merged into a single layer, and then anything before that would be merged into its own layer.

So if you ran this today (January 2020), the merge would:

Leave whatever layers you'd captured since April 1, 2019 untouched (that's the "keep" part)

Merge all layers in March, 2019 into a single layer
Merge all layers in February 2019 into a single layer
Merge all layers in January 2019 into a single layer
....
Merge all layers in June 2018 into a single layer
Merge all layers in April 2018 into a single layer

Merge all layers between April 2017 and March 2018 into a single layer

Merge all layers before April 2017 into a single layer

The beauty of the rolling merge is that it "rolls." You can run this action twice a day if you want, but it would only do something if there were multiple layers within a group. For this action, it wouldn't do anything more until you ran it again in February.

When this action runs again in February 2020, now there are a group of layers in April 2019 that get merged into a single layer. And when it's run in October of 2020, all of the single-month layers between January 2018 and December 2018 now fall in the year tear and get merged together.

The new rolling merge action editor has a really cool (if I don't say so myself) animation that will let you preview the effect of the rolling merge as you edit it.

And there's always QRecall Help > Guide > Actions > Layers > Rolling Merge.

Post again if you have any more questions.

Welcome aboard!

That warning is simply letting you know that not all of your changes were captured by that layer.

So if you had five items that changed, the capture was canceled after only three of them were captured, you later rewind to that layer and restore that layer, you'll have two items missing or they'll be older (previously captured) versions?in other words, not the versions that existed when that layer was captured.

When you start the next capture, QRecall will (always!) pick up where it left off capturing the two items that didn't get captured in the previous layer. And if you want to be tidy, merging those two layers will result in a layer that is complete and up-to-date and effectively nullifies the warning your received on the first layer.

To recall an item (or items) from the archive, you can simply drag the item from the archive back to your hard drive like a Finder copy.

The "Restore" command does much the same, but instead of you deciding where the recalled copy goes, you simply select the items in the archive; QRecall finds the original items and replaces them with the restored version.

I hope that helps. Please post any additional questions you have or send them to suppport@qrecall.com

This sounds like it's really stuck.

If it's still running, please send a diagnostic report first. Open the QRecall app, choose Help > Send Report.... The diagnostic report will sample all running QRecall components which will help identify exactly where it's at.

Afterwards, go ahead and kill the process and try the repair again. If the second try gets stuck too you might have a stale file locking semaphore on the file server.

There's a description of file locking / access problems in the help (Help > QRecall Help > Guide > Trouble Shooting > Problems > Can't Open Archive).

TL;DR: Restart your system AND your file server and try again.

Please let us know what worked (or didn't).

Jeffrey,

The answer is "kinda," at least for files that have been deleted.

In the QRecall browser window there are two commands: Edit > Select existing items and Edit > Invert Selection. You can see where this is going...

Browser the archive to the folder where you deleted files.

Choose Edit > Select existing items

Choose Edit > Invert Selection

The remaining items selected are the ones that exist in your archive but do not exist in your filesystem.

Occasionally I get requests for a restore "pre-flight" feature that will definitively list the items that would be restored. It's tentatively on the 3.0 development list, but we haven't gotten to it yet.

Quick poll: Would a "preflight" feature still be useful if it was only available from the command line?

Bruce Giles wrote:The folder itself gets backed up, but nothing in the folder does, so that's fine.

If you want to exclude the folder too, use this pattern:

/Users/bgiles/Documents // Virtual Machines ☐ ∞

All display names and icons in the archive browser window are cosmetic.

When a folder is displayed in the archive window, the items names are displayed as soon as they are assembled, while cosmetic information (like the icon) is collected on a background thread so you can start working with the items as soon as possible. Eventually the background thread will load the icon data and update the display.

But it's just that: a display. Icon and localization information that affect how an item appears in the Finder is collected during the capture but only so that QRecall can, as accurately as possible, show you how the item appeared when it was captured. But that display information isn't actually part of the item and when the item is restored it will be, once again, be the job of the macOS operating system to determine its icon and localized display

I hope that explains what's going on. I you still think there's a problem with the display, please take some screen shots and either post them here or send them to support@qrecall.com.

First, let's back up a step. Please describe the file(s) that QRecall is keeping open that are preventing your volume from unmounting.

None of the QRecall background components should be keeping any open files on external volumes, except the binary executable files themselves ... and those shouldn't be on volumes that would ever be unmounted while the system was running. The scheduler and monitor will occasionally check the reachability and status of archives and it may watch for changes in certain directories, but neither of these should prevent a volume from unmounting.

I also noted that the path /Volumes/xxxx/Users/yyyyy/Library/LaunchAgents/com.qrecall.scheduler.plist might indicate that your home folder is not on the startup volume, which could complicate your installation.

Finally, launchctl unload is a legacy command that's no longer supported; I'm not even sure it would work. Even if it does your command is targeting the wrong session type.

It's probably a bookmark issue. Excluded items are stored as bookmarks (which replace aliases), but like aliases changes to volume identifiers and whatnot can cause them to lose track of their original item.

As an alternative, try using an exclusion pattern, since this isn't a folder that's likely to get renamed or moved.

In the Patterns section, add a new "glob" pattern, enter the path you want to exclude on the left and make the pattern to exclude * on the right, like this:

/Users/bgiles/Documents/Virtual Machines // * ✓ ∞

That should permanently exclude every item in your Virtual Machines folder forever.

Jessie,

The new backup model is a feature called "stacks". The idea is that QRecall will isolate all of the data that makes up an individual layer in the archive, which we're calling an archive "slice". You then periodically upload slices to a stack, making that stack an archive of your archive.

We plan on making the stacks as flexible as possible, both in terms of where they can be stored and how often they get updated. The stack can be as simple as a second hard drive, but it could also be on a local server, on a remote server, a pile of (re)writable DVDs, a folder in your cloud storage (Apple, Goggle, ...), DropBox, AWS S3, and maybe more.

We're toying with the idea of providing a managed network-based storage service available for a monthly fee, but the primary tools will always be available for you to decide, control, and manage your own stack(s).

We were hoping to get this in beta this fall, but Catalina has seriously disrupted our development schedule. Watch for a beta announcement on the forum or just check the download page on the website.

Bruce Giles wrote:So those two requests for access were unexpected, and caused a significant delay. I'm hoping this was a one-time thing, and the problem won't recur.

It shouldn't reoccur, at least for the questions you've already answered. But I'm actually surprised it interfered with the capture process. It shouldn't; the QRecallHelper and QRecallScheduler processes are largely independent of one another and blocking the scheduler shouldn't prevent capture from running unabated.

And, as you might guess, this is a security feature and there's no way to disable or get around it. So during your initial upgrade you'll just need to answer "OK" to any access questions.

By the way, when I moved the archives, they appeared to copy rather than move. I had a copy in /Users/Shared, and I had another copy in the "Relocated Items" folder. My archives were large enough that this shouldn't have been possible -- I didn't have enough free space on the drive to maintain two copies of the archive files. When I deleted the copies in the Relocated Items folder, I checked the free space on the disk and noticed that it didn't change. Apparently the duplicate copies never occupied any space. I'm guessing this is one of the new tricks that APFS provides.

Yes, this is an APFS trick. In APFS, copying a file (by default) creates a "clone" of that file—both files share the same set of data blocks. A lazy "copy-on-write" feature makes the actual copy, on a block by block basis, should you modify either of the files.

There is now a Catalina (macOS 10.15) compatible version of QRecall available.

If you are already running Catalina, QRecall will suggest this update automatically. If you are not yet running Catalina you can download it manually, although you won't (shouldn't) notice any difference.

Please read the release notes as it contains important information about how system volume captures and restores have changed.

Bruce Giles wrote:Or does Reindex do something that Repair doesn't?

Both reindex and repair rebuild all of the index files (using the same code).

The only difference between a reindex and repair is that the reindex doesn't touch the master repository.data file.

A repair opens the master data file read+write and will erase or repair any damaged records or inconsistencies that it finds.

A reindex opens the master data file read-only and simply fails if it finds any inconsistencies.