Mojave is the last macOS you can restore a bootable startup volume using QRecall. So if you follow my previous instructions (create a new APFS volume and restore your volume to that), the results should be bootable. Also...

Steps for downgrading macOS:

If you're also restoring from QRecall, it's cleaner if recall your volume from QRecall before re-installing the (old) OS over it.

Download an earlier macOS installer using the (not-so-)secret App Store links.

Create a small HFS+ volume on an internal/external drive, or use a largish USB thumb drive (on computers that can boot from a USB drive).

Create a bootable installer using the createinstallmedia tool that's imbedded in the macOS installer app.

Reboot from the volume the tool just initialized and install your old OS somewhere (on a new volume, or into the volume you restored with QRecall).

Note: I've noticed that using a USB thumb drive has been problematic with some recent Macs. I have a Mac Pro 2019 that I cannot boot from a Big Sur installer volume created by createinstallmedia, even though this Mac shipped with Catalina. (It starts to boot, and then just crashes.) But if I add a small volume partition to a spare internal SSD, it boots from that just fine.

Mike,

At that point the computer was able to boot off its system volume. But it was running Monterey. I naively expected it to be running Mojave.

Mojave is pre-Catalina, so it exists as a single volume. Catalina and on, the startup volume is a volume pair: an immutable system volume and a mutable data volume.

During the Monterey install, your single volume was split into a system volume and a data volume. When you then restored your Mojave volume to it, you only ovewrote the data volume. The core operating system (Monterey) is still on the immutable system volume, so that's what'a going to boot. And yes, you've created a kind of Frankenstein OS that will probably exhibit some bizarre behavior.

To jump back to Mojave, you need to completely erase the Monterey System/Data volume pair, create a new (single) APFS volume, and use QRecall to restore that. That should get you back to running Mojave, from which you can then proceed forward.

Mike,

Sorry to hear about your trouble upgrading your OS.

There are a number of paths to follow. One is the command line, but that's pretty technical.

Here's my suggestions:

First, start by simply trying to preform the upgrade again. This would be the simplest solution, if it works. Even if your startup drive isn't bootable, you can always reinstall the most recent macOS that your hardware supports using recovery mode. It's entirely possible that something went sideways during the upgrade (and jumping three major version in a single go is fertile ground for complications).

Hard reboot your machine and start it up in recovery mode. Then just try installing Monterey again. If that works, you're done. (As much as I love it when people use QRecall to solve their problem, NOT having to perform a full-system restore is usually a simpler solution.)

However, if you now believe that your startup volume has been trashed and is unrecoverable, you can restore from QRecall and reinstall macOS. The easiest way to do this is from a second bootable volume. Since you didn't create one ahead of time, create one now?and again, recovery mode and APFS are your friends:

Start up in recovery mode

Use the Disk Utilities to erase/reformat your startup drive

Create a new APFS volume on the drive named Lifeboat (or something)

