Facing a 7+ hour verify, I think my final configuration will need to have the server do the verification and compacts of archives from the laptops as suggested in several forum threads. I assume if I install QRecall on the server with its "Start and run actions while logged out" enabled, the actions will run (I understand I'll need to have appropriate filesystem permissions for QRecall on the server).

However, it doesn't appear that on a headless server a verification failure has any place to warn me. Given my experience so far with handling fileserver disconnects I'm guessing I'll see verification errors with some regularity. How can this be handled? The discussion of autorepair in the manual focuses primarily on the client repairing during capture. However, in my logs I see messages like:

Action 2014-11-14 18:00:01 Failure Capture failed
Action 2014-11-14 18:00:01 The index of the archive is incorrect and needs to be recreated.

I presume a repair would have fixed these (in my tests I just ended up recreating the archive).

Specific questions:

- This old thread http://forums.qrecall.com/posts/list/118.page#488 mentions email notifications, was that ever implemented?
- Is it possible to chain verify to repair on the server action?
- If the server verification fails is this guaranteed to trigger a warning and eventual autorepair on the status on the client? Will the client's status window show the verification state produced by the server (i.e. is the verification failure persisted to the archive for other readers)?
- Will the server repaired archive trigger recapture of corrupted files in the archive from the client?

Thanks,

Alex

Alex wrote:I assume if I install QRecall on the server with its "Start and run actions while logged out" enabled, the actions will run (I understand I'll need to have appropriate filesystem permissions for QRecall on the server).

Correct. You also don?t need to install an identity key on the server if all you?ll be running are maintenance actions (verify, merge, compact, repair, and so on).

If you have a fast server and a slow network, it?s recommended that you perform everything but captures directly on the server.

However, it doesn't appear that on a headless server a verification failure has any place to warn me. Given my experience so far with handling fileserver disconnects I'm guessing I'll see verification errors with some regularity.

Possibly. For most actions (capture, merge, and so on) a spontaneous interruption due to a network communications break, process termination, or loss of power, will leave the archive in a state where it will be auto-repaired on the next regular action. That includes the verify action. So even if you regularly lose connection with the file server, or crash your laptop, the next regularly scheduled action will/should restore the archive to its previous state and pick up where it left off.

Caveat: There are critical moments in an archive?s life where a terminal interruption will leave the archive is a state that can?t be auto-repaired. For those (rare) situations, a repair will be necessary.

The discussion of autorepair in the manual focuses primarily on the client repairing during capture.

All actions will first attempt to auto-repair the archive before proceeding. The one exception is the Repair command when you explicitly tell it to not perform an auto-repair before repairing.

Tip: If all you want to do is auto-repair an archive, run a verify action. If it manages to get started, then any auto-repair that needed to be performed was successful, and you can now cancel the verify.

However, in my logs I see messages like:

Action 2014-11-14 18:00:01 Failure Capture failed
Action 2014-11-14 18:00:01 The index of the archive is incorrect and needs to be recreated.

That?s a more serious issue that would require a repair (or reindex) to correct.

- This old thread http://forums.qrecall.com/posts/list/118.page#488 mentions email notifications, was that ever implemented?

QRecall support Growl, and the latest Growl supports several email notification extensions. (Note that probably won?t help you on your server if you don?t leave a user logged in, but it would likely work on your clients.)

- Is it possible to chain verify to repair on the server action?

That?s on the to-do list for the next version of QRecall.

- If the server verification fails is this guaranteed to trigger a warning and eventual autorepair on the status on the client? Will the client's status window show the verification state produced by the server (i.e. is the verification failure persisted to the archive for other readers)?

An action that fails (but does not terminate) will update the status of the archive, and that status will (eventually) appear in all status windows that are displaying the status of that archive. So yes, a fatal verify error will eventually percolate back to the client?s status window.

Note that this doesn?t apply to auto-repairable conditions. The conditions that leave the archive in an incomplete state are unexpected terminations that (obviously) don?t finish and don?t update the archive?s status. The next action will attempt to auto-repair the archive. If successful, no harm no foul. If not, it will update the status to ?needs repair? and stop.

- Will the server repaired archive trigger recapture of corrupted files in the archive from the client?

Yes. If the repair process finds anything out of place in a layer, that layer is marked as ?damaged?. A capture that references a damaged layer ignores all file change history, exhaustively recurses through the entire directory tree, and fully recaptures all suspect files.