Backups are not evidence

I run production infrastructure for an Australian healthcare company under Privacy Act obligations. Virtualisation, storage, backup, identity and mail, with sole technical responsibility for all of it. I am not going to name the organisation and I am not going to publish its architecture, so this is a case study about what the obligation changes, not a tour of somebody else's estate.

The short version is that the Privacy Act does not ask whether you take backups. It asks what you can establish, and how fast.

The obligation is not the one most people quote

Two provisions do most of the work here.

The first is that a health service provider does not get the small business exemption. Under section 6D(4)(b) of the Privacy Act 1988, an entity is not a small business operator if it provides a health service and holds any health information other than in an employee record. A three-person medical practice is covered on exactly the same terms as a hospital group. Turnover is irrelevant. That single subsection is why so much of the advice written for Australian small business simply does not apply in this sector.

The second is Australian Privacy Principle 11, which requires reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure. "Reasonable steps" is deliberately not a checklist, and the absence of a checklist is the part people find uncomfortable. It means the standard is judged after the fact, against what you actually did, with the sensitivity of health information as the multiplier.

Then there is the Notifiable Data Breaches scheme. If you suspect an eligible data breach, section 26WH requires all reasonable steps to complete an assessment within thirty calendar days. Thirty days is a ceiling, not a plan. If the assessment finds reasonable grounds to believe an eligible breach has occurred, section 26WK requires notification to the Commissioner and to affected individuals as soon as practicable.

Read those together and the design question stops being "is the data backed up" and becomes "within thirty days, can I say what was in there and whose it was". Those are different systems. One is storage. The other is inventory, logging and retention.

What that changed

Three things, concretely.

Restore evidence, not backup reports. A backup job that reports success is a claim about writing, not a claim about reading. The only thing that establishes recoverability is a restore that somebody performed, on a date, with a written result. So restores are scheduled work with an owner and a record, and the record is the artefact — not the green tick in the backup console. When someone eventually asks how the recovery position was known to be sound, the answer has to be a date and an outcome, not a screenshot of a dashboard.

This is also why we sell a restore test as a fixed-price piece of work rather than as a line item inside a managed service. It is the part that is quietly skipped, and it is the part that decides whether the rest of the arrangement was real.

Monitoring that alerts on absence. The failure mode that hurts is not an error, it is silence. A snapshot that stopped being taken three weeks ago produces no alert at all in a monitoring setup that only watches for failures. So the alerts are written against the absence of an expected thing — no snapshot in the window, no replication receipt, no log lines from a host that should be talking — rather than against error strings. Grafana and Loki carry that; the design decision is what you choose to consider abnormal, and "nothing happened" has to be on that list.

Retention that survives the account that created it. Ransomware and a mistaken deletion look identical from the perspective of a backup target that trusts its client. If the same credential that writes the copy can also delete it, the copy is not a second copy — it is the same copy in another building. The offsite arrangement is pull-based and separately credentialed for that reason, and the retention is set so that a problem noticed a fortnight late is still recoverable from something older than the problem.

Where Proxmox and ZFS earn their place

The virtualisation is Proxmox VE on ZFS, on Dell hardware, with replication offsite. That is not an ideological choice and I would not pretend the licensing argument was the deciding one here.

ZFS earns it because of what it makes cheap: snapshots that cost almost nothing to take, and checksums on every block, so bit rot is something the filesystem tells you about rather than something you find during a restore two years later. Under an obligation that turns on what you can establish, a filesystem that can prove its own integrity is worth more than one that is merely fast.

Proxmox earns it because the whole stack is inspectable. When something is wrong at two in the morning, the difference between a system you can read and a system you can only file a ticket against is the difference between a bad night and a bad week. Its subscription is priced per occupied CPU socket and does not care how many cores are in the socket, which — as the VMware renewal calculator on this site sets out — is the whole reason the two vendors' invoices diverge as core counts rise.

What I am not claiming

I am not publishing recovery time objectives, host counts, data volumes or incident statistics for someone else's environment, and you should be sceptical of any consultancy that does. What I will stand behind is this: every architectural decision described above is one I also carry the pager for. We do not sell an arrangement whose failure mode we have not had to sit through.

If you are a health service provider and you have never performed a restore you could describe to the Commissioner, that is the gap. It is also the cheapest one on the list to close.