On the face of it, that should have worked (assuming that Drobo02 was mounted and writable). The only thing that comes to mind is there might be something odd about duplicating/binding file descriptors on the Drobo02 when running as root, in single user mode, or from the recovery partition.

It's a bit late now, but you could try:

.../qrecall restore osx.temp ... --logfile stderr ... 2>>/Volumes/Drobo02/log/qrecall.logfile

That would let the shell create the file descriptor and then pass that the helper, rather than having the helper create its own.

Jeffrey Fort wrote:Just purchased. First Capture is underway.

Congratulations!

How do I make sure the Capture, to a new external HD, is encrypted?

Short answer: You encrypt an archive by installing an encryption key. Open the archive and choose Archive > Encryption > Install Encryption Key.

Long answer: See Help > QRecall Help > Guide > Advanced > Encryption.

Also, do I schedule period Captures or does in just happen automatically?

You'll want to schedule captures, merges, and other periodic maintenance. This is done by creating actions.

The easiest way to get started is to use the Capture Assistent. Choose Help > Capture Assistent and tell it that you want to create a backup strategy. Choose the archive you've already created and answer the rest of the questions.

The assistant will create a set of actions to automate QRecall. Review these actions to understand what's been set up. Later you can edit them to refine them, delete them if you don't like them, or create new ones that better fit your needs. If you really don't like the actions that were created, just delete them all and run the assistent again.

Norbert Karls wrote:I'm aware that after booting into internet recovery using ??R I can use a shell to dissolve the fusion drive, format my SSD as HFS+, mount my backup box and use QRecall's command line utility conveniently waiting there with

qrecall restore osx.longterm.quanta ':OSX' --tovolume /Volumes/SSD

to pull everything from the archive to the newly created volume without having to install a temporary OS first.

While that's technically true, it's a lot of work. If you have an external, bootable, drive it's much easier to install macOS & QRecall there first, then use that to reformat, reconfigure, partition, install, and restore your new internal drive(s). I keep a 16Gb thumb drive around just for that purpose.

You may have purposefully glossed over some of the command-line details details, but if you didn't be aware that running the qrecall tool from a recovery partition is a little more complicated than that. You can refer to the Help > Guide > Troubleshooting > Restore OS X section for all of the gory details. In fact, I'd suggest having this page loaded on a tablet or smart phone before you begin.

But how would I go about restoring everything except that one big folder? Is there a hidden switch or option to achieve this? The man page doesn't say so, but I hope that's just because it tries not to drown people in text.

Sorry, there is no such option. Your original idea of first duplicating the archive an then deleting the one big document folder will work. If you still had your original drive, I would have suggested taking a final capture, deleting the one massive folder, then taking one more capture. You could have then restored your SSD from the last layer, then rolled back one layer to recall your documents folder to some other location.

And just for there record, the whole purpose of a man page is to drown users in text.

That seems an awful lot of i/o for a fairly intuitive transaction request, though.

You say "intuitive," but I say "this is there first time anyone has asked for this."

