It appears that when switching from a temp key to a purchased key, QRecall shuffles through the entire archive due to the change in ownership. This is taking a very long time, and in particular, for one of my archives, the estimated time to get through this conversion of ownership based on current progress appears to be 200 hours. It only took about 24 hours to make the original backup. Is there a way to trash the entire archive contents and then recapture it? I suppose that I can delete the archive, but it seems like there should be a simple way to just delete the contents.

Restarting the computer took care of it.

Overall, QRecall is working well for my backups. Its a little slower than I'd like, but it gets through 20 GB of changes and additions in about 3-4 hrs which is tolerable, and my impression is that the integrity of a QR archive is unbeatable, so seems worth the length of time for the backup to occur.

Check out the attached image. The one with dark gray background is non-existent in the Actions window. I've tried restarting QR Monitor several times. Restarting got rid of it once, but then it came back.

James Bucanek wrote:

maxbraketorque wrote:For the second question, there are no orphaned actions listed in the Actions window.

Oh, I think you might be referring to the Status window, not the actions or activity window.

The Status window shows the state of all known, and previously known, archives. To make QRecall forget about the status of an archive, click on the action (gear) button, or Right/Control-click anywhere in that pane, then choose Forget.

Definitely was Window->Actions that I reviewed. All the actions listed are associated with existing archives. However, QR Monitor continues to show an action that is not present in the QR app Window->Actions window.

ok. I'll consider the deferred de-duplication. Thanks much.

James Bucanek wrote:See QRecall Help > Guide > Troubleshooting > Problems > Can't Open Archive

... and let us know if that helps.

None of the listed scenarios seem to fit. I ran lsof, and there were no instances of this archive be open by MacOS. I guess that doesn't rule out the server locking the file, but as I said, I was able to open the archive in QR. I guess I'll reboot the server as well as the mac after QR completes the backup of another archive.

James Bucanek wrote:

maxbraketorque wrote:1) I decided to break out each of my four external drives into their own automated QR archive using the QR Assistant. If I want all four archive backups to run back-to-back, can I set their action times to all be say 15 minutes apart, e.g., start actions for backup1 at 8pm, actions for backup2 at 8:10 pm, etc? Will sets of actions for each archive run serially with sets of actions from other archives, or will each set of actions run in parallel if the prior set of actions for the archive before it haven't finished?

Overlapping actions that modify an archive will run sequentially (only one action can be modifying an archive at a time). Overlapping actions that just read an archive (recall, verify) and actions on other archives will all run concurrently.

If that introduces performance or resource issues there are two settings in the QRecall Scheduler preferences that can help:

Maximum concurrent actions and Maximum actions per volume.

If you set Maximum concurrent actions to 1, only one scheduled action will run at a time.

(*)These have no effect on commands initiated from the UI or the command-line.

2) When I was first experimenting with using QR, I created a few archives that I subsequently manually renamed and then subsequently deleted. Some actions for these deleted archives seem to be persisting in the QR monitor window. How do I find and remove these actions?

Open the Window > Actions window and find the actions that no longer have archives. Select them. Delete them.

Thanks on the answer to the first question.

For the second question, there are no orphaned actions listed in the Actions window.

My stationary computer is working its way through the first round of daily automated capture updates. Everything went quickly for three of incremental backups, but for one backup that contains one disk where I moved around ~80 GB of large files (maybe 200 files in total) without any file name changes, QR is really crawling. Based on the current progress, its going to take ~8 hrs for the incremental backup to run. Rather fascinating that its so slow to update the backup for files moved around on the disk. This is about 1/10th the speed during the initial backup of the disk.

I've got an archive that won't open by a capture action. The log says:

Action 2020-04-09 10:17:35 ------- Capture to SP1000QR.quanta
Action 2020-04-09 10:17:35 archive: /Volumes/QRecallBackups/SP1000QR.quanta
Action 2020-04-09 10:17:35 Minutia Waiting for permission to open archive
Action 2020-04-09 10:17:35 Archive is locked
Action 2020-04-09 10:17:55 Archive in use

However, as far as I can tell, the archive is not locked or in use. I can open it in QR. There were one or two achives that I originally created as a "capture" event, and then subsequently converted into a routine backup by re-running the QR Capture Assistant using the automated capture strategy. Perhaps this is the source of the issue?

1) I decided to break out each of my four external drives into their own automated QR archive using the QR Assistant. If I want all four archive backups to run back-to-back, can I set their action times to all be say 15 minutes apart, e.g., start actions for backup1 at 8pm, actions for backup2 at 8:10 pm, etc? Will sets of actions for each archive run serially with sets of actions from other archives, or will each set of actions run in parallel if the prior set of actions for the archive before it haven't finished?

2) When I was first experimenting with using QR, I created a few archives that I subsequently manually renamed and then subsequently deleted. Some actions for these deleted archives seem to be persisting in the QR monitor window. How do I find and remove these actions?

After backing up ~4 TB of data, I'm seeing an average speed during these first capture operations of ~100 GB/hr. Not bad I guess. I think Time Machine would be faster for these initial backups, but for TM I have no option to break out my drives to their own backups, TM is very slow on subsequent incremental backups especially as the archive grows, and it appears that QR backups are much more resistant to corruption which is important for backups over a network.

ok. Thanks much for the explanation. Transfer speeds have drifted up in the last few hours.

I'm in the process of backing up all the external drives attached to my stationary Mac. Three of the four drives are connected to the Mac via the somewhat outdated FW800 protocol. The QR archives are being hosted on a 4-drive RAID10 NAS with Ironwolf drives. Both machines are networked at 2.5 gbe through a multigigabit switch. I've clocked large file reads from the NAS at 250 MB/s and large file writes to the NAS at 150 MB/s.

I'm currently backing up one of the FW800 drives that consists primarily of files that are >500 MB in size. When the backup operation was started, I was seeing write speeds to the NAS of 80-90 MB/s which is right at the limit of the FW800 protocol, but now at 5+ hours into the backup, write speeds have slowed to 25-35 MB/s. Is there some behavior in QR that results in periods of reduced write speed?

ok, sounds like as long as QR can correctly restore a TM backup, its better to backup the .backupdb file directly rather than dump the .backupdb into an HFS+ dmg. If you're not sure whether QR can correctly restore the .backupdb, then perhaps I'll restore the TM backup to a spare HDD and extract the files that I need.

James Bucanek wrote:

maxbraketorque wrote:Just wondering if its feasible to rotate usage of the CPU cores to more evenly distribute heat production across the cores and keep max core temperatures down. My MacBookPro is getting fairly toasty during the initial backups of my external drives. QR seems to be favoring Core 1 and Core 2 with their temperatures consistently running in the mid-80C range while Core 3/4 are running in the mid-70C range.

What tasks get assigned to what CPU is completely outside QRecall's control. That's entirely the job of the Darwin kernel and I know of no way to influence it.

Also note that modern, mobile, CPUs often have one core that's more powerful, with auxiliary cores that are more efficient. So intensive tasks vs. light/periodic tasks are going to favor one core, or one type of core, over others.

ok. Thanks. Perhaps I'll point a clip-on fan at the computer.