Trust
Backups and recovery
Until a restore has actually been performed, a backup is a belief rather than a capability. We have not performed one. That sentence is the whole page, and everything below explains what we do have, what we will not claim, and what would have to be true before we could.
- Quality and compliance
- Hospital operations
- Executive and finance
What is a backup and recovery position?
Definition
Backup and recovery
A backup and recovery position is four things: what is copied, how often, how quickly it can be brought back, and the date somebody last proved the last of those by actually doing it. A position missing the fourth is a plan rather than a capability.
Most vendors answer the first two and imply the third. The fourth is the one that matters, because restore procedures fail for reasons that are only discoverable by running them: a missing credential, an object-store permission nobody thought about, a dependency ordering that was obvious to whoever wrote the document and to no one else at three in the morning.
We can answer the first two honestly. We cannot answer the fourth at all, and that means our answer to the third is a target rather than a measurement. Publishing a recovery objective we have never tested would be publishing a wish with a number attached.
What is in place, and what is not
Three of these are gates that have not been cleared. That is the current state rather than a summary of ambition.
| Item | Status | Detail |
|---|---|---|
| A documented backup and restore procedure | Written | What to back up, and a step-by-step restore verification checklist. |
| Automated platform backups | Not yet enabled | A deployment gate on the pilot project, not yet cleared. |
| Point-in-time recovery | Not yet enabled | Same gate. |
| Object-storage versioning | Not yet enabled | Same gate. |
| A verified restore | Never performed | The gate that matters. Until this, the rest is a plan. |
| Published recovery point objective | None | We will not publish a target we have not measured. |
| Published recovery time objective | None | Same. |
| Hosting region and residency | Open decision | Where data lives is not committed. Ask before you evaluate further. |
| Retention periods | Open decision | Suggested values exist in our internal plan. None are asserted. |
| Append-only audit chain | Built | Relevant here: the audit trail cannot be silently rewritten, backup or not. |
Backup and recovery position by actual status
Why we will not publish an RPO or an RTO
Because a recovery objective is a measurement, and quoting one you have never measured is the specific dishonesty this whole section exists to avoid.
It would be easy to write "RPO: 24 hours, RTO: 4 hours" on this page. Those numbers are plausible, they are what our internal plan suggests, and no prospect would challenge them at the evaluation stage. They would also be fiction, because an objective is a commitment about behaviour under failure and we have never observed our behaviour under failure.
The number that matters is not the one in the plan, it is the one you get on the day. Those diverge for boring reasons: the restore takes three times as long as expected because of a step nobody timed, or it fails outright on a credential that expired. Organisations discover this during incidents, which is the worst possible moment and the most common one.
So the honest position is: we have a procedure, we have not run it, and we will publish objectives when we have measured them rather than before. If that is disqualifying for your organisation, it should be, and knowing it in week one costs you nothing.
What to ask us, and every other vendor, about this
Four questions. The answers are more revealing than any certification, and most vendors have not been asked them.
When did you last perform a restore?
Not "do you have backups", which everyone answers yes to. A date. If there is no date, the honest translation of their backup position is the same as ours, and the difference between us is that we said so.
What is your RTO, and how was it measured?
The second half is the question. A number from a plan and a number from a drill are different kinds of object, and only one of them will hold on the day.
Where does our data live, and what happens if we need it somewhere else?
Our answer is that the hosting region is an open decision, so if residency is a hard requirement for you, we may not fit. That is a real constraint and it is better named early.
What can be recovered but not un-changed?
The interesting one. Our audit trail is append-only and hash-chained, so history cannot be silently rewritten regardless of backup state. Ask what a restore would and would not undo, because that is where recovery meets evidence.
What this does and does not put at risk
Rydya stores no patient clinical records at all. What a failure here would put at risk is your operational and financial data, staff identities, uploaded evidence and the audit chain: real, valuable, and materially smaller in consequence than a system holding clinical records. That is context rather than an excuse. An unproven restore is an unproven restore, and if you are relying on Rydya for compliance evidence, the state of our recovery position is your risk as well as ours.
When this changes, and how you will know
When the gates are cleared and a restore has actually been drilled. This page will say so, with a date, and not before.
The three enablement gates are ordinary work: turning on automated backups and point-in-time recovery on the production project, and enabling object-storage versioning. They are not done because Rydya has not yet been deployed to a production project, which is the honest reason rather than an oversight.
The one that requires genuine effort is the drill: restoring into a fresh environment, verifying the data, timing it, and finding out what the document forgot. That is where the real recovery objectives come from and it is what will let this page carry numbers.
Until then, treat every backup claim on this page as what it is: a plan we believe in and have not tested. We would rather you hold us to that sentence than to a number we made up.
Questions
Do you have backups?
We have a documented backup and restore procedure. Automated platform backups, point-in-time recovery and object-storage versioning are deployment gates that have not been cleared, because Rydya has not yet been deployed to a production project. More importantly, no restore has ever been performed, and until one has, a backup is a belief rather than a capability.
What are your RPO and RTO?
We do not publish either, because an objective is a measurement and we have never measured ours. Writing plausible numbers here would be easy and no prospect would challenge them at evaluation, which is exactly why it would be dishonest. The number that matters is the one you get on the day, and it diverges from the plan for boring reasons discovered during incidents.
Where is our data hosted?
The hosting region is an open decision rather than an answer we are withholding, and residency commitments and cross-border posture go with it. If data residency is a hard requirement for your organisation, raise it before evaluating further, because it may mean we do not fit.
Would a restore let someone rewrite our history?
The audit trail is append-only and hash-chained with no update or delete path at the database, so history cannot be silently rewritten regardless of backup state. This is worth asking every vendor: what would a restore undo, and what could it be used to undo? That is where recovery meets evidence, and it is rarely on a backup page.
See it on your equipment
Live in an afternoon, useful the same week. A person replies, usually within one working day.
Contact us