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.

See the Actions section in the 2.1(24) beta release notes.

The details about the action that will/did ran is provided as environment variables.

Post here if you have questions.

Ralph,

The Finder (and probably the Open/Save UI) all know about "ubiquitous" (iCloud) documents and present them as if they were in this special place called the iCloud Drive. The same is true of app-specific documents, like your Keynote documents. In reality, they all live in a special hierarchy inside the ~/Library/Mobile Documents folder, which we (being mere users) are not to concern ourselves with.

The rules for when and why a document is stored on your local system or only as placeholder is a complex mix of criteria. Obviously, if you open the document macOS will immediately download a copy. After that, it depend on how big the document is, how fast your network connection is, how often you access that document, how much free space is on your startup volume, and so on.

Bruce Giles wrote:Is there a way to tell QRecall to ignore actions while powered off, and just resume at the next scheduled interval after powerup?

Not yet, but this is still on the short-list for 2.1 (and that short list is getting pretty short).

Ralph,

Thank you for being so patient.

I had a chance to look into this today and I think I understand what's going on. Apple is playing some clever shell game in the Mobile Documents folder, just not the game I thought they were playing.

I have "successfully" backed several iCloud Drive folders and documents here. And by "successfully", I mean that QRecall faithfully captured the iCloud Drive files store on my local "Mobile Documents" folder.

However, this might not be what you expect. Documents in the iCloud Drive folder can be locally cached copy or merely placeholders for a document you have in the cloud. In the Finder, a placeholder appears with a little "cloud" icon next to it, which means it isn't physically stored on your hard drive at the moment.

On you local drive, these "cloud" documents are stored as tiny invisible .icloud documents containing bookmark information about the original.

And sure enough, QRecall captured all of those placeholder files. But, since the files are normally invisible, they do not appear in the QRecall browser unless you turn on "Show Invisible Items". (The Finder obviously knows about these special placeholder finds and displays them as regular files, even though they are invisible.)

If you capture the files, open the archive, and set "Show Invisible Items" you'll see all of the cloud documents that QRecall captured. But, obviously, these aren't the actual documents, just the placeholders, since QRecall doesn't download the shared document from the Internet.

For iCloud documents that are currently cached on your system?the ones that appear without the little "cloud" icon?those are just regular documents and get captured just fine.

Good new:

It turned out the menu bar icons for the activity monitor just needed a special "template image" flag set, and it wasn't set.

Bad news:

"Template" images are always monochrome, so the colored indicator to show that there's a warning or problem in the status window now draws just a grey dot, indistinguishable from the "busy" dot.

Update: I decided to add some code to detect the "dark mode" setting and draw a colored icon for regular menubar users and the monochrome version for dark mode users.

Let me know your opinion in the next beta release.

Charles Robinson wrote:I'm sure maintaining the app keeps you quite busy

...
That's an understatement.

I didn't have dark mode menubar on my to do list, but it shouldn't be very hard. Since 2.1 is all about the UI updates, I'll see if I can squeeze that into this release.

Alexandre,

That was indeed the problem. The latest report you sent shows the restore command couldn't get the info for the Boxcryptor volume.

Glad to hear the patch fixed it.

Alexandre,

Thank you for the diagnostic report.

Yes, it's a bug. QRecall is crashing when trying obtain the list of volumes on your system. For some unknown reason, one or more of the browsable volumes on your system returns an error when QRecall asks for the volume's specifics. And that's where it gets in trouble; it tries to log the volume details and crashes.

I've (hopefully) modified the code so it can log the failure without crashing. (I have no way of testing this since this situation has never arisen here and you're the first user to report it.) I'll email you link to a patched version of QRecall that you can try.

Please send a follow-up diagnostic report after you try this so I can see the success (or failure) of the new version.

Alexandre,

If you haven't already, please sent a diagnostic report (in the QRecall application go to Help > Send Report). If the process crashed, there should be a crash log that we can look at.

If the process didn't crash, and it simply lost its connection with the action, that should be in the log too.