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?

Curious indeed!

I could ask you a million questions, but I think it would be simpler if you would send a diagnostic report (Help > Send Report) from that computer. That will allow me to investigate/eliminate a whole bunch of possibilities.

Done!

David,

Well this is mighty peculiar. You're running a regular scheduler, so when you log out and back in again, the schedule gets shut down and restarted.

When it starts up again it thinks the previous actions didn't run on time and starts them again, even though the log clearly shows that the scheduler started the action and saw that it finished.

It's possible the scheduler is having problems remembering what has run and what hasn't, so let's try this: in your ~/Library/Preferences folder, locate the com.qrecall.scheduler.plist file and trash it (along with any semaphore files that start with com.qrecall.scheduler.plist.). Restart your system and see what happens.

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?

David Ramsey wrote:Can I delete these?

Yes. There's ever only one active lock file. The rest are orphans.

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.

David Ramsey wrote:Deleting the files has cured the "runs multiple times per day at odd times" problem.

However, I think I am now noticing another problem.

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

Performance problems.

During a QRecall capture there are about a thousand different things going on, which means there's a million ways it could be getting slowed down.

While the performance of the source volume could be issue, it's the least likely. One issue could be that QRecall can't use the volume change history for some reason, which will force it to perform an exhaustive scan of the directory structure. But for the most part it just reads directories and files, and unless there's something wrong with the volume (and it doesn't sound like it), this shouldn't be an issue.

It's much more likely that the size of the archive or the performance of the volume it is on will have more of an impact. Due to the nature of QRecall's data de-duplication logic, the amount of work required to add new data to an archive increases exponentially as the size of the archive grows. So if it takes 1 second to add X amount of data to a 100GB archive, it might take 8 seconds to insert that same amount of data into a 400GB archive.

Other factors include the archive volume's speed, bus latency, how full the volume is, and how fragmented the volume has become.

Now, that's not to say nothing is wrong, but it's really hard to tell from this distance given the number of things that could be affecting performance. If you like, send a series of diagnostic reports while one of these long-running captures are executing. The Send Report command samples all running QRecall processes and include that in the uploaded report. That could provide some clues as to what's eating up its time.

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!

Thank you for your help Mr.David... I had this same problem in my system.. Now i have solved that issue by reading your suggestions.. Thank you