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.

I'm running the latest QRecall beta under El Capitan. It's working perfectly-- in fact I restored some files today with it. However, the status window says it hasn't been backed up for 10 days (yesterday it said 9 days).

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

I think the failure to clear the "backup problem" is likely a bug, albeit a minor one.

Changing the permissions is simple enough.

Last question: will simply trying to restore data from this archive with QRecall 2 render the archive unusable by earlier versions? Or am I safe as long as I don't actually store more data into the archive?

Well, I get further with the beta (2.0.0b1. Now clicking the "Open Archive" button gives me a file selector window.

However, when I select my existing archive, it won't open:

QRecall 2015-10-28 17:12:21 Warning Unable to open document Crucial Backup.quanta
QRecall 2015-10-28 17:12:21 path: /Volumes/Backup/Crucial Backup.quanta
QRecall 2015-10-28 17:12:21 docType: com.qrecall.repository
QRecall 2015-10-28 17:12:21 cannot create file
QRecall 2015-10-28 17:12:21 ErrDescription: Permission denied
QRecall 2015-10-28 17:12:21 flags: 0x0002
QRecall 2015-10-28 17:12:21 access: 0x01b4

I assume that since I am trying to restore from a new installation, my user ID is different. Wouldn't think I'd need write permission to open an archive, but there you go. I'm reluctant to start mucking with the permissions on the file, especially since I see it has extended permissions. What's my next step?

As it turns out, the system boots perfectly as long as I don't have any USB 3 devices plugged in. This is part and parcel of the way Apple has changed how OS X enumerates the USB ports. If I don't plug in a USB 3 device, the system works perfectly.

(I can plug in a USB 3 device after booting, but it's not recognized.)

I've sent the QRecall logs as requested.