While still in recovery mode, install macOS on the new Lifeboat volume (user name, passwords, settings don't matter; just keep it simple)

Now that Lifeboat is installed and booted, download QRecall and install it

Launch Disk Utility and create a second APFS volume (APFS containers can hold multiple APFS volumes that share the same space); this will be your new startup volume

Launch QRecall; open your latest archive and select the volume to restore, hold down the option key and choose Restore Volume To...

Select the volume you just created in Disk Utility and start the restore; this will take awhile

When you're done, either download the Monterey installer again from the App Store, or use recovery mode again, and install Monterey on top of the restored volume

If successful, you can use Disk Utility to delete the Lifeboat volume

Now if all of that doesn't work, then there's a serious problem installing Monterey on your startup volume. Alternative solutions would be to upgrade to an intermediate OS first (rather than trying to jump directly to Monterey). Another approach would be to install a blank version of Monterey on a new volume, then use the migration assistant to import your old startup volume, rather than trying to install the OS directly on top of an existing installation. The latter approach assumes you have enough disk space, and there are a few tricks to make that possible too, so post again if you're still stuck.

Johannes,

We are aware of the problem of actions windows not displaying, but have yet to reproduce it here. We've tried QRecall 3.0.x on both Intel and M1 Macs, on macOS 12, 11, and 10.15, we've even tried opening the actual action documents from users having this problem and still can't replicate it.

So now we're asking for beta tester help.

If you're having this problem, please try the following:

Open the Console app.

Select your device (computer name)?it should be the default?on the left.

Click the Start Streaming button; you may have to enter your admin password the first time.

Enter "QRecall" into the search field, upper right.

Open QRecall.

Try to open an action window, from the actions window, or create a new action.

If the window contents are blank, continue...

Switch back to the Console app.

Click the Pause button in the toolbar.

Select everything in the window and copy it to the clipboard.

Create an email to support@qrecall.com and paste in the results.

Follow up by sending a diagnostic report in QRecall (Help > Send Report).

This will help us look for anything unusual that might be getting logged by the system UI that's preventing the action windows from displaying.

Thanks for reporting this, and thanks for helping make QRecall better. Beta testers are the unsung heroes of software engineering!

The manual for QRecall is bundled in the application. Download it, install it, and chose Help > QRecall Help.

There's also a fairly recent copy of the manual on-line.

As long as you can mount the storage for your Micro PC as a volume on the Mac, QRecall should work.

While QRecall is focused on capturing and restoring macOS native filesystems, the archive can be stored on any volume that can be mounted on macOS, which includes networked servers, NAS devices, thumb drives and more. Not every filesystem is supported (because some are flawed), but that's the goal.

In the past, it was possible (although not recommended) to capture and restore your Spotlight database.

The latest versions of macOS, however, makes a lot of the spotlight data inaccessible, even to processes running as root. So if you did capture those files in the past, I'm not at all surprised you can't restore them now.

Mike M wrote:I found the section of the log at the point the restored finished. Maybe you can explain this.

That's simply the summary message that one or more issues were encountered. You'd have to search back through the log to find the specifics of the/each issue.

If you like, compress your log file(s), email them to support@qrecall.com, and we'll take a look at them for you. (We have a number of automated tools for combing through log files looking for problems.)

Mike M wrote:But I'm thinking that if the recall was incomplete, then I'm missing data

That is entirely possible.

Mike M wrote:What I'd really like to do is verify it against the archive at the time of recall.

A verify action only validates the internal consistency of the archive. It doesn't compare what's in the archive to what's on disk. There's currently no function that will tell you the difference between what's on a volume and what's in the archive, although that is a requested feature and is still on the wish list.

(Well, that's not exactly true; in the archive browser you can choose Edit > Select Existing Items, which will effectively compare the files in a browser view against what's on the volume, but it only works for the currently displayed folder.)

Then that's very odd. Then the message is probably in there somewhere. You might increase the detail level of the log window. Or you can just search the log files manually (they're just plain text files). less and grep are your friends.

The recall issue you saw was most likely something to do with the recall process itself; a permission error, or out of disk space, or something like that. A data corruption in the archive (which is what a verify would reveal), would have stopped and immediately terminated the recall command with a fatal error.

Mike,

I assume you were restoring your entire startup volume.

The bad news is that your startup volume includes your log files. So the restore replaced your working log files (the ones being written during the recall) with your captured log files. (Note that it also restored your QRecall preferences and other ephemeral settings.)

This conundrum has been partially addressed in QRecall 3.0, but not entirely.

