Automation

A scheduler runs a rule the client defined, it doesn't change who decides.

Nothing requires the client to trigger every test manually. It is common to set up automation on the client side — for instance: "every Sunday at 3 AM, take object X according to rule Y, hand it to the runner, and launch the test." This page clarifies what that automation changes, and more importantly, what it does not.

A client instruction, not a RestorSignal choice

A scheduler — a cron job, a recurring schedule in an orchestration tool, or any equivalent mechanism — only executes a rule the client itself defined. RestorSignal does not decide which artifact to test or at what frequency: the rule itself — which object, on what calendar, under what selection criteria — is written and configured by the client, its IT department, or its MSP.

This is the central point of this page, and it connects directly to the first principle governing the entire service: RestorSignal never chooses the backup to test, whether the trigger is manual or automated. Automating a trigger never hands RestorSignal the power of selection — that power stays, in every case, in the client's hands. RestorSignal never browses a backup console to pick what to verify on its own; it runs the test on the artifact submitted to it, whether that submission comes from a human action or an automated rule.

What automation concretely provides

The value of a well-configured automation is operational: it makes it possible to regularly verify, without repeated manual intervention, that the backups being produced remain actually restorable over time. It changes neither the execution mode used (see Execution modes), nor the nature of the evidence produced, nor the division of responsibilities between the client and RestorSignal — see Division of responsibilities for the full detail of that division.