Ceph backup and recovery design for DORA Article 12: what the platform covers
A financial entity under DORA must be able to show a documented backup policy, periodic tests of backup and restoration, and restore systems that are segregated from the source environment. Ceph can supply several of the storage features those controls depend on, but it does not write the policy, run the tests, or decide which functions are critical. DORA has applied since 17 January 2025 to 20 types of financial entity, and as a regulation it is directly applicable in every member state without national transposition. DeployOpen plans, builds and documents the Ceph side of this work and prepares the systems and evidence for your assessors. DeployOpen does not certify compliance, and no DORA attestation is issued by DeployOpen or by Ceph.
On the platform side, Ceph helps with the technical points in Article 12. Replication across failure domains, configured through CRUSH rules, protects against hardware loss, but replication is not a backup because a deleted or corrupted object is copied too. Separate backup targets, such as a second cluster or a multisite zone, along with RGW Object Lock on a dedicated bucket and separate administrator accounts, can support the segregation and immutability expectations in Article 12(3). The platform does not satisfy them automatically, so you will need to confirm the configuration against your own threat model and record how each target is isolated from the source system.
Several Article 12 duties remain organizational. Your team must set backup frequency by criticality, assign recovery time and recovery point objectives to each business function, define the checks and reconciliations performed during recovery, and schedule restore tests that show those objectives can be met. Ask your DeployOpen scope to produce the Ceph configuration evidence, restore runbooks and test records, and map them to the Article 12 subsections you need, but confirm with your compliance function and competent authority how they expect the evidence to be presented.
Mapping DORA Article 12 requirements to Ceph capabilities and configuration
This table maps the Article 12 backup, testing, segregation and recovery obligations to what Ceph can provide, the configuration each one needs, and what stays with your organization. Read each row as a question to answer with evidence from your own cluster. Ceph supplies replication, identity and encryption building blocks, but the policy, recovery objectives and sign-off remain your responsibility.
| Requirement | Ceph capability | Configuration needed | Outside the platform |
|---|---|---|---|
| Art. 12(1): documented backup policy by criticality | Replication and snapshots can be scoped to pools, buckets and images, so tiers can follow function criticality | One tier per critical function, mapped to pools or buckets, with snapshot and copy schedules. Confirm scoping options for your release | Setting scope and minimum frequency by criticality, and approving the policy |
| Art. 12(2): periodic testing of backup and restoration | RGW and RBD interfaces can restore into a test target, so drills run against the same storage stack | Scheduled restore drills into a test pool or zone, with logged results and failure handling | Choosing test frequency, acceptance criteria and independent review of results |
| Art. 12(3): segregated restore systems | RGW IAM and STS APIs, Keystone or LDAP authentication, and msgr2 secure mode for encrypted traffic | Separate restore cluster or failure domain, separate backup administrator identities, msgr2 secure mode enabled | Physical and network separation from the source site, and periodic access reviews in your identity system |
| Art. 12(3): protection from unauthorized access or corruption | Object Lock on RGW buckets can block changes during retention. Confirm availability and behavior for your release | Enable Object Lock at bucket creation, set retention per tier, limit delete rights to a separate account | Off-network or offline copies, and legal hold decisions |
| Replication versus backup | Multisite and CRUSH replicas protect against hardware loss but copy deletions and corruption to every replica | Keep a separately retained copy with its own retention and delete controls, outside the replication path | Choosing the location and custody of any third-party or off-site backup copy |
| Art. 12(6): recovery time and recovery point objectives per function | Replication lag sets the achievable recovery point, and measured restore throughput sets the recovery time | Measure replication lag and restore duration in drills, then record results per function | Business impact analysis and the RTO and RPO values approved for each function |
| Art. 12(7): checks and reconciliations during recovery | Cluster health output, scrub results and object listings can be compared before and after a restore | Checksums or manifests stored outside the cluster, reconciliation scripts run after each drill | Application-level reconciliation of transactions and sign-off by data owners |
Why replication across sites is not a backup under DORA
Replicated copies are not backups, because replication faithfully copies whatever reaches the source. A deleted bucket, a corrupted RBD image or a ransomware-encrypted CephFS tree will be propagated to every replica, whether the replicas sit in the same rack or in a second data center. Article 12(3) of DORA expects restore systems to be physically and logically segregated from the source system and protected from unauthorised access or corruption. A Ceph cluster that replicates across failure domains or sites, including through multisite zones, meets availability goals but does not by itself meet that segregation test. Decide early which copy is the recovery target and treat every other copy as availability infrastructure.
CRUSH failure domains answer a different question from recovery. They decide where Ceph places replicas or erasure-coded chunks so that a host, rack, room or site failure leaves data reachable, and they are tuned for capacity and fault tolerance. A recovery target has to answer whether an earlier, unaltered version can be restored after logical damage. Those requirements push the design toward a separate backup path with its own credentials, its own retention rules and, for object data, RGW Object Lock with retention set in a way that the daily cluster administrators cannot override. Confirm with your Ceph version and RGW configuration which retention and lock behaviors apply before you rely on them in the design.
In practice, this means separate administrative access for the recovery target: different Ceph users or Dashboard roles, different host access and different change approval from the production cluster. Ask your team to document which identities can delete snapshots, modify buckets or change retention, and to test whether a compromised production administrator could reach the recovery copy. Those answers become the evidence Article 12 testing will examine, so record them alongside the restore tests and the RTO and RPO targets for each function.
Choosing a segregated recovery target by function
A separate Ceph cluster in another site gives a restore target that does not share control planes, monitors, managers or credentials with the source. Replication between clusters, such as RBD mirroring or RGW multisite, keeps the target current, which helps against site loss and hardware failure. It does not, by itself, protect against a logical attack or a bad change that replicates to both sides, so it should be paired with a retention or immutability mechanism elsewhere.
- Isolation boundary: Confirm that the second cluster has its own monitors, admin keys and cephadm host access, and that no shared identity provider or automation pipeline can administer both.
- Replication lag: Replication is asynchronous in many designs, so the achievable recovery point depends on link capacity and write volume. Measure it under load.
- Recurring cost: Hardware, rack space, power, network circuits, licensing for any surrounding tooling, and staff time for patching and capacity planning recur for as long as the cluster runs.
- Failover drills: The restore path must be exercised, including DNS, certificates and application configuration, not only the storage layer.
- Capacity reserve: Size the target for the restore workload, not only for steady-state replication.
Before relying on this option, confirm with the Ceph documentation which mirroring or multisite mode fits your replication model and how it handles deletes.
An RGW bucket with Object Lock, owned by a separate backup administrator account, keeps recovery copies on the same cluster but moves write and delete rights to an identity the production administrators do not hold. Retention rules then limit what anyone can remove during the retention period. This separates the backup control plane from production, but it shares the physical cluster, so hardware, monitor or site failures still affect both copies.
- Account separation: The backup administrator should use distinct users and keys, with policies that deny production administrators access to the bucket configuration and lock settings.
- Lock configuration: Confirm in the RGW documentation how Object Lock modes and default retention are set, and whether they can be changed or shortened by any principal.
- Storage overhead: Retained object versions consume capacity for the full retention window, so cost tracks change rate and retention length.
- Restore verification: Test restores through the same S3 endpoint and credentials the recovery team would use during an incident, including the case where the production account is unavailable.
- Key and certificate dependencies: Identify where S3 credentials are stored, since a compromised secret store can expose the backup account.
Illustratively, a bucket for a critical function might hold daily full copies under a fixed retention period, but the actual lock mode and cluster-level controls must be checked against your retention policy and the current RGW release.
An air-gapped or off-network copy is written to media or a system with no persistent network path to production, so an attacker with production access cannot reach it through normal connectivity. This gives the strongest logical separation and suits the most severe threat scenarios. The trade-off is that the copy is usually older, restores take longer, and the transfer process itself becomes a control that must be operated and evidenced.
- Transfer window: Define when and how the copy is refreshed, and how that window is kept closed the rest of the time.
- Operational friction: Manual or scheduled transfers add staff steps, change tickets and approvals, which recur at every cycle.
- Restore speed: Bringing data back from an off-network copy often takes longer than from an online target, so the RTO for critical functions must account for it.
- Integrity checks: Record checksums at export and verify them at import, and reconcile record counts against the source, as Article 12(7) reconciliation expectations require.
- Media lifecycle: Plan for media replacement, encryption key custody and secure destruction.
Check with the Ceph documentation which export mechanisms fit your data types, and confirm with your own environment how the off-network path is physically and logically isolated.
Configuring Ceph backup and restore testing for Article 12
This sequence turns DORA Article 12 expectations into a working Ceph setup: defined recovery targets, a written backup policy, a segregated recovery target, immutable retention where supported, and restore tests whose results are recorded as evidence. Your organization owns the business decisions in the early steps, and DeployOpen configures the platform in the middle steps.
Classify functions and set RTO and RPO
Your business continuity and risk owners list the financial functions in scope, classify each by criticality, and set a recovery time objective (RTO) and recovery point objective (RPO) per function, as Article 12(6) expects. DeployOpen reviews the list against the storage workloads that support each function so that the targets are technically reachable on the planned Ceph layout. Done means each function has a signed RTO and RPO and a named owner, and every data set it depends on is mapped to a pool, bucket or image.
Write the backup policy and scope
Your information security and operations leads write the documented backup policy required by Article 12(1). It sets the scope of each data set, the minimum backup frequency by criticality, retention periods, and who approves changes. DeployOpen drafts the technical annex describing which Ceph features carry each backup, such as RBD snapshots, RGW replication or an external backup tool. Done means the policy is approved and every in-scope data set has a stated frequency and retention.
Deploy the segregated recovery target
DeployOpen deploys the recovery cluster or recovery pools with cephadm in infrastructure you control, separate from the source system with its own hosts, monitors, network segment and administrative accounts, as Article 12(3) requires. Your team confirms that the recovery environment cannot be reached with source-system credentials and that access is limited to named roles. Done means a documented network and access diagram exists and a test credential from the source environment is refused on the recovery side.
Separate backup administrator accounts
DeployOpen creates distinct accounts for backup writing, backup reading and recovery operations, and removes standing rights from routine administrators on the backup side. Your security team checks that multi-factor authentication applies to privileged access and that account changes are logged. Ceph's own authentication and the dashboard settings are reviewed against your security hardening baseline. Done means an access matrix lists each account, its rights and its owner, and the matrix has been reviewed by someone outside the platform team.
Enable immutability where the platform supports it
Where your Ceph version and the backup path support it, DeployOpen configures object retention on RGW buckets, including Object Lock settings, so backup copies cannot be altered or deleted during the retention period. Where a feature is not available for a given pool or workload, the design records the compensating control, such as an off-network copy or a restricted administrator account. Your team confirms the feature against the release it runs on. Done means a test write cannot be deleted before its retention expires and the exceptions list is approved.
Schedule restore tests with reconciliation checks
Your operations team and DeployOpen agree a restore test schedule that covers each function's criticality tier, as Article 12(2) requires periodic testing of backup, restoration and recovery procedures. Each test restores data to the segregated target, then runs reconciliation checks such as record counts, checksums and application-level validation, which Article 12(7) expects during recovery. Done means the schedule is approved and the first test has produced a comparison report showing the restored data matches the source within the agreed RPO.
Record results and close gaps
Each restore test result is written up with the date, scope, measured recovery time, reconciliation outcome and any defect found, then reviewed against the RTO and RPO for that function. DeployOpen supports the write-up and fixes configuration issues, and your team decides on risk acceptance for anything not closed. Done means the evidence pack for each test is stored where your auditors can access it, and open gaps have owners and due dates in your risk register.
Evidence Ceph produces for DORA backup reviews and how to keep it
A DORA backup review is a question about evidence: can you show the policy, the targets, the tests and the account controls that held when a restore was needed. Ceph produces some of this material as a by-product of operations, but none of it is a finished audit report, so the financial entity must decide who writes, approves and retains each record.
Backup policy document
Article 12(1) expects a documented backup policy that sets scope and minimum frequency by criticality. Examiners test whether the policy names which Ceph pools, RBD images, CephFS volumes and RGW buckets are covered, how often each class is copied, and which copies sit on a separate failure domain. Ceph does not write this policy for you. The risk owner signs it, and the platform team retains it with the change record for each revision.
RTO and RPO register per function
Article 12(6) requires recovery time and recovery point objectives set per function, not per cluster. The register should map each business function to the Ceph storage it depends on, the target recovery time, the target recovery point and the snapshot or replication interval that makes the point achievable. Examiners will compare these figures with restore test results, so the business owner signs the register and the platform team confirms each interval is actually scheduled.
Restore test records with reconciliation
Article 12(2) requires periodic testing of backup, restoration and recovery, and Article 12(7) requires checks and reconciliations during recovery. A useful record names the restored source, the target cluster or pool, the date, the measured time to usable service, and the reconciliation result, such as object counts, checksums or application-level row checks. Failed restores belong in the record with the remediation and the retest date. The operations team retains these records, and the function owner reviews them.
Segregation and account records for recovery systems
Article 12(3) requires restore systems to be physically and logically segregated from the source system and protected from unauthorised access or corruption. Keep records of the separate recovery cluster or failure domain, the Ceph and RGW users and keys that can write to backup pools, the administrators allowed to delete or change retention, and the review of those accounts. Examiners test whether the same identities can both write production data and erase its backups. Security and identity teams retain these records.
Configuration exports and cephadm change history
Examiners test whether the restore environment can be rebuilt as it was documented. Export the cluster configuration, CRUSH map, pool settings, replication and erasure coding profiles, and RGW policies on a schedule, and keep the cephadm service specifications under version control. Each change should link to a ticket and an approver. Ceph does not supply an audit report, so the entity or its platform partner must assemble this history and decide the retention period with its compliance team.
Incident and recovery logs
Article 12 testing and Article 17 incident handling both depend on a timeline of what failed and what was done. Record each recovery event with the detection time, the Ceph health state at the time (for example, degraded or inconsistent placement groups), the actions taken, the data restored, and the decision to declare recovery complete. Logs from the monitors, OSDs and RGW should be kept off the cluster being recovered. The incident owner and the operations team retain them together.
Questions buyers ask about Ceph and DORA backup design
How much effort does a Ceph backup design for DORA Article 12 take?
The effort depends on how many functions need recovery objectives, how many sites hold copies, how much data each function owns, and how long backups must be kept. Each of these multiplies the work. A design covers the backup policy by criticality, the segregated recovery target, the immutable copy approach, the restore test plan and the RTO and RPO per function. A single site with a few critical services is a small exercise. Several sites, many functions with different retention, and large RGW or RBD datasets take considerably longer, because each dataset needs its own copy path and its own restore test. Ask for the effort split by function and by site in any written scope, so you can see which items drive the total.
Can our own team design Ceph backups for DORA without a partner?
Yes, if the team already runs Ceph in production and has someone who can own the recovery design. The harder parts are not the Ceph commands. They are the business decisions: which functions are critical, what downtime and data loss the business accepts, and how restores are proven to work. Teams that lack recent Ceph operations experience, or that have not run a full restore test on the same platform, usually find the restore testing and the segregation of recovery systems the most demanding steps. A partner can take on the design, the documentation and the test evidence, while your staff keep ownership of the decisions and the running system. Compare both options against your current staffing and skills before deciding.
What does DeployOpen need from our team during a backup design engagement?
A backup design cannot be finished without decisions only your organization can make. Expect to provide a list of business functions with their criticality ratings, named owners who can sign off RTO and RPO values per function, and access to the current Ceph cluster or its planned architecture. You also need to set test windows, since restore tests on production-like data affect capacity and sometimes service availability. Your security and risk teams should review the segregation of recovery systems and the access model for backup administrators. Agree these inputs in the written scope, with named people and dates, because a missing sign-off is the most common reason a design stalls.
How long does a Ceph backup and recovery design take?
The timeline is set by the number of functions needing sign-off, the number of sites, the state of the existing cluster and the availability of test windows. Decision workshops on criticality and objectives often take longer than the technical build, because they depend on people outside the platform team. Restore tests also need time to schedule and repeat. No fixed duration applies to every organization, so the written scope should give phases with dependencies, the people each phase needs, and the dates your side must meet. Ask for a timeline that separates design sign-off from test execution, since the two can run at different speeds.
Does Ceph alone meet the backup requirements of DORA Article 12?
No. DORA Article 12 sets obligations for documented backup policies, periodic testing of backup and restoration, segregated restore systems, RTO and RPO per function, and reconciliation checks during recovery. Ceph provides replication, snapshots, object versioning and Object Lock, and these can support parts of that design. Replication alone is not a backup, because it copies deletions and corruption as quickly as valid data. Segregation, immutability, restore testing and the governance records are organizational and procedural controls that Ceph does not supply by itself. Your compliance function decides how the requirements apply to your entity, and the supervisor reviews the evidence. DeployOpen prepares systems, controls and evidence for assessment but does not issue audit reports or attestations.
What should a quote for a Ceph DORA backup design state?
A quote should follow from a written scope, and the scope should list what is in and out. It should name the deliverables, such as the backup policy, the recovery architecture, the RTO and RPO register by function, the restore test plan and the evidence pack. It should state the assumptions about your existing cluster, the number of sites, the data volumes in scope and the test windows. It should list who must provide input and approvals, the timeline by phase, and what happens if a dependency slips. Separate one-time design work from any recurring support, restore testing or retained services. DeployOpen does not publish a price list, so ask for the quote to show how each deliverable maps to the scope.
Which Ceph settings should engineers check first for recovery targets?
Start by confirming which copies are truly independent. Check the replication factor and failure domains in the CRUSH map so that copies are spread across the hosts, racks or sites you intend. Review the RGW versioning and Object Lock configuration for the buckets that hold backups, and confirm that the credentials able to delete them belong to a separate administrative account. For block and file data, confirm which snapshot and mirroring jobs exist, where they write, and how long they are retained. Test a restore into the segregated recovery target and measure the time it takes against the RTO you agreed. Record the results, because the restore test is the evidence that the design works.
How a DORA backup scope is agreed before work starts
DeployOpen typically agrees a DORA backup scope in writing before any build starts, and the document covers more than the storage cluster itself. It names the functions in scope, the recovery time and recovery point objectives set for each one, the target architecture for the Ceph backup and recovery design, the testing approach, the evidence deliverables, and a clear list of what stays with your organization or its auditors. For Article 12, that list matters as much as the technical design. Your team sets the criticality classification and the minimum backup frequency that feed the documented backup policy under Article 12(1), and the business owners of each function confirm the recovery objectives. Our work covers the platform: separate recovery targets with the segregation Article 12(3) asks for, replication and backup configured as distinct controls, immutable copies, and restore procedures your team can run. Confirm early which party signs off each objective, because a scope that leaves that open tends to stall at the first restore test.
Fixed-scope work suits the design phase, but restore testing repeats. Article 12(2) expects periodic testing of backup, restoration and recovery procedures, so after handover many clients keep a retainer for scheduled restore tests, reconciliation checks after recovery and updates to the procedures as the cluster changes. Ask any partner, including us, to state in the written scope which tests run in the retainer, who records the results, how failed tests are reported, and what evidence is handed over for the register and for supervisory review. Also ask which parts of the DORA obligations remain with your compliance function, such as the classification of ICT services, contractual terms under Article 30(2), and the exit strategies under Article 28(8). DeployOpen prepares the systems, controls and evidence, but it does not issue audit reports or attestations, so the scope should say so in plain terms.
How DeployOpen designs and evidences Ceph backup for DORA
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Ceph backup and recovery designs. For DORA Article 12, the work starts with written scope and ends with documented procedures, restore evidence and a support path that the client's team can run.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope maps each critical function to its recovery time and recovery point objectives and the backup scope it needs.
- Scope identifies which Ceph pools, buckets and images hold data the backup policy covers, and which copies sit on separate infrastructure.
- The scope lists the evidence you will receive, such as configuration records, restore test results and reconciliation procedures.
How we build
- We design replication, backup targets and immutable copies as separate layers, so a single failure or admin account cannot remove every copy.
- Restore targets are planned as segregated systems with their own access controls, following the separation Article 12(3) describes.
- We configure Object Lock retention, separate backup administrator accounts and msgr2 secure mode where the design requires them.
- Restore runbooks are written and rehearsed against the agreed objectives before handover, with checks and reconciliations included.
How we hand over
- You receive the backup policy, recovery architecture, configuration records and runbooks written for your operations team.
- Restore test reports record what was restored, how long it took, what was reconciled and which gaps remain open.
- Documentation maps controls and procedures to DORA Article 12 so your internal audit and the competent authority can trace the evidence.
- Knowledge transfer sessions cover daily monitoring, backup job failures and how to run a restore without the DeployOpen team.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the original engagement.
- Periodic restore tests can be scheduled under a retainer so the periodic testing Article 12(2) requires continues after go-live.
- Ceph upgrades are planned against the releases that are actively maintained, so backup tooling stays supported over time.
- DeployOpen prepares systems and evidence for assessments. Independent auditors and supervisors make the final determination, and we do not issue attestations.