David Ramsey wrote:(Yes, I realize they're doing different things.)

You are correct, they are doing different things.

However, QRecall does use the filesystem history to quickly skip over folders that do not appear to have any changes, and it's done this since ... well ... filesystem history was introduced into OS X.

This is a bit of a complicated subject, so there are a few caveats.

First, QRecall does not blindly trust the filesystem history. There are known situations where the filesystem history can miss changes, and a "deep dive" into the file hierarchy is the only way to catch those changes.

On occasion, QRecall will ignore the filesystem history and perform an exhaustive search of the filesystem looking for changes. This can take a very long time. The default is to do this about once a week, so you'll occasionally see a capture take a lot longer than normal. In the log you'll see the message "Filesystem change history ignored" when it does this.

This interval can also be adjusted in the advanced settings. If you change the advanced setting "Filesystem Change History Trust Limit" to a shorter interval, it will perform this more often. If it's set to 0.0, then it will always ignore the change history and perform an exhaustive search on every capture.

You can also override this in a specific capture action. If you set the "Deep Scan" option, that specific capture will always ignore filesystem history.

In addition, you can set individual folders to ignore changes. Those changes can only be ignore for so long (typically 24 hours). This will cause QRecall to exhaustively search those specific folders. In the log you'll see the message "Deep scanning ignored folders" when that happens.

Finally, even when QRecall can skip over folders it knows haven't changed, it still has to compare the files now with those in the archive's history to determine the differences. Normally this is very quick, but if you have folders with thousands of items or a lot of layers (a 100 or more), then it will simply take some time to reconstruct the baseline picture of the folder before QRecall can start looking for what's changed.

I hope that helps explain some of the differences. Let us know if you have additional questions.

Dawn to Dusk Software is pleased to announce the (belated) start of the QRecall 3.0 beta test program.

To get started, go to the QRecall Download page.

If you already have a permanent or trial identity key, you can continue to use that. If don't have a permanent key, or your trial key has expired, click the button on the download page to obtain a free Beta Identity Key that will be valid for the entire beta test period.

The theme of QRecall 3 is "to the cloud and beyond." The user interface should be familiar, but underneath the hood is a massive rewrite of the code for improved performance, new technologies (Apple Silicon!), Swift integration and more.

The biggest new feature is Stacks, which you can start reading about in these forum posts:
About Stacks
Creating Stacks
Updating Stacks
Recovering From a Stack
Miscellaneous

As always, feedback is welcome and encouraged.

Slice Details

In the slices window, double-click on a slice to get pop-up windows with some additional details.

If there are issues with the slice, that reason will be displayed.

Partial Slice Transfers

Copying an archive layer to a stack is incremental and can be interrupted.

If you stop a transfer before it's finished, the slice that was in the process of being copied will appear as partially transferred when you return to the slices window. Restarting the same copy will pick up right where it left off.

You may also find it useful to set a time limit on your cascade action, letting it run for say no more than 9 hours at a time. Any unfinished slice transfer will resume the next time the cascade action is started.

If you manuanlly start a different copy, one that does not include the partially transferred slice, that partial slice is discarded.

Verifying stacks

You can manually verify a stack's structure and/or data. You can also create a verify stack action, that can be scheduled to run periodically.

To verify a stack manually, show the stack's configuration pane in the archive's right sidebar. To the right of the stack's name, click the action button and choose one of the Verify commands. There are three levels:

Quick: Test that the stack is reachable and all parts are present.

Structure: After performing a quick test, all metadata (file, directory, layer) records are read and compared with those in the archive to make sure they agree. (This typically requires reading about 1-2% of the stack's content.)

Full: After the structure test completes, QRecall transfers all remaining data records and makes sure they are readable and match the data in the archive, where applicable.

Note that for AWS S3 and compatible cloud object containers, you should never have to perform a full verify. (In the final version of QRecall this option might not be available for those stack types.)

Deleting Stack Slices

Just as you can delete recent layers from an archive, you can delete recent layers from a stack.

Open the archive, open the slices window, and choose the "Delete slices in" action. Pick the layers in the stack you want discarded and click the Delete button.

Manual slice copy

There are two "manual" stack actions: "Copy to" and "Copy from". These actions will let you copy any slice from the archive to the stack, or from the stack to the archive,
within the rules of slice copying (of course).

Use this to update a slice that doesn't want to (because it wouldn't save enough space, for example), or recover the details of a merged layer that hasn't been updated yet.

Using (the) Force

Hold down the option key and "Copy to" and "Copy from" become the "Force copy to" and "Force copy from" actions. These are the same as the basic copy actions, but disable all safeguards. It will let you copy any slice, regardless of whether QRecall thinks this is a good idea or not.

Please exercise discretion when using these actions.

Compression

All records copied to a stack are compressed.

Recovered slices (copied from a stack back to an archive), remain compressed. So recovered layers/archives may occuy less disk space than they did originally.

Deleting Stacks

It's easy to delete a stack. In the archive's right sidebar, show the stacks pane.

To the right of each stack name is an action menu. Click it and choose Delete Stack....

The stack container will be erased and the stack's configuration will be removed from the archive.

Disconnecting Stacks

There are several commands useful in dealing with situations where the stack's container is lost or relocated.

The disconnect stack command will forget the stack configuration from an archive, without destroying its container. In the action menu, hold down the Option and Control keys and the Delete Stack command will change to Disconnect. This command removes the stack connection from the archive, but leaves the stack container intact.

It is your reponsibility to delete, relocate, or repurpose the container. But as long as it still exists, you can use the stack container to recover the stack or reconnect the archive to the stack again at some later date.

Reconnecting Stacks

If a stack's connection with its container is broken (for example, the container has moved to a different server), you can restore the connection using the Reconnect Stack command. In the stack sidebar, hold down the Option key and choose Reconnect Stack... from the action menu.

Fill in the connection details, exactly as if you were recovering from a stack. If the container agrees with the archive, the stack's connection is restored.

Reconnect a Forgotten Stack

If the archive no longer has a connection to the stack, it can still be reconnected. With the archive window open, hold down the Option key and the New > Stack command turns into New > Reconnect Stack. Again, choose the stack's type and fill in the details of the container's location. If successful, the stack will be added back to the archive.

Stack Container Format

Currently, the format and struture of all stack containers are interchangable, if not identical. For example, if you have a stack on AWS S3 and want to relocate it to a different cloud storage servce, you can (1) disconnect the archive from the AWS stack continer, (2) manually transfer the contents of the stack container package from AWS to a third-party S3 bucket, (3) reconnect the archive to the stack, but this time providing the S3-compatible bucket credentials instead.

Stacks can be used to recover details erased in a merged layer, fix a repaired layer, or recover an entire archive.

Recovering Details and Healing Damaged Layers

In the "Updating a Stack" post there was a lot about when merged layers in an archive replace their original layers the stack.

But if those layers haven't been replaced yet, they can be used to restore those details at any point in the future.

Also, if an archive becomes damaged somehow, it may now contain repaired layers. If those layers had been previously copied to the stack, those layers can be recovered simply by replacing the repaired layer(s) with equivalent layers in the stack.

Both of these tasks are accomplished in the slices window. Open the archive, and then choose Layers > Stack Slices?. (Note that the repair action automatically opens the slices window if the archive has at least one stack and the repair detected damaged/missing data in a layer.)

Select the Recover from action.



Select the slices you want to replace in the archive. It can be layers you want to "un-merge" or repaired layers.

you can also restore layers that have been deleted from the archive.

Recovering an Archive

When the disaster is a little bigger than a repaired layer or two, the entire archive can be recovered from the stack?or at least as much of the archive that has been synchronized with the stack.

Choose File > Recover From Stack? in the QRecall application.

You begin by specifying the type and location of the stack container, exactly as you did when you created the stack. (I trust you saved all of that information somewhere safe.) But instead of prompting you for the name of a new stack container, it will ask you to select an existing stack.

You will then be prompted for the name and location of the recovered archive. An empty archive will be created. It will have the same identity and will already be connected to the stack. It will also restore all of your archive's settings.

The slices window will automatically open, and the action set to "Recover from". When you created the stack, the archive had layers and the stack was empty. This time, the archive is empty and stack has layers. Select some or all of the layers to recover and click the Recover button.

WARNING:

Archives and stacks all have a unique identity code. This is assigned when the archive and stack are created and is used to make ensure the stack belongs to the archive.

If you duplicate an archive, you create a situation where there are two archive documents with the same identity. If QRecall ever detects this, it will spontaneously reassign the identity of one of the archives.

This can be an issue when recovering an archive because, if the original archive still exists (say you just want to test out this new recovery process), QRecall may spontaneously reassign it a new identity. When this happens, one of the archives will be disconnected from the stack, and it might not be the archive you want.

If you want to test the recovery process, first rename the old archive, or make sure it's off-line during your tests. In the worse case scenario, you may have to delete one of the archives, recover from the stack again, or delete the stack and start over.

A stack is updated using the cascade action. This is the most common stack action, and one of the few you can automate. A cascade performs two tasks, as needed:

New archive layers that are not yet in the stack are appended to the stack. Each layer become a new slice.

A merged layer in the archive replaces multiple, equivalent, layers in the stack. This is referred to as "updating a slice."

To get started, you'll want to transfer the initial set of existing layers to the stack. Open the archive and choose Layers > Stack Slices from the menu.



This is the slices window. All direct interaction with your stack is performed through this window.

The action to perform is selected at the top of the window, and should default to "Cascade to". If it isn't, select the cascade action now.

To the right of the action is the destination stack. If you have more than one stack, select the stack you want to work with now.

In the middle is the list of slices (matched groups of layers) you can work with. Slices are enabled or disabled depending on what action is selected. The slices that are recommended for updating will be pre-selected automatically.

In the beginning, all you'll see are the layers in your archive. The stack side (on the right) is empty.

If you want to transfer all of your layers to the new stack, select them and click Update. And then be patient...

You can also select a different set of layers to update. Note that when you select (or deselect) a slice in the list, QRecall may select (or deselect) other slices too. There are rules about which slices can be transferred, and in what order, and the window will enforce those rules.

Automating updates

Updates are automated using the new cascade action.

Create the action and then specify the archive and stack you want to update. There are no options in the action; the slices to be transferred are chosen automatically based on those stack settings you set in the stack's configuration.

You can schedule the action like any other action. Run it twice a day or once a month. It's your choice.

About those settings....

Stack settings can temper when (or if) slices are transferred. This can reduce the amount of I/O, with the trade-off that the stack isn't as up-to-date as it could be.

Unlike an archive, which is assumed to be directly accessible and can be randomly modified, stacks are organized into clusters of data objects that are written once and never change. They may later be deleted, but that is their entire lifecycle.

This design means stacks will work efficiently with object storage services (AWS S3), filesystems that copy whole files (WebDAV), file/drive synchronization software (rsync), and cloud drives.

Another consideration is that stack containers may be expensive to access. This includes storage fees and metered I/O. It also might be expensive in terms of time (slow access). And there may be other considerations, such as data caps.

Finally, keep in mind that every update to a stack is a single, often large, transfer operation. Layers in stack are never randomly modified; they are replaced in their entirety.

Most of the settings offer ways to reduce how often slices are transferred, which reduces the amount of I/O that has to be performed to keep the stack in sync with the archive. They can also curtail how current the stack is.

Copy After [ 8] [Days]

The "Copy after" settings prohibits newly captured layers from being appended to the stack for a period of time.

As an example, let's take an archive that captures files hourly during the day. At the end of a week, there could be a hundreds of small layers. But let's say you have a rolling merge action that, after a week, merges those hourly layers in a single layer for each day. Setting a "Copy after 8 days" preference would wait for those small layers to be merged, before uploading a single (day) layer to the stack. Rather than uploading hundreds of small layers, only to replace then again in a week.

The disadvantage is that your stack will always be at least 7 days behind your archive.

Preserve for [ 2] [Months]
Update [saves at least 30%]

The next two settings reduce how often slices are updated. Once a slice has been added, these settings delay it from being replaced with a merged slice either by time or relative size.

The "Preserve for" setting prevents it from being replaced by an update for a specific period of time. Using the previous example, it would allow hourly layers to be added, but not replace them until the those layers had been merged into far more compact daily, weekly, or even monthly layers. The stack is always up-to-date, but the work needed to consolidate the layers is postponed so it's more efficient.

Similarly, the "Update saves" setting blocks a slice from being updated unless it is expected to reduce the size of the slice in the stack by a certain percentage.

Using a setting of "Update saves at least 30%," individual hourly stack layers may persist in the stack indefinitely. But once the archive has an equivalent layer that is at least 30% smaller, all of those stack layers will be replaced. Once replaced, it won't be replaced again until there's a newly merged layer that is, again, at least 30% smaller than the first replacement, and so on.

Save Forever...

Finally, note that there's an Update never option. With this setting, slices in the stack are never (automatically) replaced. This would be for archives that capture sensitive document changes which, for legal or regulatory reasons, must be maintained forever.

You can continue to merge and reuse space in the archive for new captures, but the layers and stack detail will never be reduced and will grow forever. Well, not *forever*. Years from now you may reach the limits of the archive index and have to start a new stack; but it's effectively forever.

Cascade strategies

On one extreme, if your stack container is a document on a fast local drive or server, set all of these settings to their minimum and run the cascade action regularly.

At the other extreme, you may delay the transfer of new slices to the stack for a month or more, choosing only to upload weekly layers.

In between these extremes, consider your bandwidth costs and your storage costs. If storage is expensive but I/O is cheap, set the "Update always" to keep your stack size a its minimum. If I/O is expensive or slow, set "Update saves at least 50%" or more, to minimize how often slices are replaced.

Manual Updates

These settings only apply to automatic cascade actions. These are the slices that QRecall will suggest when you open the slices window, and the set of slices the cascade action will copy automatically.

You can always open the slices window and update whatever slices you choose (within the rules, of course).