I'll add it to the wish list. It might not be that difficult to implement. There's already a to-do item to add an exclusion mechanism to the restore command. This is to solve an unusual problem where you've captured the volume that contains the archive itself. During the restore, QRecall will attempt to delete the archive (since the archive always excludes itself from any capture). It's actually the opposite problem (not deleting an item that wasn't captured), but the mechanics of not recalling an item that was captures would be, more or less, the same.

Mike,

You want to "shade" a layer or two. What you're seeing in the browser is the composite results?the most recent version?of all of the files captured in those four layers.

To play time machine, you shade the most recent layers. The browser then presents the view of your files before those layers were captured, allowing you to recall earlier versions of those items.

To move the bottom shade, the one used to hide the most recent layers, either click and drag the bottom shade or hold down the Control key and press the Up (or Down) Arrow.

See QRecall Help > Guide Layers > Layer Shades (for how to manipulate the layer shades) and Understanding Layers for an overview of the layers concept.

Let us know if you have more questions.

Mike,

Yes, that's one way of doing it. There are three popular methods for handing a source volume that isn't always connected:

Add a Hold if No Capture Items condition (the one you suggested)

This condition will allow an action to start at a scheduled time, but then hold the action until the source volume is connected. Once connected, it will start immediately.

Add an Ignore if No Capture Items condition

Similar to the hold version, this condition just skips the action if the source volume isn't mounted. When the scheduled time arrives, the volume will be captured if it's connected, and ignored if not.

Use a Capture Items Volume Connects schedule

This event schedule starts the action whenever the source volume connects. Use this schedule for volumes that are connected very infrequently or unpredicatably. The ignore and repeat property can control how frequently this action runs.

See QRecall > Help > Guide > Automation > Schedules for more details.

And almost before this page reloads, Sierra is here.

QRecall 2.0.4 has been released. Update at will.

And with it the "macOS" era returns?for those of you old enough to remember the first MacOS era.

As Manfred mentioned, we have a version of QRecall that works with Sierra.

I'm pretty happy with the Sierra compatibility at this point. We've preformed several full-volume OS X restores and so on with no issues.

There were just a couple of other bugs and minor improvements that we'd like to get included in 2.0.4, and that's the only reason it hasn't been released yet. But we're ready to pull the trigger on 2.0.4 at anytime.

Hello Paul,

The next beta for QRecall is still several months off, but here's what's going on.

I've spent the better part of this summer replacing the aging mach ports inter-process communications (IPC) infrastructure with XPC, Apple's modern IPC service. I'm also rewriting the whole of QRecall to use automatic reference counting (i.e. modern memory management). These change are the last of the major rewrites to bring QRecall up-to-date with the latest core technologies and should provide stability and improved performance. I hope to have this all finished and tested by the end of September.

After that, there's a short list of new features:

A UI facelift. This is a work-in-progress, so how radical this will be has yet to be determined.

A new "Stacks" feature, inspired by work done by Bryan Derman, that lets you incrementally offload a copy of your archive to remote storage. Initially this will be targeted at optical media, but I hope to evolve it into a multi-fasciated feature that supports a variety of file transfer protocols (SFTP, WebDAV, ...) as well as cloud storage services like iCloud, DropBox, Amazon S3, BackBlaze, and so on.

I want to implement a long-overdue feature that allows you to run a script before an action starts and/or after it finishes. A script could mount a specialty filesystem, wake up a server, export a database, suspend a daemon, and so on.

Kurt Liebezeit wrote:So, I'm stuck... I thought I pasted my valid identity key in the place where it goes, and the Preferences say it is valid and permanent, but it isn't working. What have I done wrong?

Kurt,

You've done nothing wrong. This is a (*cough*) quirk (*cough*) of OS X's preferences system, which has been covered in other threads.

Simple solution: restart your system and the capture should run OK.

Ralph Strauch wrote:Today I decided to try wifi again and again got the error, so I followed up immediately with a backup over firewire. I then noticed that the earlier wifi backup had apparently completed, and added a layer to the archive even as it was complaining about a "problem closing file." (I've also noticed this occasionally in the past.)

There are two places the "problem closing file" can occur. First, if there's a permanent failure of some kind (say the network or drive gets disconnected) and QRecall can't close its open files while trying to clean up and terminate.

The other, which is what happened here, can occur when everything goes the way it should, but just as QRecall is finishing up and closing the completed files, the OS complains that something went wrong. This is what appears to have happened in this case. All of the data was successfully written, but when QRecall went to close the very last file, the network hung for 8 minutes and then reported that the file couldn't be closed (POSIX error 60, "timeout"). But in reality, all of the data was probably written, which is why the archive was intact and you had a complete layer. I don't have any good theories as to why this might happen. It's possible that the server simply had a lot of unwritten data to write, and the network operation timed out before the server had finished writing all of its buffered data. But that would require either tens of GB of unwritten data on a really, really, slow drive, or else the server was frightfully busy doing other things at the same time.

I've been using qrecall since 2007 and this problem only cropped up with v2, so I'm guessing that something in v2 changed what happens with the wifi connection when the target computer is asleep.

This is much more likely due to the change in filesystem API. QRecall 1.x uses the legacy Carbon API while QRecall 2.x uses the BSD (UNIX) API. Each API has its own idiosyncrasies and error handling, so there are bound to be some behavioral differences between the two.

Paul Mann wrote:Can I get QRecall to issue a shell command where I could add the WOL request via a command line tool perhaps?

That feature is planned for a future version.

Paul Mann wrote:Is this possible to set a condition of sending a magic packet to a mac address, then wait, then look for the destination archive?

Not in this version.

QRecall really doesn't work at the server level. It works at the filesystem level. If your server supports being woken up when a client connects to a volume or in response to a bookmark mount request, this it should "just work."

Since most dedicated file servers run all of the time, I'm going to assume that your server is another Mac that's set to go to sleep periodically. The simplest solution for that is to use the Energy Saver control panel and program it wake up a minute or two before your regularly scheduled actions.

The Energy Saver control panel only presents a UI for setting a single wake event, but OS X can actually manage an arbitrary number of scheduled power management requests. If you need more than one wake time you can do this the propeller-beanie way using the pmset command-line tool, or look for a third-party app the does the same thing.

Kurt Liebezeit wrote:I'm expecting that it will store a good-sized ~10GB chunk of new unique data into the archive as a result of the operating system change, but otherwise the applications and user data should just be deduplicated, right?

Correct.

If you can think of any subtleties that I might want to address before the migration, I would be grateful to hear them.

What's going to happen is that a new set of volumes will appear in your archive. QRecall will most certainly detect that the volumes you are now capturing are not the one you were capturing. Everything will be captured anew (with data de-duplication), but you'll still get a new layer with every file appearing to be a new version, with no history.

Your old volumes are still in the archive, and will no longer be appended to. When browsing your files, you may have to navigate between volumes if the item you're looking for is before, or after, the transition.

If this is acceptable, you don't have to do anything. If, on the other hand, you'd prefer to have a single history for all of your documents, then you'll want to combine the new volume with the old one.

You're most likely to want this with your user files partition. Navigate to the "owner" level of the archive. Select both the new user partition volume and the old user partition volume, and then choose Archive > Combine Items.... The items in the old volume will be migrated to the new volume, and will appear in the history that precedes the new volume. The old volume will then be deleted.

Mike M wrote:Does that sound okay?

Sounds perfect!

A few tidbits of advanced wisdom:

- The "couple of directories" can be part of the same capture action. A capture action can capture any number of source items (files, folders, or volumes).

- If the folders you're are capturing are broad (i.e. ~/Document & ~/Pictures) then an hourly schedule is the most efficient approach.

But if your folder is very targeted (~/Documents/Projects/Hot) then consider the "When source items change" event schedule. QRecall will monitor that folder for changes and immediately start a capture only when it does. It's more timely than waiting for the hourly capture, and it can be more efficient because the action only runs when there's something to capture. You just don't want this kind of schedule on a folder that changes all the time (like your home folder, which change every few minutes).

Mike M wrote:I have another situation. I frequently download large data files into the Downloads directory, and within a week, delete them. I have no need to save them longer than that. But if they are captured, then they may stick around in the archive for a long time, depending on how frequently I merge layers.

I wanted to see if there's a way to merge only portions of layers, say only the files in the Downloads directory. I don't see such a thing in the docs. Of course, I bet that such an action doesn't make logical sense--it might violate some consistency rule in the archive. Just guessing.

You're correct: it's not possible to selectively merge individual folders. It really violates the logical definition of a layer.

So that leaves the delete option. I see that I can manually delete some of these files. Is there a way to create a Delete action that would run on a schedule and delete stuff in Downloads?

It's possible to do this with the command-line tool. You could script the qrecall tool to periodically delete your Downloads folder from your archive, say once a week.

But honestly, if you don't want to keep your downloads in the archive consider just excluding them from the capture. You can do this in the archive's settings or by setting the "Exclude Contents" capture preference on the Downloads folder.

Files that you only want to keep a backup of for a few days are not worth capturing in the first place. Particularly since these are transient files which, presumably, are available to download again should you lose them for some reason.