I have Firefox set in HTTPS-Only mode. Sadly https://qrecall.com/ leads me to macOS Server. I suspect that that site could be a scam. By the way an entry in November 22 at MacUpdate mentions this problem. Can it be fixed somehow please?

-- Charles WJ

Running QRecall b20, I tried to run a back-up Action this morning after my attempts to run one to a NAS when logged out, failed. The Action refused to run because it was seeing an 'invalid identity key'. When I looked at Preferences > Identity Key, the Key Status reported 'Valid permanent key'. I tried re-entering my key only to be warned that doing so would change ownership of the archive. Odd?

There were other oddities in the Log so I have sent a full report to James. The good news part of this is that a while later QREcall did run the back-up Action. Clearly it had overcome the identity crisis.

Some years ago James Bucanek wrote:

For QRecall to mount a network volume while unattended, it requires two things: (1) the user name and password for the volume must be stored on your keychain, and (2) your keychain must be open.

and

(3) The action does not use the "Hold While No Archive" or "Ignore if No Archive" schedule conditions.

Operating Systems have moved on since this thread started and perhaps the conditions have changed, so I'm resuscitating the question.

I'm trying to use ControlPlace (a freebie available at http://www.controlplaneapp.com/) to handle the mounting of a NAS drive. It uses Rules to trigger Actions. The Rule that I've tried is to name the application which will trigger the drive mount. So far I've tried QRecallMonitor and then QRecallScheduler. Neither appears to work; I say 'appears' because I'm getting a 'NetAuthSysAgent wants to use the "login" keychain' message when I login. Setting that problem aside, I'd appreciate knowing what application should be named. I don't have to use the application in the rule, I could use 'Time of Day' but the former would be more elegant in case I decide to change QRecall's schedule.

On the third point, I guess that I don't need to cancel the "Hold While No Archive" condition if ControlPlane has done its job?

My QRecall archive is around 460 GB. Until a few weeks ago I had been backing up to my NAS (an Asustor 606-T) by WiFi. By and large this worked OK BUT the verify process was taking 20+ hours. I have now abandoned WiFi for my desktop computers hard-wiring them, the ADSL modem, NAS etc together. Doing this has cut verification down to around 2 hours AND, thus far at least, cut out the small errors that had crept in during the WiFi backups.

At the same time I have revised my Actions to use a daily 'Rolling Merge' in which I'm keeping the most recent 7 days, followed by 8 day layers, 6 week layers and 12 month layers. Given that I'm not short of space on the NAS, is this a good choice? Indeed is there a recommended suite of Actions when backing up to a NAS?

-- Charles

Before going away I 'hold all schedules' until after I expect to return and shut my machine down. My aim is to avoid QRecall running immediiately I restart. When my return is delayed until after the date that I've chosen, I don't achieve my aim. Normally this is OK but not always, on my last late return my computer crashed during the immediate back-up. While the crash did not damage the archive, it did require a time-consuming reindex of it. Is there a way to hold schedules indefinitely?

James Bucanek wrote: 6.5 MB/min is dreadfully slow. Are you sure you don't mean 6.5MB/sec? That's about what I would expect from WiFi.

You're right. As ever my maths missed out some zeros. Now that the verify is finished I find that a 450+ GB archive took just under 20 hours to verify. This (re)calculates to just over 6.4 MB/sec.

James Bucanek wrote: Verifies are I/O bound. If you have 100Mb ethernet, connecting via ethernet will give you about 10MB/s. If you have Gb ethernet, you should get about 80-100MB/s.

I don't know what your topology is, but consider having a different computer verify the archive. I have several laptops and an iMac that all capture via WiFi, but I use the server that's connected directly to the shared RAID to perform all of the weekly verify and merge actions. Everything is fast.

Good idea, I'll try to organise a spare laptop to do the 'heavy lifting'.

James Bucanek wrote:
It depends on how the volume mounts. If the volume mounts as a physical hard drive, QRecall will mount it before starting an action. If the mounts as a remote/network volume, then that requires an account and password, which requires the keychain, which requires that you be logged in and your keychain unlocked when the action runs.

A little experimentation should tell you which method works.

Unfortunately it mounts as a remote/network volume. It's hard-wired to my modem/router and WiFi from that to my Mac. While back-ups run at an acceptable speed, verify operations are terribly slow at around 6.5 MB/min. As my NAS has 3 drives and uses RAID 5, I'm thinking of cutting back to, say, one verify/month. Or maybe I should hard-wire my Mac to the router? Any views?

