Method
The only honest test of a backup is a restore.
This page explains where the premise came from, what the words in the catalogue mean, and what would have to be true for the company to be worth paying. It also states, again, that none of it is running.
Why this exists
A green tick is not evidence.
Backup tooling is mature and mostly good. The reporting it produces is about the backup: the job ran, the bytes went somewhere, the retention rule applied, the schedule held. Every one of those can be true of an artefact that will not come back.
What makes this durable rather than a one off mistake is that the failure is silent by construction. A backup that will not restore behaves exactly like one that will, right up to the moment somebody needs it. There is no alert, no red light, no gradual degradation. The information simply does not exist until a restore is attempted, and the attempt is expensive enough in attention that it gets deferred to a quarter that never arrives.
So the intended product is not clever. It is a scheduled attempt, plus the discipline to write down what happened, plus a refusal to let a skipped run disappear.
Why the schedule belongs to the supplier
Because a rehearsal you run yourself is the first thing dropped in a busy month, and nothing about dropping it is visible afterwards. Moving the schedule to somebody outside the building does not make the restore better. It makes the gap in the record impossible to hide, which is a different and more useful property.
Why the report has to include the failures
A verification service that only reports successes is worse than nothing, because it produces a document that looks like assurance. The period report is specified to include every failure and every skipped run, and the evidence file is specified in an open format precisely so a customer can check that the quarter's summary matches the individual runs.
What we are not claiming
Not that this is a new idea. Restore testing is old, well understood and recommended by every serious framework. The observation is only that it is widely recommended and narrowly practised, and that the reason is organisational rather than technical.
Definitions
The words in the catalogue, and exactly what they would mean in a contract.
Most disagreements about a service like this are disagreements about a definition, discovered late. These would go into the engagement in this form.
| Term | What it means here | What it does not mean |
|---|---|---|
| Rehearsal | One complete cycle: restore a nominated backup into an isolated environment, run the agreed checks, record the result, destroy the environment. | It is not a test of your production system, and nothing in your production system changes. |
| Check | A single assertion about the restored copy that returns a number, a pass or a fail, and never returns records. | You choose them. We can suggest, and a suggestion is not advice. |
| Recovery time objective | How long the business has decided it can be without a system before the consequences become serious. | Almost always written down as a target and almost never measured. A rehearsal measures the restore part of it. |
| Recovery point objective | How much recent work the business has decided it can afford to lose. | A rehearsal reports the real age of the newest restorable point, which is sometimes not the age the schedule implies. |
| Isolated environment | A network and storage boundary created for one rehearsal, with no route to your production systems and no route to any other customer. | Created at the start of the run, destroyed at the end of it, including when the run fails. |
| Evidence file | The dated written record of one rehearsal. | A record of what a third party observed. Not an audit opinion, not certification, and not a substitute for either. |
| Failure | The restore did not complete, or a check did not pass, or a rehearsal did not start when it should have. | A skipped rehearsal counts as a failure. A silent gap in the record is the failure mode the whole idea exists to prevent. |
Position
We would be a processor, and that shapes everything.
A customer's backup contains the customer's data, and the people in it never chose us. The customer decides why that information exists and what may be done with it. We would be a set of hands acting on written instructions, and nothing in that pile would be held for a purpose of ours.
That is not a legal footnote. It decides the design.
- Checks return counts and statuses, not records, because a report containing rows is a second copy of the data in a second place.
- The evidence file carries no content, so it can be handed to an auditor without a redaction exercise.
- Environments are per rehearsal and per customer, never shared and never persistent.
- The credential reads and cannot write.
- Nothing is used for product development, benchmarking, or the training or evaluation of any model.
The privacy policy is split explicitly into the parts where we would be a controller and the parts where we would be a processor, and every numbered section is marked with which applies. It also has a section describing the risk our own service creates, which is the section we would want a prospective customer to read first.
Register
The verifiable part.
Nothing on this page is a credential. These are the facts a stranger can confirm without asking us.
Legal name
SHIELD DATA SYSTEMS PTY LTD
Entity type
Australian proprietary company, limited by shares
ACN
696 553 036
ABN
46 696 553 036
ABN status
Active
GST
Registered for GST
State
New South Wales, Australia
Contact
[email protected], the only contact route. There is no form on this site and no telephone number is published
Where to check it
The ACN sits with the Australian Securities and Investments Commission. The ABN, its status and the GST position are published free, without an account, at abr.business.gov.au
Service of documents
The registered office recorded against ACN 696 553 036 at ASIC is the address with legal effect for service. We do not publish a second address here, because a second address would not have that effect
SHIELD DATA SYSTEMS PTY LTD does not hold ISO/IEC 27001 certification, a SOC 2 report, an IRAP assessment or any other independent accreditation, and will not represent otherwise until one is genuinely held. It has no customers, no completed engagements, no published prices, no outside investment and no insurance policy. It has never restored a backup belonging to another organisation.