QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: James Bucanek
Forum Index » Profile for James Bucanek » Messages posted by James Bucanek
Author Message

The "Lifeboat" volume is just a temporary volume used to as a springboard for recovering your system. You use recovery mode to create the temporary volume and install a bootable OS. This OS is not the OS you will eventually install or recover, and doesn't need to be the same version.

The volume you eventually recover will be some other volume, either your original startup volume, or a new volume that you create and restore to.

If you don't see an option to reformat the entire drive, repartition, or add a new volume, then you need to switch Disk Utility's view mode to "Show All Devices." In the simpler "Show Only Volumes" mode it only lists logical volumes that have already been created. The "Show All Devices" mode shows the logical tree of hardware, partitions, containers, and logical volumes.

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.

    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.


    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.


    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.

    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

    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.


    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.


    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.
    Forum Index » Profile for James Bucanek » Messages posted by James Bucanek
    Go to:   
    Powered by JForum 2.1.8 © JForum Team