QRecall (or at least the current incarnation) only works with mountable volumes. So I you say "over the internet" I assume you're speaking of a remotely mounted volume on a server or NAS device.

Compression, and QRecall's unique data analysis, can significantly reduce the amount of data your backups consume. This, in turn, can significantly reduce the amount of data you have to transmit over a network connection. (I have one customer who says recalling from a compressed archive is faster than doing a straight copy of the same files from his networked volume.)

Trying to split your archives into different types probably won't help and will ultimately introduce more overhead (due to the need of updating multiple archive documents). QRecall is really smart about compression and de-duplication, and it works best when everything is in the same archive. The only major advantage would be to split very large archives into smaller ones so that maintenance is manageable (see last answer).

In modern (multi-core) computer systems, compression adds only a modest amount of CPU and memory overhead. It's measurable, but if you can benefit from the compression it's certainly worth turning on.

Merging over a slow network connection isn't going to be particularly slow. The verify, compact, and repair actions will, on the other hand, be slow due to the requirement of reading every byte in the archive. Either schedule these tasks to run infrequently (say, once a month), or (if possible) try to perform them from a system that has a fast(er) connection to the data.

If you're asking how that would look, that would be a merge action set up to create 14 day layers, and nothing else.

Attached is a screenshot.

Jeff,

You might want to start with the Capture Assistant and have it implement a capture strategy, which you can then customize.

You'll most likely want to customize your capture actions. You can capture every hour, if you like, or you can add additional capture actions. Examples: I capture my home folder every hour. I also have a capture action on my server that captures my Git repositories 2 minutes after any change is detected.

The rest of the actions (merge, compact, verify) are maintenance tasks that only need to be done once a week, often less. That's why I suggest you start with the capture assistant; it will create all of the regular maintenance actions with reasonable schedules, which you can then adjust to meet your needs.

Jeff Lambert wrote:Hi, I've had a couple of warning because I had a scheduled Backup and my mac wasn't running at the time. Now I want to get rid of those warning and not see a orange circle in my menu bar QRecall icon. Is it possible to reset the logs?

If you're talking about the warning indicators (yellow or red signal) in the archive status window, you can silence these warnings in that same window.

(1) Open the Archive Status window from either the QRecall Monitor dock icon or menu bar item.
(2) Expand the status pane of the archive with the warning
(3) Click the action (gear) button
shortcut for 2 & 3: control/right-click anywhere in the archive's status pane
(4) Choose one of the Silence options

You can have the monitor ignore a warning forever, or only until the action that would remedy the warning has had a chance to run again.

On another issus, It seems that I can't backup my Home Folder anymore. I upgraded to Mojave on Monday, and since then, I get an error message saying can't backup Home Folder, and the backup takes 0 sec. I've tried reinstalling QRecall, gave it full disk access, but still it's not working. I now have deleted that action that backup to my main Archive which is for the full disk.

You do need to grant QRecall Full Disk Access, but it's not the file you think it is.

Open your <home folder>/Library/Application Support/QRecall folder. Inside that you'll find an executable file named "QRecallHelper". This is the binary that actually performs the capture/recall, and is the one that needs full disk access. Drag that file into the Full Disk Access category of the security preferences panel and it should start working.

Note: We're working with Apple to resolve a number of issues still outstanding with Mojave and Full Disk Access, so this isn't a done deal just yet.

I thought this would be more stable than TimeMachine but I guess with TM I just didn't know when it was not working and now I know when QRecall isn't working

I occasionally get complains about how much QRecall complains when things aren't working perfectly. But if your data is important, you need to know this stuff!

Jeff,

Glad you found the Actions window. Each archive window also has an Actions sidebar (on the right) where you can see just the actions for that archive.

Jeff,

Excellent question.

The Stop at 8PM condition means that if the action is still running when 8PM comes around, the action is stopped, just as if you clicked the stop button at 8PM.

The schedule condition you probably want is "Ignore between...". Set up something like "Ignore between 8PM and 9AM", and the interval schedule will run every hour starting at 9AM through 7PM.

Jeff,

Thanks for choosing QRecall and for the heads-up on the website.

We're actually the process of redesigning the website and installing newer forum software. Obviously, someone tripped over the extension cord keeping the current one alive until that happens.

Everything seems be back to normal. Post again if you have any more questions.

Mike,

It disappeared because I made it disappear.

The default setting for the "Show in menu bar" option is now "no," while in earlier versions of QRecall it was "yes." To make the menu bar icon reappear, launch QRecall and go to QRecall > Preferences > Monitor, and check the "Show in menu bar" option.

The reason for this change is the new "Show in dock" option, added so that the QRecall Monitor can interrupt a restart or shutdown request if there are running action. Since the dock icon duplicates all of the functions of the menu status bar item, it made sense not to have them both showing by default.

Basically, your plan is sound. It just depends on how long you want to keep the details (individual versions) of items during these few weeks.

Yes, by all means simply create an archive and schedule it to capture just the activity of your working folder(s) for the short term.

When you have access to your original archive again, it will resume capturing your documents. Afterwards, your original archive will have the latest backups, it will just be missing the intermediate versions of the past few weeks.

