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}" '*:*'

Nancy,

That's an interesting suggestion.

When designing QRecall, the assumption was that you would regularly capture your startup volume. When disaster struck, you would restore your system from one of the many versions captured in the archive, and get back to work.

And yes, that's exactly the technique described in the Backup Strategies > Bootable Recovery Drive section of the help.

So it has never occurred to me that someone would want to automate a recall/restore.

While it's not a built-in feature, you could automate a regular recall/restore using the qrecall command-line tool, although that's a bit geeky. In fact, in the latest version of QRecall (2.1, to be released any day now), you could attach a script to your daily capture action that would then immediately restore that same volume somewhere else.

If this is something important to you, let me know and I'll put it on the wish list.

Nancy Baird wrote:Is is possible to make a bootable duplicate with QRecall (like with CarbonCopyCloner or Super Duper)?

Absolutely.

If you capture a bootable system volume and then restore it to different volume, that restored copy will be bootable too.

See QRecall Help > Basics > Restore Items > Restoring a Volume to a Different Volume.

Having said that, there is some fine print. The system you use to restore the volume should be the same major version of macOS (or later) and of course the volume you restore to must be capable of booting macOS (e.g. local hard drive, HFS+ or APFS format on GUID partition, ignore ownership and permissions turned off, ... in other words, the same prerequisites required to install a fresh version of macOS).

Alexandre Takacs wrote:Problem seem to be back - tried a restore - failed.

Thanks for sending a diagnostic report.

The restore command is crashing inside the code that tries to match the volume identity of the captured items with the volumes you have on-line. There appears to be an empty/null/whatever volume name or something that's causing the crash.

I'm digging into it now, but in the mean time try to perform a recall instead of a restore (a recall doesn't need to find the original location of the captured item).

Kurt Liebezeit wrote:After thinking a bit more, I wonder if this was a ZFS filesystem error.

It could be. I don't have much experience with ZFS, but on the Mac native filesystems, a corrupt volume structure can present itself as I/O errors, even when there's nothing physically wrong with the drive. (That's why the Repair command prompts you to repair the volume directory structure on the archive volume before proceeding.)

Seems unlikely given that the log seemed to have had a lot of entries that looked like errors that recovered on retry, but I'm still bothered by the pristine SMART data.

SMART drives have never been very smart. SMART really is little more that a guess about the drive's health, and I've had drives declared to be in perfect condition by SMART only to die completely the next day. So a negative SMART warning should be taken as a sign something is wrong, but a positive SMART status doesn't mean your drive has years of error-free service ahead of it.

I wonder if it would be possible to surface the hardware error by doing a Unix dd command read, sending data to /dev/null?

Yes, that will at a least perform a read on the entire surface. Note that this is effectively what a QRecall verify action does; ditto for repair.

There are a (precious) few disk utilities that will perform a read/write surface test of your drive. The last one I used is DiskTester from the diglloyd Tools suite. There are so few disk utilities that will actually perform a surface test, I've considered adding it as a utility to QRecall.

I did get your logs, but they're basically 40MB worth of "I/O error reading repository.data file" messages, which you already knew.

Bruce Giles wrote:So you're saying that if I install the latest QRecall on the mini, and then connect the external drive that contains the backup created by QRecall 1.2.3.8, I should be able to restore those files and folders to the mini?

Yes

Also, will it make any difference if the server drives are APFS?

No. To QRecall, a volume, is a volume, is a volume.

But getting back to my previous suggestion, I'm sure the mini won't boot with a copy of Snow Leopard on it; that's why I suggested using Internet recovery mode to install High Sierra over the Snow Leopard boot volume. My concern is that there's a lot of stuff in /Library and /var/db that you might want and just migrating /Users and /Groups is not going to include.

Then again, this is a new system so just give it a try. If it doesn't work, you can always and wipe it and try plan B.

In theory, the latest version of QRecall can read any archive, back to about 1.0.something. So you could load the latest version of QRecall on the mini and use that to restore, piecemeal, whatever you want.

However, I've noticed that the server software keeps changing stuff with every major release and I'd worry that simply dropping OS X Server 11.6 files into a 10.10+ system isn't going to work. So if I were doing this, I'd take this approach:

Use whatever set up you can (target disk mode, etc.) to restore the entire OSXS 10.6 system onto the mini's HD.

From 10.6 system, or using recovery mode, install 10.13 over it.

The installer should perform whatever upgrades are necessary to the data, users, directories, configuration files, etc. to bring your 10.6 system up-to-date.