James Bucanek wrote:Control+click/right-click on that item in the status window and choose Forget from the pop-up menu.

Thank you. Works perfectly.

I have now installed a NAS (Asustor AS-606T) and QRecall is backing up to it correctly. I have however two questions:

1 When using an external drive QRecall was able to back-up when I was logged out at night. Is it possible to arrange this with a NAS (which runs 24/7)? Or must I leave myself logged in 24/7 too?

2 Testing the NAS I made a new archive on the NAS. I never used it and have deleted it. Status Window remembers it and lights its red button to show that the archive has never been used. How do I get Status Window to 'forget' that archive?

Very helpful, thank you.

Yesterday (Sunday) I had a message from Drobo. It advised that the Drobo FS has been replaced by the Drobo 5N and that Drobo doesn't officially support 10.6.8 on any of its current products. This means that a more recent operating system is needed to configure a current unit but that once that is finished any 10.6.8 Mac should be able to access it. The Drobo 5N would however still need to be managed by the computer that configured it. This rather rules out Drobo units from my options.

My oldest Mac can only run Snow Leopard, it and my other machines back up to individual FireWire drives. Those drives start to fail from time to time; so far I've been able to anticipate this and have transferred the archives to new ones. I'm starting to consider whether I'd be better served by having a NAS. Reading here I believe that QRecall will use one as only a few problems have been reported. So my questions are:

- am I right in thinking that setting up QRecall to use one is (relatively) easy, and
- if James will allow, might I seek views on the easiest make for a simpleton to use; my reading suggests my choice should be between Drobo and Synology but I may well have missed something.

Views on both points will be much appreciated.

-- Charles

James Bucanek wrote:

Charles Watts-Jones wrote:Have run the complete set from the Actions window. All OK. Will report again after tommorrow morning's schedule.

Then I would expect it to work. If it doesn't then something else (besides the archive location) is the issue.

This morning's back-up worked as it should - good! I did two things before it ran:

1. 'reconnected' and resaved the Actions, and
2. rebooted my machine. I hadn't done this when installing the new drive as FireWire drives can be connected 'hot'. This, I suspect, is what got everything back to normal. Doubtless James will comment.

So I'm (moderately) relaxed again

> Out of curiosity, did you run the capture action from the
> actions window or from the File menu?

From the Actions window

> I can't think of what. I would suggest that you need to
> update the location of your archive in your actions, but
> you seem to have done that already.

Have done it again. Will see what happens tomorrow morning.

> If the archive appears grey or has a warning, there are still
> locations that need to be updated.

Nothing greyed ou. Would attach a picture but can't find a way to get my machine to do that.

> It they all say they are ready to run, try running them from the
> action menu (assuming you didn't try that before). If they run
> successfully, and yet they don't run when scheduled, then something is > clearly off.

Have run the complete set from the Actions window. All OK. Will report again after tommorrow morning's schedule.

My external backup disk was failing so I replaced it with a new one. I copied my QRecall archive across, changed the location of the new drive in the Actions and saved the changes. As a test I ran the Capture action, it ran flawlessly. Using the menu File > Open Recent QRecall opened the archive in its new location.

The Actions are set to run during the night when I'm logged out. After logging in, I checked that they had indeed run. For two mornings QRecall reports 'Capture could not find archive'. The menu File > Open Recent still finds the archive OK and the actions run manually flawlessly as usual. I must be missing something but what?

Thank you for a comprehensive explanation. A 'verify' is due early tomorrow morning and I'm hoping for a 'green light' after breakfast.

Yesterday I installed beta 57. QRecall runs every night. After I logged in this morning, the menu bar status icon was red. This suggested to me that there had been a back-up failure. I opened the Status Window to find:

QRecallC (my archive): Green Blank Red
Captured today: Green Blank Blank
Verified never: Blank Blank Red
Disk use bar(?): Green with size data below

Sorry that I've had to spell this out, I can't persuade this system to accept an attachment (I'm sending a picture separately to James).

Being of the generation that has difficulty with pictograms, I don't understand why the first line shows green and red, nor do I understand why the verified line shows red when the log confirms my bi-weekly verify status as OK. And I really don't want to start my day with a RED icon when the log confirms all is OK. Could RED be reserved for serious trouble please?