QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
Messages posted by: David Ramsey
Forum Index » Profile for David Ramsey » Messages posted by David Ramsey
Author Message
Bingo, that was it! The erroneous inclusion of the CCC Backup volume was what was killing the command line restore thing. I deleted it from the archive and now have a shell script set up to do it. Thanks for your patience!
James Bucanek wrote:It isn't obvious what's wrong, so go through each level one at a time to see where the break is:

qrecall ls '/Volumes/QBackup/Mac Pro Backup'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*'
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*' <-- Fails here.

I admit I'm confused about the syntax. For example, I'd expect the second line, when executed, to list the upper level directory of the volume "Primary", since that's what's backed up in the "Mac Pro Backup" archive.

Instead I get:

[Caprica:~] dramsey% qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*'
2 items
Type Access Owner Group Size Modified Captured Name
volume 1023999787008 Feb 9 13:54 CCC Backup
volume rwxr-xr-x root (0) wheel (0) 999995129856 Feb 9 13:34 Feb 12 18:04 Primary

CCC Backup is the volume dedicated to CCC. Primary is the volume I'm backing up with QRecall.

I'm surprised to see "Frankenstein"; that was the name of my Hackintosh. This backup is running on a Mac Pro 6,1 called "Computronium". But when I look at the backup in the QRecall app I can see the hierarchy is "Mac Pro Backup->Frankenstein->Computronium..."
James Bucanek wrote:
What happens if you try this:
qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

This happens:

* ls process failed: folder not found in selected layers

James Bucanek wrote:
You can try shorter versions of this (i.e. qrecall ls '/Volumes/QBackup/Mac Pro Backup' '*:*/Users') to try and narrow down where the missing piece is.

It's a mystery to me. The folder's there in the layer. Here's a screen shot:

I think I'm missing something:

[Caprica:~] dramsey% qrecall restore '/Volumes/QBackup/Mac Pro Backup' '*:*/Users/dramsey/Library/Preferences/QRecall/Actions'

Results in:

* restore process failed: folder not found in selected layers

The Actions folder and its contents are there; I can restore them manually. I've tried adding ".quanta" to the end of "Mac Pro Backup", and I've tried escaping the spaces with \ (removing the single quotes), but obviously I'm overlooking something...
Although...you know what would be cool? Some way to set up a macro or quick action or something along the lines of:

"Immediately restore [file(s)/folder] from most recent backup"

Something I could easily invoke to restore data without having to manually dig through a complex directory hierarchy...

Yes, I am indeed that lazy.
That would work. It has the minor drawback of needing to recreate the actions if I ever restore from the backup volume, but that's not too hard...
One facet of my multi-tiered backup strategy is to keep a separate, bootable copy of my primary volume. QRecall is set to back up my primary volume to a dedicated backup drive, but I have a secondary dedicated drive that I use as a destination for Carbon Copy Cloner.

My primary driver's volume name is "Primary" and QRecall is configured to run daily backups of this volume to the archive "Macintosh Pro" on a volume called "QBackup".

My CCC destination is a separate volume called "CCC Backup".

So here's the problem: if I boot from CCC Backup, the instance of QRecall on that volume immediately starts backing up that volume to "Macintosh Pro" on "QBackup". If I look in the Actions window, the backup action is labelled "Capture volume CCC Backup" instead of "Capture volume primary".

This of course leads to problems with the backup archive since it starts layering information from a different volume...

It seems as though QRecall is saving the actions as something like "Capture [boot volume]" rather than "Capture [volume name]". I guess I can understand why: you wouldn't want renaming the volume to break backup scripts.

But is there some way I can stop QRecall from trying to run an immediate backup of CCC Backup every time I boot from it? Which isn't often, but still...
I did try closing the "QRecall Monitor" application to prevent this from happening; however, closing it is impossible: that is, you can close it, but it just pops right back up.

It's possible the Monitor apps is just a monitor. However, if it's involved in actually starting scheduled actions, it sure would be nice to close it and have it stay closed.
I had occasion today to restore my entire Mac OS user folder from a QRecall backup. As it happens I'm back from a trip and the computer's been turned off for a while, thus, many backup/verify/compress tasks have queued up.

Restoring my user folder will take a while, and the scheduled backup task tried to trigger while the restore was going on. The message that popped up said something along the line of a scheduled action needs the currently open archive, which must be closed for the action to proceed. If I didn't do anything the archive would be automatically closed in 60 seconds or so.

I don't know if this would have actually happened or not, but in any case I cancelled all the pending actions.

It seems to me that scheduled tasks should never interrupt a currently running task. If the scheduled actions had actually stopped the restore process, the backup would have then backed up a user folder that was only partially correct.
Well, I ran Disk Utility (which I discovered can now repair your boot drive, yay!) and it reported no problems, after going through a number of checks I'd never seen before, but thus is the brave new world of NVME and APFS, I guess.

It reported no problems. But this evening QRecall ran its backup in less than 4 minutes.

As I look over at my Apple //e system, I fondly recall when I knew what EVERY F**KING BIT IN MY COMPUTER DID. Ah well!
Deleting the files has cured the "runs multiple times per day at odd times" problem.

However, I think I am now noticing another problem.

I normally don't pay much attention to my backups' running. My all-SSD system means that backing up my boot drive doesn't slow Mac OS to a crawl the way it can on a spinning hard drive.

HOWEVER...I recall that in years past that most daily backups ran in mere minutes. My 6:00PM backups could be finished before 6:05.

Now, it seems that every backup takes a LONG time. For example, today's backup has been running for 39 minutes as I type this and has copied a mere 1.28GB of data (didn't do much today).

It's possible my memory is wrong, and that this is simply how much time it takes to scan a 1TB APFS NvME SSD (say that three times fast). I do know that in High Sierra, Apple has introduced some sort of TRIM problem with NvME SSDs that results in very long initial boot times, but I haven't seen any other performance problems other than with QRecall. If it is indeed a problem and not normal operation.
I have deleted the com.qrecall.scheduler.* files-- there were two, the com.qrecall.scheduler.plist and an associated lockfile. A backup is running now and I'll let you know if I see any more extraneous runs.

I also noticed a bunch of other files with years-old dates:

Many com.qrecall.monitor.plist.<garbage> files dating from 2012 through 2017
A couple of com.qrecall.client.plist files from 2012

Can I delete these?
This has started happening recently: backup operations running multiple times per day, at odd times, although they're only scheduled to run at 6:00PM, once each day.

As you can see, this is an ordinary schedule produced automatically by QRecall's assistant.

But look at the log file:

The backup ran at 6:00PM on February 2.
Then it ran again at 7:03PM.
Then it ran again this morning, February 3, at 10:29PM...

Forum Index » Profile for David Ramsey » Messages posted by David Ramsey
Go to:   
Powered by JForum 2.1.8 © JForum Team