Backup verification / New South Wales
A backup nobody has restored is not a backup.
It is a file of unknown quality in a place you are paying for. Shield Data Systems intends to sell one thing: a restore that runs on a schedule, checks the restored copy against rules you set, and writes down whether it worked.
The company was registered in 2026. Nothing below is running, no customer has used it, and no backup belonging to anyone else has ever been restored by us. The status column of the catalogue says the same thing on every row, on purpose.
Catalogue
What would be included, what it would be measured against, and on what contractual footing.
The base engagement is one written services agreement covering a named set of systems on a named schedule. The two add-ons are scoped separately before they start. The last column is the honest one.
| Line | What is included | Target | Contract basis | Status |
|---|---|---|---|---|
| Scheduled restore rehearsal | We take a backup you nominate, restore it into an environment created for that one run, and record whether the restore completed at all. | Runs on the schedule written into the engagement. Daily at the shortest, monthly at the longest. | Base engagement, written services agreement, monthly term | Not built |
| Integrity checks on the restored copy | Checks you specify, run against the restored copy: row counts against a floor you set, checksums, a table that must exist, a file that must be present, an application that must start. | Every check runs on every rehearsal. A check that cannot run makes the rehearsal a failure, not a partial pass. | Base engagement | Not built |
| Restore time, measured | Wall clock time from the start of the rehearsal to the moment the restored copy has passed its checks. | Recorded to the second on every rehearsal, so a recovery time objective becomes a measurement instead of an assumption. | Base engagement | Not built |
| Recovery point, measured | The age of the newest restorable point at the moment the rehearsal starts, taken from the backup itself rather than from the schedule that was supposed to produce it. | Recorded on every rehearsal, so a recovery point objective becomes a measurement instead of a policy document. | Base engagement | Not built |
| Failure notice | A message to the addresses you nominate when a rehearsal fails, is skipped, or cannot start. It says which system, which check, and what the error was. | Sent within 15 minutes of the failure being recorded. A skipped run is reported as loudly as a failed one. | Base engagement | Not built |
| Evidence file | A dated record of each rehearsal: what was restored, which checks ran, what each returned, how long it took, and confirmation that the environment was destroyed. No content from your data, ever. | Written at the end of every rehearsal, in a documented open format, retained for the term plus 12 months. | Base engagement, and the file is yours | Not built |
| Period report | A written summary of every rehearsal in the period, every failure, and what changed as a result. | Issued within 5 business days of the end of each quarter. | Base engagement | Not built |
| Rehearsal from the second copy | Where you hold a copy somewhere other than the primary backup target, rehearse from that copy instead, so the offsite one is the one being proven. | Alternating with the primary where the engagement calls for it. | Add-on, scoped in writing before it starts | Not built |
| Attended drill with your own team | A rehearsal run alongside your people, against a scenario you choose, with the result and the timings written up afterwards. | Scheduled by agreement, with at least 10 business days notice. | Separate written scope, priced separately | Not built |
Every row says not built, and every row means it. The targets in the third column are what we would be prepared to write into a contract, not measurements of anything that has happened. There is no beta, no pilot, no design partner and no waiting list. When the first rehearsal runs for a real customer, this table changes and the change will be dated.
No price is published either. Nothing has been sold, so a rate card here would be a number invented to look established. Pricing would be a fixed monthly fee for a scoped set of systems, agreed in writing before any work starts, and the first customer would negotiate it rather than accept it.
The premise
One claim, and it is falsifiable.
Backup software reports on the backup. It tells you the job finished, the bytes were written and the retention policy applied. All of that can be true of a file that will not restore.
The gap between "the backup job succeeded" and "we can be running again on this by Tuesday" is filled with things a backup job never checks. Whether the schema in the dump matches the application that has to read it. Whether the encryption key used eleven months ago is still available. Whether the one database that was excluded by a filter in a config file somebody edited in a hurry is the one that matters. Whether the restore takes four hours or four days.
None of those are exotic. They are ordinary, they accumulate quietly, and the standard way of discovering them is during an incident, at the worst possible time, in front of people who are already having a bad day.
So the claim is narrow
Not that we can protect your data. Not that we can guarantee recovery. Only this: the difference between a backup and a restore is a fact you can establish in advance, cheaply, on a schedule, and almost nobody does it because it is nobody's job on any Tuesday when nothing is wrong.
How you would know we were wrong
If a first customer ran rehearsals for a year and every one passed on the first attempt, with no surprises about timing, completeness or keys, then their backups were already fine and we sold them a receipt for something they already had. That would be a real result and we would rather report it than bury it. It is also the outcome we would expect least often, which is exactly why it is the test.
Mechanics
How one rehearsal would run, from start to teardown.
Seven steps. The seventh is the one most likely to be skipped by a system built in a hurry, so it is unconditional.
- Start on the schedule. A rehearsal begins because the calendar said so, not because somebody remembered. A rehearsal that does not start is recorded as a failure, which is the whole reason the schedule is ours rather than yours.
- Read the backup with a read only credential. Scoped to the backup store. We decline a credential that can write anywhere near production, and we would rather lose the engagement than hold one.
- Restore into an environment created for this run. New boundary, new storage, no route to your network, no route to any other customer, nothing shared.
- Measure the recovery point from the backup itself: how old is the newest restorable state, in reality rather than in the schedule.
- Run your checks. Counts, checksums, presence, an application that has to start. Each returns a number or a pass or a fail. None of them returns records, because a check that copies your data out of the environment defeats the point of the environment.
- Write the evidence file. What ran, what it returned, how long it took, in an open format you can read without us.
- Destroy the environment, including after a failure. The classic mistake is leaving a broken run standing while somebody investigates. Teardown is unconditional and investigation happens against the logs, not against a live copy of your production data.
A restore makes a second live copy of your production system. For as long as it exists it can leak exactly like the original, and a verification service run carelessly turns a dormant risk into a recurring one on a timetable. That is the honest downside of the idea, it is why steps three and seven are written the way they are, and it has its own section in the privacy policy rather than a reassuring sentence.
Boundaries
What this is not, so nobody has to find out later.
- Not a backup product. We would not take your backups or store them. If yours stopped running, a rehearsal would report that there was nothing to restore, which is useful, and the backup would still be yours to fix.
- Not disaster recovery. A rehearsal proves a restore worked in an isolated environment. It does not fail anything over and it will not stand in for a recovery plan on the day.
- Not a security assessment. We would not review your architecture, your access model or your code.
- Not certification. An evidence file records what a third party observed. It is not an audit opinion, nobody has accredited us to issue one, and presenting it as assurance would misrepresent it.
- Not advice. Choosing which checks matter is the customer's decision. We can suggest and the suggestion is not advice, because a check that tests the wrong thing passes for the wrong reason.
Register
The part of this page that can be checked against a public record.
Everything above is a description of intent. Everything here is on a register you can search yourself.
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
ops@shielddata.link, 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.
Contact
One address, no form, and a stated response time.
Write to ops@shielddata.link. Ordinary mail gets a substantive answer in 5 business days, a privacy request in 30 days, and anything with "Security" in the subject line the same or the next business day. The contact page lists what is worth including.