In the modern macOS, laptops no longer have an explicit idle sleep time (that you can set). It is now "always" and "automatic", with a few exceptions.

The power saver system preferences settings is now divided into two panes: Battery and Power Adaptor.

In the battery section you have the ability to set the idle sleep time for the display. The shorter this time the more power you'll save, and the sooner your display will sleep. The entire computer sleeps immediately, or a short time, after this.

In the power adaptor pane you can also set a sleep time for the display. The system will also go to sleep soon afterward, unless you've set the time to "Never" or checked the "Prevent computer from sleeping automatically when the display is off" option.

So when you're not using your system, the display will dim and then power down after the time you've set, and the entire system will go to sleep soon afterwards. There are, of course, a number of exceptions to this.

Software (like QRecall) can request that the system not go to sleep. QRecall actions do this when they start running (or an action is about to start). This is what prevents the system from going to sleep while a QRecall action is working. Once the action has finished, it signals to macOS that it no longer needs to keep the system awake.

Another exception is the lid. Closing the lid of a laptop will cause the system to go to sleep. It doesn't matter what your settings are or what software is running, the system will stop. Normally this isn't a problem for QRecall, but it can be depending on your hardware (external volumes sometimes have problems reconnecting after power is restored and cause read/write errors immediately after waking up).

When you add a "Before scheduled time: Wake" to the schedule, QRecall tells the power manager to wake your system (assuming it's asleep) a minute or two before the action is scheduled to run. If the lid is closed, there's not enough battery, or the system is shutdown, this request it ignored.

The "After running actions: Sleep" option sends a request to the system that, after the QRecall action has finished running (and there are no other actions ready to start), the system should go to sleep at its earliest convenience. It is not a command. It does not force the system to go to sleep. If you're using the system, or if other software is requesting that it not go to sleep, this request is ignored. So if you want your (idle) system to go back to sleep soon after a QRecall action has finished, set this schedule option. Note that even without this option, the system will eventually go back to sleep on its own, it just might take longer depending on your display sleep time setting.

Finally, "Power Nap" is a feature added in macOS 10.8 that, on certain laptops, will occasionally "wake" from sleep to enter a very-low power mode that performs limited background tasks and then goes back to sleep. These include checking your mail, updating your calendar, performing Time Machine backups, downloading software updates, and so on. The system isn't useable and only Apple designated tasks are suppose to be running. But in real life, we've experienced problem with Power Nap that it allows some background QRecall tasks to run/start, but will often leave external drives powered down so those tasks might fail.

If you need or like Power Nap, go ahead and turn it on. Your mail will be waiting for you when you wake the system up again. On the other hand, if you have QRecall actions that start and fail during power naps, consider turning it off.

I hope that answers everything!

Oops, I got distracted and forgot to answer the other half of the question.

The compact is incremental, because (most of) what it's doing is simply relocating records in the file so all of the records are physically adjacent to one another (no empty/unused space between those records). If you stop the compact you leave some records adjacent and others not. When you start it again, it will simply resume moving the non-adjacent records.

Empty space is created following actions that remove old data from the archive, most notably a merge.

A capture action only adds new records, so a capture won't create empty space or delete records.

So a capture won't have any material impact on the next compact action that runs because it never creates empty space or non-adjacent records.

Steven J Gold wrote:... but what would happen if I attempted to take another backup (recapture) before the Compact is restarted & completes?

Just start it and find out.

Spoiler: the second action will simply wait for the compact to finish.

QRecall uses several layers of file access coordination so that no two actions are modifying the archive at the same time. (It's possible for multiple actions to read the archive at the same time; for example, you can run a recall action simultaneously with a verify or while the archive open in a browser.)

This works no matter how you run the actions. The scheduler will hold conflicting actions that are ready to run, but even if you start an action from the command line or another (networked) computer, the actions should handshake with one another so that only one is modifying the archive at a time.

Tim,

If the reindex was successful, then your archive is fine. Also, a reindex and a verify require about the same amount of time/effort which lends to the theory that this is a semi-random event.

When I get reports that a drive is un-mounting in the middle of long action (like verify) but not for other actions, I also look to the possibility that it is un-mounting at other times and there's simply no process to notice.

If you're handy in the Terminal, you might occasionally use something like fgrep 'mounted volume' ~/Library/Logs/QRecall/QRecall.log* | fgrep Seagate to look for times when your Seagate drive(s) unmount at unexpected times. (The log you uploaded only covered two days, which isn't enough time to catch something like this.)

If you find these scattered around, I suspect your drive has been spontaneously unmounting all along but only causes grief when it intersects a long running action like a verify or repair.

Tim,

I'm sorry to hear you're having problems.

I suspect the problem is in your hard drive (hardware). Less likely, it might possibly be a bug in the some of the special software you're running—although, honestly, I can't image how.

QRecall definitely does not issue unmount requests to volumes that are being verified or repaired. And even if it did, it wouldn't matter; software can only request that a volume be unmounted. The filesystem will refuse that request if there are still open files—which is obviously the case here.

The only way for a volume to get unmounted while you have open files is a spontaneous loss of connection with the device, and this is usually a hardware issue. (Full disclosure: there have been a few OS bugs that caused this too—like the infamous "FireWire sleep" bug—but right now I'm not aware of any).

We'd be happy to help you look for clues in your logs, but we'll need a lot more context. Start by sending a diagnostic report (in the QRecall app, choose Help > Send Report). Then locate your QRecall.log file, compress it, and then use a file transfer service like We Transfer to send the compressed file to support@qrecall.com.

Greetings Mike,

Each action is stored as a document in the ~/Library/Preferences/QRecall/Actions folder. Each document has a name that should make it clear what that action does.

You can move those documents, en mass, somewhere else and they will cease to be actions in QRecall. (When I'm doing testing I just move them all to a folder named Actions (disabled).)

QRecall does not expect the documents in this folder to suddenly appear or disappear, so you'll need to let QRecall know that the contents of the Actions folder has changed. Creating a new action or deleting an existing action is usually sufficient. Alternatively you can quit both the QRecall application and the QRecallScheduler process (you can do that in Activity Monitor). If that's too much hassle, a system restart will get it done.

Let us know if you have any other questions!

That would, absolutely, work too.

Snapshots help, but don't totally solve, this problem.

An APFS snapshot is just that: an instantaneous copy of the entire volume, frozen at a point in time. (Naturally, the filesystem doesn't actually copy the entire volume—it's all just metadata slight-of-hand—but the effect is identical.) Any further modifications to the volume (writing new data, creating new files, deleting files, and so on) happen on the "live" version of the volume and does not alter the snapshot.

This helps make the backup process much more stable and it doesn't have to worry about race conditions like files being added or deleted to a folder after QRecall has read the directory to find out what files it contains.

It does not, however, solve the fundamental problem of data that hasn't been written yet. The issue with virtual machine files (and databases, and large media files, and so on) is that they are still being written to while the capture is in progress. The backup copy is then a half-written file that is unlikely to be usable. Snapshots don't really change this equation, it just changes the point in time that the captured data is out of sync with the file as it will be written.

Snapshots can, however, make it easier to live within these constraints. The best solution QRecall can offer is a slightly modified version of the solution you already have.

You're already doing the right thing—closing all of your VMs before starting the capture. QRecall can automate this if you schedule the VM capture action to start as soon as your VM software application quits. This way, you don't have to remember to do anything; whenever you quit your VM software a capture will start immediately.

The beauty of APFS snapshots means you don't have to wait for the capture to complete to get back to work. As soon as the capture starts, it will have made a snapshot of all of your VM files (in their closed, pristine, state). You are now free to launch your VM software and start working again; new changes to the VM won't be part of snapshot or the capture that's in progress, no matter how long it takes.

I wouldn't recommend creating a new user. After entering your identity key, if you have problems capturing just try restarting your system.

This is a long-standing issue with the way macOS now shares (or doesn't share, to be more precise) preference changes between different applications.

Darryl Tooth wrote:That didn?t work... As soon as I launched QRecall and then went to change the preferences the app just locked up.

Also be aware that when trying to fix installation issues, QRecall my fail to connect with (deleted) services still registered with macOS. This may result in stalls and timeouts, so be patient. During startup or when changing the service configuration, give QRecall a minute or two to fix the problem.

If you just want to rename them (in place), it shouldn't be a problem.

Things get a tad more complicated if you move the archive and rename it, or relocate it to a different volume. But QRecall shouldn't be tricked by simply renaming it.

The worst that can happen is that your actions fail to locate the renamed/moved archive. To rectify that, simply open an action, choose the new archive, and save it again.

Darryl,

Thanks for letting us know about this. First, send a diagnostic report: in the QRecall application choose Help > Send Report…. Screen shots of the log are great, but there's a lot more details behind the scene that the report will capture.

But even before I see the report, I'm going to guess that QRecall is having problems installing its privileged helper. This is a privilege escalation service managed by macOS, and sometimes it get "stuck" for unknown reasons. The result is that macOS doesn't install the new service, yet the service won't run.

When you turn off Capture and recall items using administrative privileges what you're doing is telling QRecall to run without privileges, so it doesn't try (and doesn't get any errors). But without privileges, it also can't capture and restore your system files, take snapshots, make power management requests, and so on.

Try this:

Perform a a quick uninstall of QRecall: In the QRecall app, hold down the Option+Shift keys and choose QRecall > Quit and Uninstall.

Delete the file /Library/PrivilegedHelperTools/com.qrecall.hoist

Delete the file /Library/LaunchDaemons/com.qrecall.hoist.plist

Restart your computer.

Launch QRecall and reinstall it; make sure you've turned Capture and recall items using administrative privileges back on.

If either of those two files existed, then I suspect that was your problem. If that doesn't fix it, we'll know more when your diagnostic report arrives.

Finally, admin privileges and the volume format or protocol used for you archive volume are largely unrelated.

Good news: we're getting closer

The problem was that you weren't running 2.1.14(3). All of the action logs up to now were still running 2.1.14(1). When you launched QRecall to send this report, that was 2.1.14(3) ... which should now be installed.

I suggest

Launch QRecall again and use QRecall > About QRecall… to verify that you are, indeed, still running 2.1.14(3).

Deleting all other copies of the QRecall application you have lying around. It's OK to keep the installer disk images for earlier versions, as long as they're not open.

Continue running 2.1.14(3) to see if it fixes the problem.

Send another report in about a week if you don't see any problems.

Greetings,

As a rule, QRecall isn't designed to protect against changes to your source files, because source files change all the time.

QRecall protects against data corruption by preserving older versions of your files for as long as possible. Its block-level data de-duplication and compression help in that mission by storing your files in as little space as possible, allowing you to keep more history. So if you do discover that a file is corrupted, you have a better chance of recovering an earlier, valid, copy.

There are utilities that will calculate checksums of your file. You can then periodically use that information to detect if any data in your files has changed.

On the other side of the equation, it's a completely different story. QRecall archives have multiple layers of interlocking data integrity checks, so that even a single corrupt bit of data in an archive will be detected. These integrity checks are verified during every operation. It also has the option of storing redundant data so that modest amounts of data corruption can be corrected and recovered.

I hope that answers your questions.

David Ramsey wrote: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".

"Frankenstein" is the name of your identity key. When you first install QRecall, your identity key's name defaults to the name of your system. It will remain that until you change it.

To change your identity key, go to QRecall > Preferences > Identity Key and edit the name.

The full syntax for specifying an item in an archive is <owner's name>:<volume name>/dir/.../dir/item, essentially the path you see at the bottom of the archive browser window.

The convenient * syntax means "the one and only owner" or the "one and only volume". But you have more than one volume, so the * syntax can't be used.

There are two easy ways to solve this.

First, you can simply delete the "CCC Backup" volume. You were trying to solve the problem stopping captures of your "CCC Backup" volume, so this seems like the preferable choice. Once you're back down to a single volume, the * volume name will work again. In the browser, navigate to the owner level ("Frankenstein"), select the "CCC Backup" volume, and choose Archive > Delete Items….

Alternatively, you can specify the volume in the item path so there's no ambiguity: qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*rimary/Users/dramsey/Library/Preferences/QRecall/Actions'

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' '*:*'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall'

The first two should only list one owner and one volume, respectively; if they don't, that's probably the issue.