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?

Done!

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...

Ideas?

I think that's it. The other change that Couldn't Possibly Have Affected Anything was that I finally got my Hackintosh to sleep, so it not only had to do with a new drive-- which probably meant that it had to rebuild all those icon caches-- but it wasn't running more than an hour at a time.

I'll let it thrash for a day or so and hope things speed up.

[UPDATE]

By this morning, everything had completed, the system seems much more perky, and the iconservicesagent process is shown as having taken just over 3 hours of CPU time, but it currently taking 0% processor time...

Recently, QRecall has been very sluggish to update the "QRecall Activity" window that appears when backup operations are in progress.

Previously, the seconds on the timer would tick by regularly; the file names listed after "Capturing" would whiz by dozens of times per second, and the numbers for the amount captured, MB/min, and so forth would update frequently.

This was the case when I was running High Sierra 10.13.2, backing up from one SATA SSD to an archive on another SATA SSD.

A few days ago I switched my main drive from a SATA SSD to a PCI-E (m.2) SSD. That seems to be when I first noticed the problem although I can't imagine why this would matter.

Tonight, I started a backup to a brand new, empty archive. It's been a while since I've done this but I'd expect performance to be in the gigabytes per minute range since no comparisons with older versions would be required. The backup has been running for 20 minutes now, with constant disk activity light indication, and the Activity window has been stuck on "950.5MB, 12% duplicate" and "26.4MB/min" since the first minute. Looking at the archive in the Finder shows a size of 1.15GB, last updated 20 minutes prior (although I don't know how often this file info is updated). The backup timer, far from updating consistently once per second, stays the same for 30-120 seconds at a time.

File names shown after "Capturing" stay up for minutes at a time. And these are not multi-gigabyte files.

The source volume is APFS, and the archive volume is HFS, but that was the case previously. Right now the progress indicator bar has not a single pixel of blue in it. Honestly I'm not sure if the backup is actually, you know, backing up.

Any suggestions or explanations would be appreciated.

[UPDATE]

At 49 minutes in, the window's updating much more frequently now. The file names change and the backup timer ticks pretty regularly. However, only about 10GB has been backup up so far and the current backup rate is about 20MB/minute. At this pace it will take, let's see, about 70 hours for a full backup of my 850GB of data...

[UPDATE]

The proximate problem appears to be that the "iconservicesagent" process is hogging a tremendous amount of CPU time, up past 100%. Sigh. Time for more investigation...

That does in fact seem to have been the problem. It's disappointing that it still exists in High Sierra...

I'm trying to run QRecall on a test system running the High Sierra beta. No matter which of the temporary identity keys I use, QRecall won't capture, saying that I need a valid identity key for capture operations. However, QRecall preferences also notes that I have a valid, temporary identity key.

Does QRecall simply not work with APFS or High Sierra (yet) or am I doing something wrong?

Based on this information, I exercised by Google-Fu and found this handy command:

sudo mdfind "com_apple_backup_excludeItem = 'com.apple.backupd'"

The first two items on the list were the VM files that aren't getting backed up. I see that Parallels has a setting for VMs labeled "Do not back up with Time Machine", and turning that off removes the files from the list. So that was the problem.

In Documents->Parallels, I have three VM files: one each for Windows XP, Windows 7, and Windows 10.

I just found out the latter two are not being backed up. I found this out because I was checking my Time Machine backup (I run QRecall daily and Time Machine weekly) and it's not backing them up, either.

By "not backing up", I mean that the Win 7 and Win 10 VM files don't appear in either the Time Machine or QRecall interface when browsing the backups. In the case of Time Machine, I can look in the folder hierarchy of the backup and they're not there either.

Neither program has any exclusions or conditions set that would preclude the backup of these files, and looking at the permissions on the files in Terminal, all three VMs have the same permissions. My current guess is that the problem might be related to the extended attributes for each file. Suggestions?

James Bucanek wrote:

David Ramsey wrote:There was an interrupted backup 10 days ago. But every backup since then has gone perfectly (I checked the log file).

I think I've discovered where the confusion lies. You have (or had) two archives. You were capturing to the older archive, but then you deleted all of the actions for that archive, created a new archive (with a different name), and created new actions for the new archive. The new archive is working just fine, but the old archive is no longer being captured to.

That's the reason it's status is giving you that warning.

Now, if the old archive is really dead and/or gone, then you can remove it from the status window by right/control+clicking on its status and choosing the Forget command. The status window will stop tracking that archive (unless you perform another action on it, then it will start monitoring it again).

D'oh! QRecall is clearly smarter than I am. I could make the weak argument that it should stop doing this, taking the position that deleting the actions implicitly means I don't want to track it any more. But that would be pretty weak.