What happens the day you lose your clinic's data — or your access to it?
What actually costs clinics their records is rarely a fire or a failed disk — it is an inbox nobody can open any more. This guide separates the three failures everyone calls data loss, covers what protects against each, and explains why a backup nobody has ever read back is not a backup but a feeling.
Ask a clinic owner about their plan for losing data and you will usually hear about backups. That is half an answer. The cases where a clinic actually loses years of work are rarely a fire or a burned-out disk — they are a staff member who left owning the mailbox the account was registered to, or an owner who changed mobile provider and lost the number their verification codes go to. The data is entirely intact. Nobody can reach it.
A plan that works starts by separating three different failures that everyone calls by the same name. Each has a different likelihood, a different defence, and a different cost if you are unprepared for it.
Three failures, not one
| Failure | How it looks from inside the clinic | What protects you |
|---|---|---|
| The data is gone | Records missing or deleted, or a vendor that shut down | A verified backup that you hold |
| The data is there and you cannot get in | The account inbox is lost, or the second-factor phone is | Recovery address, recovery codes, a second admin |
| The data is there and readable by others | A leaked file, or a stolen account | Encryption, scoped permissions, an audit trail |
The middle column is what makes this table useful. A clinic prepared only for the first row — a weekly backup and nothing else — falls to the second, which is the most common of the three. The reverse holds too. All three are built together or not at all, and the third one is covered in patient data security and two-factor authentication.
A backup nobody has read back is not a backup
This is the most important sentence on the page and the most widely ignored. Writing a file somewhere is only half the operation; the other half is opening it again and confirming that what is inside matches what was promised. The difference between the two halves never shows up until the day you need the file — the one day you have no alternative.
Backup complete should mean the file was read back from end to end after it was written, decrypted, checked part by part for integrity, and the rows and files actually inside it counted and compared against what its own manifest claims. An archive that fails any of that is better deleted, with the failure recorded plainly — because an unverifiable backup is worse than none, given what a clinic will do in the belief that it is covered.
Three questions expose the truth quickly. Does the system tell you how many rows and files the last backup genuinely contained, or just say it finished? Does anyone get alerted when a scheduled backup fails, or does it fail quietly? And when did somebody last actually open one?
A backup you cannot download is not yours
There is a real difference between the vendor takes backups and the clinic holds a copy. The first is an internal procedure at somebody else's company that you cannot see or control, and it helps you least if the dispute is with that vendor or the vendor stops trading. Insist on being able to download a complete file yourself, and to export your data in a readable format, without going through support.
What a backup should carry, and what it should not
A useful archive carries everything that genuinely belongs to the clinic, not just database tables: patient files and their clinical records, appointments, invoices and payments, clinic settings and identity, the compliance ledgers — and above all the files themselves: radiographs, clinical photographs, uploaded documents. A backup holding tables but not images looks successful right up to the restore, where every imaged patient turns out to have lost the part that mattered.
Equally, some things belong deliberately outside the file. That is design, not an omission:
- Passwords, second-factor secrets, and sessions: restored staff accounts should come back present and unable to sign in until set-password invitations go out. A file carrying the means of access is a file that hands whoever holds it an entire clinic.
- The platform's records about the clinic: subscription and payment ids, support tickets. Those are records about the clinic, not the clinic's records.
- The account's own identity: its id, its address, its trial dates. A restore puts your data back into your account; it does not rewrite the account.
- Signing keys and integration credentials: an e-invoicing certificate is bound to an issuing device and an establishment, and copying it elsewhere means invoices signed with an identity other than the issuer's. A restored clinic re-onboards, and that is the correct behaviour rather than a gap.
Losing access is not losing data
This is the second failure, the most frequent and the least prepared for. A clinic whose owner cannot open their inbox does not need a backup — its data is perfectly intact — it needs a route back that was established in advance. These three are all set up before they are needed, never after:
- A second, verified recovery address: genuinely separate from the sign-in address, and preferably not on the clinic's own domain — a domain you have lost does not become useful because you named a second mailbox on it.
- Account recovery codes: shown once at registration, each usable exactly once. Print them and keep them somewhere safe outside the system entirely. A photo on the owner's phone is no help on the day that phone is what went missing.
- A second administrator: the cheapest of the three and the most overlooked, and the only one that helps when the owner is unavailable rather than merely locked out — travel, illness, a sudden departure.
There is also a security rule worth asking about explicitly: every route that can move the sign-in address, or hand out the means to move it later, must demand the password and the enrolled second factor. Guarding one door of a room with three is not guarding it — whoever steals the password requests fresh recovery codes at the unguarded door, then spends them at the guarded one. Any change of sign-in address should also notify the old address with a one-click cancel, and confirm through a link sent to the new one.
No support-side override is a feature, not a gap
It can feel obstructive that a support desk cannot move your sign-in address over the phone. But a support desk that can is a support desk that can be talked into doing it for somebody else — the easiest way to take over a clinic without breaking any encryption at all. The restriction that annoys you today is the one protecting your account from someone impersonating you tomorrow.
The restore, in the order that gets a clinic working
Start in a clean space
A correct restore adds rows rather than replacing them, which is why it should refuse a space that already holds data — merging two sets of records cannot be undone once it has happened. Restore into an empty clinic.
Restore from the stored copy, not an upload
If the system already holds the archive, the server can read it directly at any size, with no download and re-upload constrained by what a browser can push. The file-upload path stays available for a copy the clinic keeps itself, but it is the second option, not the first.
Reopen the staff doors
Because the means of access are deliberately not in the archive, the team comes back present and unable to sign in. The correct step immediately after a restore completes is sending set-password links to everyone at once, so the clinic is working again in minutes rather than days.
Rebuild the external links
Whatever was deliberately excluded has to be re-established consciously: e-invoicing onboarding again, a permissions review, and a check that reminders and scheduling point at the right settings. Write that list now, not on the day.
Two copies, in two places
One technical detail with a direct clinical consequence: if radiographs and documents live in one storage location, and the backup archives live in the same location, you have a single point of failure that takes the original and the copy together. The very failure you keep backups for is the one that swallows them.
The right arrangement writes every upload to two stores, reads from the second automatically when the first cannot answer, and copies backup archives into both. Deletion follows the same rule: a delete has to reach both stores, or a document a patient asked to have erased reappears the first time a read falls over to the second — an erasure that undid itself.
Where those copies sit geographically is a fair question too, particularly for clinics under regulatory obligations. Our own answer plainly: hosting is in Europe by default for every clinic, and in-region hosting is available on request as a paid add-on, subject to a written agreement. Ask any vendor for an answer that specific, in writing, rather than verbal reassurance — a backup stored somewhere it is not permitted to be is another problem, not a solution.
A checklist that fits one meeting
- When was the last successful backup, and how many rows and files did it contain?
- Who gets told if tonight's scheduled backup fails, and how?
- Can you download a complete copy and export your data yourself, without support?
- Have you actually rehearsed a restore at least once, even into a test space?
- Does the owner have a verified recovery address and recovery codes printed outside the system?
- Is there a second administrator who can act if the owner is unavailable?
- What has to be reconfigured by hand after a restore — written down now, not then?
Your data in your hands, not on deposit
Backups that are read back after they are written and reported when they fail, a full export whenever you want one, and a route back into the account ready before you need it.
See what the system does