Your choice
1.You designate
The client, the MSP, or the IT team explicitly selects the artifact to check. RestorSignal doesn't browse your consoles and doesn't pick "the right backup" on your behalf.
A real restore. A documented proof.
The job is green.
Is the restore too ?
Your backup software can tell you a job finished. RestorSignal steps in afterward : you choose the artifact to test, you trigger the check, we run a real restore and document precisely what was verified.
RestorSignal v1.0 — MariaDB runner available up to level L3. Your backup solution, your data, and the choice of artifact stay under your control.
01 / A separate layer
Keep your backup. Add independent proof.
RestorSignal isn't a new backup solution. It tests the object produced by the one you've already chosen. Veeam, PBS, Hyper‑V, NAS, or a SQL dump remain your backup chain ; RestorSignal forms a separate verification chain.
Our role
2.We restore
The runner performs a real restore in the intended context and applies the checks defined by the versioned protocol.
The result
3.We document
Object, fingerprint, versions, durations, checks, PASS, FAIL, ERROR, level demonstrated, and limits become usable pieces of evidence.
This isn't unique to RestorSignal — the gap between a backup reported as successful and a restore that has actually been verified is documented well beyond our own materials. Further reading — external resource: TechTarget — "Verify backup data integrity to reduce recovery risks".
02 / Over time
A one-off proof becomes a history.
The first test already answers a useful question. The next ones let you track freshness, artifact rotation, failures, retests, and how incidents actually get resolved. An old result is never rewritten to make the history look nicer.
FAIL
The MariaDB restore fails. The failure is kept as a technical event.
ACK
The incident is acknowledged. The context and the owner can be recorded.
NEW ARTIFACT
A new artifact is chosen and submitted. Its fingerprint differs from the previous one.
RETEST PASS
The new restore reaches L3. The 03:12 FAIL stays visible in the history.
03 / Method
The client triggers. RestorSignal executes.
This separation is deliberate. RestorSignal doesn't need an admin account on Proxmox, PBS, Hyper‑V, your NAS, or your backup software to decide what to test. Automation is still possible, but it's scheduled under your control.
On your side
- 1. You check that the backup to test is available.
- 2. You explicitly designate the artifact or the job.
- 3. A local adapter can prepare the staging and trigger the runner.
- 4. A cron, Task Scheduler, or orchestrator can repeat that same decision.
RestorSignal
- 5. The runner restores the object actually submitted.
- 6. The checks return PASS, FAIL, ERROR, or NOT_APPLICABLE.
- 7. The level reached is computed without ever turning an ERROR into a success.
- 8. The minimized technical results feed the proof report.
Principle: RestorSignal never proves that you chose the backup you "should have" chosen. It proves what happened to the artifact you actually submitted.
04 / Depth demonstrated
"PASS" isn't enough. How far did you actually test ?
The RestorSignal reference model separates a check's result from the depth actually demonstrated. A higher level that wasn't run stays explicitly not evaluated.
L1Artifact accessibility.
L2Structural integrity.
L3Technical restore actually executed.
L4Functional validation of the restored service.
L5Application-level check under a protocol defined in advance.
Current v1: the MariaDB runner targets L3. L4 and L5 must therefore never appear as implicitly validated when they haven't been run.
05 / Operational signal
Not one more dashboard to forget about.
RestorSignal keeps the history and the proof report, but important events also need to be able to reach the tools the team already uses.
v1.0
Outgoing webhook
Structured events to create a ticket, feed an RMM/PSA, or trigger an automation.
v1.0
Simple notification for environments that don't want to integrate another chain right away.
Rolling out
Native connectors
Specific connectors are added based on the environments actually in use, without changing the test method.
06 / Explicit limits
What the proof says. And what it doesn't.
Credibility comes as much from what is demonstrated as from what stays out of scope. RestorSignal doesn't turn a limited technical observation into a global promise.
Demonstrated
The tested object
An identified fingerprint was processed by an identified runner and protocol, on a given date, with determined results and durations.
Not demonstrated
Production provenance
In local mode, RestorSignal doesn't claim to prove that the supplied artifact is automatically the authentic, complete backup of your production.
Always visible
What wasn't tested
A missing higher level, a check that wasn't run, an infrastructure error, or an uncovered application scope stay visible instead of being absorbed into a global PASS.
We don't ask you to believe the backup works.
We document what was actually tested.
We document what was actually tested.
07 / Auditable method
The method itself has to be open to scrutiny.
Proof only has value if you can understand how it was obtained. RestorSignal is therefore building its reference model, its protocols, and its proof formats so a third party can eventually examine, reproduce, and audit them.
A deliberate stance
"Don't take our word for it. Examine our method."
Level criteria, PASS / FAIL / ERROR statuses, runner versions, result schemas, protocol qualification, and the chain of proof are meant to be publicly documented.
BEING PUBLISHEDRestorSignal reference model
The RS‑RVP reference model is currently an internal draft. It isn't yet presented as a certified standard nor as an external validation.
01Artifact chosenby the client
02Fingerprintobject identified
03Versioned runnerknown execution
04Restoreactually executed
05Checksnormalized results
06Prooftraceable over time
Down the line: this section could become a genuine "Audit RestorSignal" entry point into the public reference model, the schemas, the protocol versions, and the elements that let a third party check the method.
08 / Proof report
Presenting a technical fact to someone who doesn't run your backups.
The RestorSignal report aims to make the result understandable to a CIO, a client, an auditor, an insurer, or a regulator, without asking them to interpret the backup product's console.
What the report describes
- The artifact actually submitted and its fingerprint.
- Date, duration, and context of the run.
- Runner, protocol, and versions used.
- Checks run and normalized results.
- Level actually demonstrated.
- Limits, ERRORs, and elements not evaluated.
What a third party can do with it
- Confirm that a real restore was performed.
- Understand the result's exact scope.
- Compare several checks over time.
- Request additional elements if needed.
- Fold the report into their own audit or evaluation process.
- Remain free to draw their own conclusion.
09 / Two uses
Ops builds the history. Evidence renders it.
Operational tracking and the third-party report rest on the same observed reality. Evidence doesn't retroactively reconstruct tests that never happened.
RestorSignal Ops
- Recurring tracking of active contexts.
- Local tests and retests with no per-run commercial meter.
- Freshness, observed rotation, FAILs, incidents, and history.
- Day-to-day MSP / IT use.
RestorSignal Evidence
- Report built from results actually observed.
- Scope, level, and limitations explicitly documented.
- Readable by a client, CIO, auditor, or insurer.
- No self-proclaimed certification from RestorSignal.
10 / Business model
You don't pay for the size of your dumps.
In Local mode, backup volume stays on your side and isn't meant to determine the price. The billable value lies in the contexts tracked and the retention of results and proof. A temporary Lab mode is a different case, since it actually consumes infrastructure resources.
Local mode
- Pricing based on contexts tracked.
- Retention of results and proof reports.
- Local tests and retests aren't billed by backup volume.
- Your dumps are never transferred to RestorSignal.
Lab mode
- Temporary environment provisioned on demand.
- Voluntary transmission of the artifact by the client.
- Cost tied to storage, compute, transfer, and the disposable VM's lifetime.
- Context destroyed after the planned cycle.
11 / Pricing
Tracked contexts. Not a run counter.
The plans below cover Local mode. They include unlimited local runs and retests, 24 months of result retention, and a maximum of one sealed Evidence per context per day. Billing is monthly and based on the number of tracked contexts.
Essential
29 € excl. VAT / month
10 contexts
- 10 active contexts max
- Unlimited local runs and retests
- 24-month retention
- 1 sealed Evidence max / context / day
Pro
79 € excl. VAT / month
50 contexts
- 50 active contexts max
- Unlimited local runs and retests
- 24-month retention
- 1 sealed Evidence max / context / day
MSP
199 € excl. VAT / month
200 contexts
- 200 active contexts max
- Multi-tenant organization
- Unlimited local runs and retests
- 24-month retention
- 1 sealed Evidence max / context / day
Scale
399 € excl. VAT / month
500 contexts
- 500 active contexts max
- Multi-tenant organization
- Unlimited local runs and retests
- 24-month retention
- 1 sealed Evidence max / context / day
RestorSignal v1.0
Keep your backups. Add real proof of restore.
Start with a limited scope on your existing architecture. RestorSignal doesn't replace your backup tool, doesn't choose your backups, and doesn't ask for access to your production consoles to decide what to test.