I backup my MacBook Pro over my LAN to a backup drive mounted on another computer. I occasionally have backup failures due to transient network problems, including operator error when I close the lid during a backup. These failures show up in the Archive Status box with a yellow circle and a "minor problem" message. Rerunning the backup is usually successful and clears the status indication.

On Wednesday I accidentally closed the lid during a backup and got a status window message that the archive required repair. Since that's a long process with a terabyte archive, I decided to rerun the backup first. It completed successfully and has been working since. The Archive Status window, though, refuses to reset and continues to show an "archive needs repair" message and a red circle, as does the status window on my other computer. I even told the Status window to forget the archive, thinking that would clear it, and the repair needed message still came back. Is the Status window indicating an underlying problem with the archive that needs repair, even though it seems to be working OK, or is this just a problem with the status report? I've sent a diagnostic report from Qrecall.

Since updating to Yosemite, I'm seeing a couple of other anomalies in the log. The first is repeated "Cannot connect with scheduler" messages, followed by reinstallation of com.qrecall.monitor.plist, and the second is an "Unable to determine path to VM swap files; assuming /var/vm" message within each backup log. (I don't see either of the log entries in my other computer.)

And as long as I'm writing, I'm curious about what's reflected in the "Ignored some changes" entries I see frequently?

Ralph Strauch wrote:... and got a status window message that the archive required repair. Since that's a long process with a terabyte archive, I decided to rerun the backup first. It completed successfully and has been working since. The Archive Status window, though, refuses to reset and continues to show an "archive needs repair" message and a red circle, as does the status window on my other computer.

That?s correct. When a capture, merge, compact, or other action that is modifying the archive encounters a fatal problem reading or writing the archive data, it sets a ?needs repair? flag in the archive?s status file. This is what triggers the message you?re seeing in status window.

The only actions that will clear that flag are verify and repair. Another successful capture, merge, or whatever does not mean the archive is fixed. None of these actions will repair anything that?s broken in the archive (except those things that can be fixed by auto-repair). If the next capture was successful, it just means you dodged the bullet that got your last capture, but it doesn?t mean the archive is in perfect working order.

I even told the Status window to forget the archive, thinking that would clear it, and the repair needed message still came back.

The Ignore command just makes the status window forget about that archive?s status. The archive, however, still maintains its status internally and the next action (capture, compact, verify, ?) will restore the archive?s status in the window in its entirely, which includes the remembered ?needs repair? flag.

Is the Status window indicating an underlying problem with the archive that needs repair, even though it seems to be working OK, or is this just a problem with the status report?

It may, or may not, be a problem with your archive. Since your failure was due to a network communications error, it?s possible there?s nothing actually wrong with your archive. But QRecall doesn?t know that, and it won?t reset that ?needs repair? status until it can verify that. And it only verifies the integrity of the entire archive during the verify and repair actions.

If it really bugs you, you could cheat. The archive?s status is maintained in the status.plist file in the archive?s package. Use the Ignore command in the status window to cause the QRecall application to discard its copy of the status, and then open the archive package and delete the status.plist file. QRecall will forget everything it knows about the status of that archive.

Or, you could just wait and run a repair.

Since updating to Yosemite, I'm seeing a couple of other anomalies in the log. The first is repeated "Cannot connect with scheduler" messages, followed by reinstallation of com.qrecall.monitor.plist

The interprocess communications is even more problematic in Yosemite. I?ve completely rewritten this logic in QRecall 2.0.

and the second is an "Unable to determine path to VM swap files; assuming /var/vm" message within each backup log. (I don't see either of the log entries in my other computer.)

I?m still doing research, but it appears that Yosemite has eliminated the vm_swap process. It?s now probably baked into the core OS. As such, there?s probably no way of customizing the location of your swap files in 10.10. This has little or no impact on QRecall. If it can?t find the vm_swap process it simply uses the standard VM swap location. In the next version of QRecall, I?ll remove this test for Yosemite users, but for now just ignore that message.

And as long as I'm writing, I'm curious about what's reflected in the "Ignored some changes" entries I see frequently?

OS X?s filesystem events history is a fantastic feature, but has known flaws. If QRecall relied solely on filesystem events to check for modified files, there are files it could premanently miss. (And yes, there are situations where Time Machine will neglect to backup files indefinitely.) QRecall combats this with a limit (which defaults to about a week) that it will trust the filesystem history information. Once that time period expires, it ignores the filesystem history and preforms an exhaustive scan of the entire filesystem. It also logs the message you see so you know when that happened.

Thanks, James. I always find it interesting to learn more about Qrecall's innards. I verified the archive to see if it was OK or not, and it wasn't. So I repaired and now it's fine.

James Bucanek wrote:
The interprocess communications is even more problematic in Yosemite. I?ve completely rewritten this logic in QRecall 2.0.

So QRecall 2.0 is still on the horizon? Maybe not too long?
Either way I am really looking forward to it.

Rosco Mahoney wrote:So QRecall 2.0 is still on the horizon? Maybe not too long?
Either way I am really looking forward to it.

Rosco,

Like the Great Pumpkin, QRecall 2.0 will rise again.

I?m happy to report that I delivered the final chapter of my new book, Learn iOS 8 App Development, to Apress yesterday. I expect near-full-time development of QRecall to resume in a week or two. I?ll post something on the forums when the next beta looks close.