Code, infrastructure and configuration
Rebuilt reproducibly from the repository. It needs no backup in the classic sense: it needs the rebuild to work, which is a property verified a different way.
The route to recovery is to rebuild, not to repair
All infrastructure — the cluster, the deployments and their configuration — is declared as versioned code, not configured by hand. In a serious outage the intended path is not to repair a damaged server but to stand the environment up again from code and restore the data onto it.
That design decision splits the problem into two halves with different treatments.
The data
Production data and database state cannot be regenerated. They are the real object of the backups, and the reason those are kept outside the cluster that produces them.
The practical consequence is that continuity does not rest on recovery manuals but on the environment being able to come back up. A documented procedure that has never been executed does not establish a recovery capability.
An outage degrades towards «no access», never towards «ungoverned access»
The policy enforcement point operates in deny-by-default mode. On failure or on doubt, it denies. That means an outage always shows up as a loss of availability, and never as access control opening up.
It is a deliberate choice and it is not free: it turns certain partial failures into unavailability. The alternative — degrading towards open access to preserve the service — is unacceptable in an infrastructure whose purpose is to govern who sees which data.
| Priority 1 | The governed consumption layer and its policy enforcement point. Without it the customer cannot query their data; with it degraded, neither is there ungoverned access. |
| Priority 1 | Customer production data. It is the asset whose loss is least tolerable and the one that drives the backup strategy. |
| Priority 2 | The identity and access plane. Without it nobody authenticates, which also blocks recovery itself. |
| Priority 2 | The execution substrate, and the code and secrets needed to rebuild. |
| Priority 3 | Internal support services, which tolerate longer recovery windows with no customer impact. |
Backup and verification criteria
The continuity plan sets the backup requirements for stateful systems, and establishes that their usefulness must be demonstrated by restoring them, not by the existence of a backup file.
| Independence | Backups reside on storage outside the cluster that generates them, so that losing the environment does not take its own backup with it. |
| Protection | Backups inherit the classification of the information they contain and, with it, its level of encryption and access control. No backup lowers the protection of the original data. |
| Verification | The plan is explicit: a backup never restored is not considered a backup. That is why periodic restore testing is part of the plan and not of its supporting documentation. |
| Proportionate redundancy | Redundancy is introduced in proportion to each service's maturity. Where there is no high availability, the declared compensating control is rebuilding from code onto a verified backup, with a recovery objective to match. |
The specific recovery objectives — restore time and maximum tolerable loss per service — the backup architecture and the state of each control are provided as part of the contractual documentation and the vendor review. We prefer not to publish them openly: they are operational information whose detail is of interest to whoever is assessing the service and equally to whoever might want to attack it.
Who recovers what
Continuity is split like every other control. The full detail is in the shared responsibility matrix.
Opendome recovers
Opendome runs recovery end to end: rebuilding the environment, restoring the data and verifying integrity before handing the service back.
An explicit split
Opendome runs recovery of the software and the platform. The destination, retention and residency of the backups belong to the customer on their own infrastructure, and are set in the agreement.
The operator's
Continuity is the responsibility of whoever operates the deployment. Opendome ships signed artefacts that allow the environment to be rebuilt from infrastructure declared as code.
What keeps working without us
The question a risk committee asks about any infrastructure provider is not only what happens if it goes down, but what happens if it disappears. With a proprietary product the answer depends on source code escrow clauses and on the provider's goodwill. Here it depends on the architecture.
Open and inspectable
The core of the platform is distributed under an open source licence. The rights to use, modify and redistribute do not depend on the continued existence of the company that develops it.
In standard formats
Storage uses open formats readable by any compatible engine in the ecosystem. The data remains usable with no prior conversion and no proprietary tooling.
Rebuildable from code
The same property that underpins our recovery serves the customer's: signed artefacts and a declared deployment allow the environment to be stood up with another operator.
It is not a contractual promise bolted onto a closed product, but a consequence of how it is built. It is the same reason you can audit what the system does instead of trusting that it does what it says.
Resilience review
A session with your risk team to review the recovery objectives applicable to your deployment model, the backup architecture and the documentation you need for your vendor file.
Request a technical meeting