If you're anxious to maintain those intermediate versions, simply hang onto the temporary archive for awhile.

There's no direct way to directly inject the history of one archive into another archive. It would be possible to script this using the command line tool—the script could run in a loop recalling each layer from the temporary archive and then capturing that into the original archive. The layer dates would be off, but it would replicate the sequence of versions in your original archive. It also seems like an excessive amount of work.

Christian Roth wrote:A final question: Does a QRecall activity in progress get a chance by the OS to clean itself up before it gets killed by the shutdown process? Asking if it was possible to cleanly stop any activity in time (and closing the open archive correctly) before shutdown actually happens. I seem to remember you actually implemented it that way, but that either there?s a hard time limit (10 seconds? - which with a >1TB archive I will always miss) or the SMB protocol network underpinnings go away earlier, so the process cannot finish writing to the NAS). But I?m not sure about the details on this one.

When shutting down, macOS first sends a TERM signal to each running process. A QRecall action interprets a TERM signal exactly the way is does the "stop" button in the monitor; it attempts to immediately cancel what it is doing and cleanly close the archive.

However, the shutdown usually only give it about 30 to 60 seconds to wrap up. If you have a big archive on a networked volume, that probably isn't enough time. If the process is still running, macOS will then send the process a KILL (force quit) signal, which usually leaves the archive in an unfinished state.

Most actions, however, should tolerate this. The common actions (capture, verify, merge) can be randomly killed and the next action will auto-repair the archive and continue on as if nothing had happened. The problematic actions are compact and repair, which cannot tolerate being KILLed, requiring the archive to be repaired.

Nancy,

So I'm not sure what's going on. According to man 2 intro, POSIX error 8 is:

8 ENOEXEC Exec format error.  A request was made to execute a file that, although it has the appropriate permissions, was

             not in the format required for an executable file.

So there's something about your file, or file format, that the kernel doesn't like. Try this command:

file ~/bin/mirror_volume.sh

The result should be "mirror_volume.sh: Bourne-Again shell script text executable, ASCII text"

If it's not, then that's the problem.

My first guess would be character encoding. Make sure the file is plain ASCII-7 or UTF-8 format without a BOM.

Cody,

Let's start by getting a diagnostic report. Choose Help > Send Report in the QRecall application.

The problem is probably related to moving your home folder to a different volume. Many of QRecall's services are installed as system daemons, and having your home folder on a different device than the system really complicates the situations and runs into all kinds of security restrictions.

QRecall was designed to deal with this kind of situation, but that doesn't mean it handles them all, and the diagnostic report should contain some clues.

In the mean time, you might see if your "Run actions when logged out" scheduler preference is turned on. If it is, try turning it off. When off, the scheduler runs as a user agent, which get launched much later in the login process.

Christian,

You'll appreciate that we were indescribably disappointed when this feature stopped working.

Yes, we added a dialog sheet to the QRecall Monitor user agent which presents a dialog asking you what to do about the actions that are running before shutting down. A GUI app that presents a dialog in response to a shutdown-releated quit request will halt the shutdown.

This was all working great during the beta period.

Then, suddenly, it stopped working so well. I'm not sure if it was the result of an OS upgrade or was just dumb luck, but now the QRecall Monitor may, or may not, halt shutdown. On many of my test systems I can actually see the dialog sheet roll out, only to watch macOS immediately terminate the app anyway.

*sigh*

I've reported this to Apple and I'm looking for a workaround, but for now this features is only semi-functional.

Nancy,

It's hard to tell what's going on, but I suspect your script file might not be executable. (That's not a joke.)

An executable script is marked as "executable" and has the magic "she-bang" line that tells POSIX which interpreter to use.

So the script should start with the line

#!/bin/bash

Then set the script file's "executable" permission flag:

chmod +x ~/bin/mirror_volume.sh

(obviously replace this path with your script's path)

Being able to run the script via bash means that the script is a functional bash script, but that doesn't make the script file itself an executable file. These two steps should make that happen.

When you're done, you can test this by executing the script directly, as if it were a standalone program:

cd ~/bin

./mirror_volume.sh

Or, if you want to really test it, execute it with the desired environment variables set:

env QR_ARCHIVE_PATH="/Volumes/Alpha's 2 Versions/Alpha's 2 Versions.quanta" ~/bin/mirror_volume.sh

Nancy,

To get you started, an epilog script (supported in QRecall 2.1) that would automatically recover the volume you just captured to a different volume would look something like this:

#!/bin/bash



# QRecall script to immediately restore the captured volume, to a different volume.

# Note: this script assumes the archive contains a single volume for a single owner.

# If there is more than one owner or volume, adjust the '*:*' parameter accordingly.

# Also, make sure the mirror volume has ownership and permissions enabled and is

# the correct format (HFS+ or APFS).



# Path of volume to mirror

# WARNING: this volume will be completely overwritten

MIRROR_VOL='/Volumes/Mirror HD'



qrecall restore "${QR_ARCHIVE_PATH}" --tovolume "${MIRROR_VOL}" '*:*'