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 does one thing about that: a restore that runs on a schedule, checks the restored copy against rules you set, and writes down whether it worked.
Contact [email protected]. Name one system, say where the backup lives and what a good restore looks like to you, and a substantive answer comes back inside 5 business days.
Catalogue
What is included, what it is 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 names the record each line leaves in your hands.
| Line | What is included | Target | Contract basis | Record produced |
|---|---|---|---|---|
| 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 | Run record |
| 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 | Check results |
| 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 | Timing |
| 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 | Point age |
| 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 | Email notice |
| 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 | The file |
| 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 | Quarterly report |
| 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 | Run record |
| 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 | Write-up |
Those targets are the figures we write into a contract and are held to, not averages taken across somebody else's systems. Your engagement names your systems and your schedule, and the targets attach to those.
Pricing is quoted rather than published: a fixed monthly fee for a scoped set of systems, agreed in writing before any work starts. Widen the scope and the fee changes from the date the wider scope begins, never retrospectively.
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
Run rehearsals against your systems for a year, have every one pass on the first attempt with no surprises about timing, completeness or keys, and the conclusion is that your backups were already sound and we sold you a receipt for something you already had. That is a real result, it goes into the period report in those words, and we would rather write it down than bury it. It is also the outcome we expect least often, which is exactly why it is the test.
Mechanics
How one drill runs, from start to teardown.
Seven steps, in this order, every time. The seventh is the one most likely to be skipped by a system assembled in a hurry, so here 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 do not take your backups or store them. If yours stops running, the rehearsal reports that there was nothing to restore, which is useful, and the backup stays 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 do 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, 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
Everything here sits on a register a stranger can search.
Everything above this section is our own account of our own service. The rows below are matters of public record instead, and checking them takes about a minute.
Legal name
SHIELD DATA SYSTEMS PTY LTD
Entity type
Proprietary company, limited by shares
ACN
696 553 036
ABN
46 696 553 036
ABN status
Active
GST
Registered for GST
Place of business
New South Wales, Australia
Contact
[email protected], the only contact route. No form exists anywhere here, and no telephone number is published
Registers holding this
ACN 696 553 036 sits on the companies register kept by ASIC (Australian Securities and Investments Commission). Look the ABN up on abr.business.gov.au, the Australian Business Register, which also shows whether it is active and whether GST applies. No account, no charge
Service of documents
Service takes effect at whatever registered office ASIC currently records for ACN 696 553 036. Nothing printed on this page substitutes for that address
Contact
Put one backup through a drill.
Start with a single system rather than the whole estate. Tell us what it is, what takes the backup, where the copy sits, and what a successful restore looks like to you. Back comes a scope, a schedule and a fixed monthly figure, in writing, before anything runs.
One address, no form. 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.