How Ceph helps meet NIS2 backup and redundancy requirements
If you are an essential or important entity under NIS2 and run or plan Ceph, the short answer is that Ceph can support the backup and redundancy duties in point 4.2 of the Annex to Implementing Regulation 2024/2690, but it cannot make you compliant on its own. NIS2 creates no certificate of compliance, so supervisors and auditors will judge the evidence you produce, not the software you chose. Ceph's contribution is mostly technical: replication across failure domains, which you design with CRUSH, keeps data available when drives, hosts or racks fail, and msgr2 secure mode encrypts and integrity-checks traffic between daemons and clients after authentication. Redundancy across sites depends on how you design the cluster or set up multisite replication, and you should confirm the exact behavior of each option against the Ceph Object Gateway documentation for your release.
Several points of 4.2 depend on your backup policy rather than on storage features. Replication is not a backup: a deleted or corrupted object is copied faithfully to every replica, so a backup plan under point 4.2.2 must still provide complete copies, including configuration data, stored off the system's network and far enough from the main site. Those copies may live on a separate Ceph cluster, an independent storage system or tape, and the choice drives the cost and the recovery time you can promise. Retention periods, access controls that keep backup administrators separate from production administrators, and the restore process are decisions your organization owns and must document.
Point 4.2.3 and 4.2.6 require regular integrity checks on backup copies and regular recovery tests, with results recorded. Ceph's scrubbing and checksum behavior help detect inconsistent data inside the cluster, but you still need to define what your integrity checks cover, how often they run, and which logs and restore test records prove they happened. ENISA's June 2025 guidance lists backup logs, evidence of off-site copies, checksum settings, restore test records and a backup plan review that references the 3-2-1 rule as examples of evidence, which gives you a practical checklist. Ask your auditor or competent authority early which evidence format they expect, because the same records can satisfy different frameworks.
Mapping points 4.2.2, 4.2.3 and 4.2.6 to Ceph features
This table maps each backup plan element in point 4.2.2, the integrity checks in point 4.2.3 and the recovery tests in point 4.2.6 to Ceph capabilities and the evidence an assessor can review. Read the middle column as the configuration to build and the last column as what Ceph covers only in part. The main takeaway is that Ceph provides replication, scrubbing and access controls, while recovery objectives, off-site policy and test records remain your responsibility.
| Requirement | Ceph capability and configuration | Evidence to keep and coverage |
|---|---|---|
| 4.2.2: Recovery times | Set a recovery time objective per service, then size OSDs, network and RGW capacity to meet it | Documented recovery targets and measured restore times. Partly covered: Ceph does not set your objectives. |
| 4.2.2: Complete copies including configuration data | RGW multisite or RBD mirroring for data, plus a dated export of cephadm service specs and cluster configuration to a separate store | Copy inventory and configuration export records. Partly covered: replication does not capture host OS settings or runbooks. |
| 4.2.2: Storage off the system's network | Separate backup network with bonded links across two switches, and a backup target reachable only through a controlled path | Network diagrams, firewall rules and access paths. Partly covered: isolation depends on your network design. |
| 4.2.2: Distance from the main site | CRUSH failure domains set at site or room level, and RGW multisite zones or a second cluster in another location | CRUSH map and rule exports, site list with distances. Gap: the distance target is a policy decision you must set. |
| 4.2.2: Access controls | Dedicated backup client keys with scoped cephx capabilities, RGW user and bucket policies, and Dashboard SSO through SAML 2.0 or OAuth2 Proxy | Client key listing, capability reviews and SSO settings. Partly covered: replication accounts need separate scoping. |
| 4.2.2: Restoration and retention periods | RGW lifecycle rules and Object Lock on backup buckets where supported, plus snapshot retention schedules for RBD and CephFS | Retention schedule, lifecycle configuration and lock settings. Confirm Object Lock behavior in your Ceph release. |
| 4.2.3: Integrity checks on backup copies | Regular scrubbing and deep scrubbing of stored data, and msgr2 secure mode for integrity checks on traffic | Scrub logs and health history. Partly covered: scrubs check stored objects, not your backup-level checksums. |
| 4.2.6: Recovery tests of backups and redundancies | Scheduled restores into an isolated pool or cluster, and drills that remove an OSD, a host or a whole site | Dated test records, restore durations and drill results. Partly covered: Ceph does not run or record tests for you. |
Choosing a redundancy design across sites
A single-site Ceph cluster protects against the failure of individual drives, hosts and network paths inside one facility. Ceph's hardware recommendations advise a dedicated drive per OSD, moving WAL and DB onto shared SSDs for HDD-based OSDs, using enterprise-class SSDs for metadata, and bonding network links across two switches. These choices reduce the chance that one component failure takes down a pool, but they all sit in the same building, power feed and cooling domain. A fire, flood, power loss or site-wide ransomware event can affect every copy at once.
- Drive and host loss: Replicated or erasure-coded pools with failure domains set to host or rack can survive planned losses without data loss, provided the cluster has spare capacity to recover.
- Shared SSD for WAL and DB: Losing a shared SSD takes down every OSD that depends on it, so the failure domain for that SSD must be treated as one unit in your design.
- Dual-switch bonding: Bonded links across two switches protect against a single switch or port failure, not against loss of the room or the upstream provider.
- Memory sizing: Size OSD memory for peak use, because recovery after a failure is when memory demand spikes.
- Site-level exposure: Everything in this design shares one site, so it does not satisfy a requirement for storage off the system's network and far enough from the main site.
Before accepting this design for backup purposes, confirm with your auditor whether it counts as redundancy only, and document which events it does not cover.
Two sites with RGW multisite replicate object data between two Ceph clusters, which lets a second facility take over service when the first is lost. The Ceph Object Gateway documents multisite configuration, and this design helps with site-level outages that a single-site cluster cannot survive. Multisite replication is a continuity mechanism, though. Changes, deletions and corruption can replicate to the second site as quickly as valid writes do, so it does not provide a point-in-time copy you can roll back to.
- Site loss: A second site with current data supports service continuity when the primary facility is unavailable.
- Logical error propagation: Accidental deletion, a bad application write or an attack that encrypts objects can replicate to the secondary site.
- Distance and latency: Confirm the distance between sites meets the regulation's expectation for storage far enough from the main site, and confirm the link latency is acceptable for your write pattern.
- Access separation: Both sites share an administrative trust domain unless you deliberately separate it, so review who holds credentials on each side.
- Evidence: Replication status and sync logs help show that redundancy works, but they do not replace restore tests.
Ask the implementation team to show how the second site is monitored for sync lag and how a failover is tested and recorded.
An off-network copy target is a backup repository that is logically or physically separated from the production network and its administrative accounts. It addresses the gap that replication leaves open: a versioned, point-in-time copy that an attacker or a faulty change cannot reach through the production control plane. Under point 4.2.2 of the Annex to Implementing Regulation 2024/2690, backup copies must be stored off the system's network and far enough from the main site. Ceph can host such a target, but the separation must be built and controlled deliberately rather than assumed.
- Separate network and credentials: Place the target on a network segment and under administrator accounts that production systems cannot reach or change.
- Immutability: Use retention controls such as RGW Object Lock where the design calls for it, and confirm how retention is enforced and who can override it.
- Complete copies: Include configuration data along with the data itself, so a restore is possible without rebuilding settings from memory.
- Integrity and restore testing: Run regular integrity checks and record restore test results, because the target is only useful if restores succeed.
- Geographic distance: Choose a location that is far enough from the main site to survive the events you have assessed.
Before you sign off, ask for the access model, the retention settings and a written restore test procedure for this target.
Most regulated organizations combine these designs rather than choose one. The right mix depends on the services in scope, the recovery times you have set, and the events your risk assessment considers credible. A single-site design with a separate copy may suit a smaller entity whose services can tolerate a longer outage, while a larger entity may need a second site for continuity and an off-network copy for recovery from logical attacks. This is a decision for your risk owners, and the outcome should be written down with the reasons.
- Continuity needs: Services with short tolerable outages point toward a second site with multisite replication.
- Recovery from corruption or attack: Services where a bad state must be rolled back point toward an off-network copy with retention.
- Budget and staffing: A second site and a separate target each add hardware, licensing, networking and operating effort, which should be quoted separately.
- Ownership of each layer: Assign who operates replication, who operates the copy target and who runs restore tests.
- Documented reasoning: Record which events each design covers and which it leaves to other controls.
Check that the chosen mix matches the recovery times and retention periods in your backup plan, and that the evidence listed by ENISA can be produced for each layer.
Evidence auditors and ENISA examples ask for from a Ceph estate
The ENISA June 2025 guidance names concrete evidence examples for backup and redundancy. Most of them can be produced from Ceph's own outputs, but only if someone collects, dates and retains them on a schedule. The cards below map each example to the Ceph source that supports it and the checks to run before an assessment.
Backup logs from the copy job
Backup logs show that copies ran, when they ran, and whether they succeeded. In a Ceph estate these logs come from the tool that writes the copies, such as RBD mirroring, RGW multisite sync or your backup software writing to an RGW bucket, so the log source must be named in the plan. Confirm that each job writes a timestamped record to a location the backup administrators cannot edit, and that failed runs leave a record too.
Proof of off-site copies
The rule requires storage off the system's network and far enough from the main site. For Ceph, keep a record of the target cluster or zone name, its physical location, its network path and the replication status reported at the time of review. A multisite sync status output captured on a known date is stronger evidence than a diagram, because it shows the copy existed and was current.
Checksum and scrub settings
Integrity checks on backup copies need documented settings. In Ceph, record the scrub and deep-scrub intervals in effect, the checksum behavior of the pools holding backup data, and any overrides applied per pool. Export the current configuration with the cluster configuration commands and store it with the change record, so an auditor can see what was set and when it changed.
Scrub and cluster health reports
Regular integrity checks produce results that should be kept. Save the cluster health output and the scrub results for each reporting period, and record any inconsistent placement groups with the date they were repaired and the repair command used. Gaps in these reports are the first thing a reviewer will ask about, so set an owner for the weekly export and alert on missed exports.
Restore test records
Restore tests need a record of what was restored, from which copy, to what target, how long it took and whether the result matched expectations. For RBD images, record the snapshot or mirror used. For RGW objects, record the bucket, object version and checksum compared. Keep these records next to the scrub and sync evidence, because the reviewer will look for them together.
Dashboard and audit logs
Access and change logs show who altered backup configuration, who read backup data and who approved a change. Ceph Dashboard activity, manager and monitor logs, and the logs of your identity provider should be forwarded to a store that backup administrators cannot edit. Confirm which Dashboard login method is in use, because single sign-on through SAML 2.0 or OAuth2 changes where the authentication record lives.
Backup plan review and dated configuration
The ENISA guidance lists a backup plan review that refers to the 3-2-1 rule. Keep the plan as a versioned document, and attach an export of the cephadm service specifications and host configuration for each review date. A reviewer can then compare the plan with the cluster as it actually ran, and the dated export shows which changes were made between reviews.
Configuration sequence for a NIS2-ready Ceph backup design
This sequence turns the backup, redundancy and evidence requirements of Implementing Regulation 2024/2690 into an ordered Ceph build, so each control is configured once and leaves a record an assessor can check. It is a planning order, and each step should be confirmed against your own sites, release line and national transposition law.
Define the backup plan and recovery targets
Start with a written backup plan that names the systems in scope, the recovery time and recovery point targets for each, the retention periods, and who may access backup data and administer the backup environment. Your risk owner and the teams that run the workloads should sign off on these targets before any Ceph pool or bucket is created, because every later choice depends on them. Confirm which Ceph release line you will run: Squid (19.2.x) or Tentacle (20.2.x), checking the end-of-life dates on the Ceph releases page against your planned operating period. The step is done when the signed plan lists targets per system and the chosen release line.
Size failure domains and the second site
Map CRUSH failure domains to the racks, rooms and sites that can fail together, and choose a replication or erasure-coding scheme that keeps copies in separate domains. Place at least one complete copy of backup data in a location off the production network and far enough from the main site to survive the same event, which means confirming the distance and power, network and administrative independence with your facilities team rather than assuming it. Use the Ceph hardware recommendations to plan bonded links across two switches and dedicated OSD drives. The step is done when a documented CRUSH map and site diagram show where each copy lives and which single event would remove it.
Enable msgr2 secure mode
Set the messenger protocol to msgr2 with secure mode so that inter-daemon and client traffic after authentication is encrypted with AES-GCM and carries integrity checks. Apply the setting to every monitor and OSD, confirm that clients on the backup path use a version that negotiates secure mode, and record the configuration keys you changed. Verify on the wire or in daemon configuration that secure mode is active between the sites that carry backup copies. The step is done when the configuration export and a connection check show secure mode on every path that moves backup data.
Configure RGW multisite or a separate backup target
Choose between an RGW multisite zone for the off-site copy and a separate backup cluster or pool, then restrict access with distinct credentials for the backup writer, the replication process and the administrators. Keep backup administrators separate from production administrators, and confirm the multisite features you need, including the authentication options Ceph Object Gateway documents, in the release you chose. Enable access logging on the gateway so that writes, deletes and key use leave records. The step is done when a test account can write to the backup target, production credentials are rejected there, and the access list is written down.
Enable integrity checks and scrub reporting
Turn on regular deep scrubbing for the pools that hold backup copies and set a schedule that your plan defines. Configure the reporting that records scrub results, scrub errors and any inconsistent placement groups, and route those alerts to the people who must act on them. Document how you verify checksums for backup objects, including any application-level checksums your backup tool writes, so that the integrity check covers the copy and not only the storage layer. The step is done when a scheduled scrub has run, its results are stored in a location you can retrieve, and an injected test alert reaches the on-call team.
Export the cephadm configuration
Export the cephadm-managed cluster specification, the service definitions, the configuration database and the host inventory to version-controlled storage, and repeat the export after each change. Record the Ceph version, the container image, and the list of hosts and daemons so that a rebuild can reproduce the environment. Store the exports and the cluster's recovery procedure separately from the cluster they describe, under the same access controls as the backup data. The step is done when a fresh export can be read back, the restore procedure names where it is held, and a reviewer has confirmed the export is complete.
Schedule and record restore tests
Write a test schedule that covers restores from the on-site and off-site copies, and includes at least one full restore of a representative system into an isolated environment. For each test, record the start and end time, the data restored, the checksum comparison, the measured recovery time against the target, and the person who approved the result. Include a test of the redundancy path, such as failing a host or site in a controlled exercise, and document what the cluster did. The step is done when the first test record is complete, shows whether the target was met, and lists any remediation with an owner.
Set up evidence retention and plan review
Define which records you keep (backup logs, evidence of off-site copies, checksum settings, scrub reports, restore test records and configuration exports), where they are stored, how long they are retained, and who can change them. Set a recurring review of the backup plan that compares the current targets, site map and release line with what the environment actually does, and record each review and its changes. The ENISA technical guidance of June 2025 lists these kinds of records as evidence examples, so map each record to the requirement it supports. The step is done when an evidence index links every requirement to a dated record and the first review is booked on the calendar.
Questions buyers ask about NIS2 and Ceph backup
Does NIS2 require a specific backup product or storage platform?
No. NIS2 is a directive, so it sets outcomes that entities must meet through national transposition laws, and Commission Implementing Regulation (EU) 2024/2690 describes the technical and methodological requirements without naming a product. Ceph is one way to meet the requirements, alongside other storage and backup tools. What matters is whether your backup plan covers recovery times, complete copies including configuration data, storage off your network and far enough from the main site, access controls, restoration and retention periods. Confirm with your national competent authority how the rules apply to your entity.
Does Ceph replication count as a backup under NIS2?
Usually not on its own. Replication keeps data available when a disk, host or site fails, but it copies changes and deletions along with the data, so a corrupted or deleted object can be replicated too. Point 4.2.2 of the Annex to Implementing Regulation 2024/2690 expects separate complete copies stored off the system's network, which is why most designs pair Ceph replication or stretch clusters with independent backup copies, such as RGW Object Lock retention or snapshot exports to a segregated target. Your design should treat replication as redundancy and the separate copy as the backup.
How much effort do the design and evidence work take, and what drives it?
The effort depends mainly on how many systems fall under the backup plan, how many sites you run, how many restore scenarios you need to test, and how much evidence you already produce. Each system needs a defined recovery time, a copy strategy, access controls and retention rules, then an integrity check and a recovery test schedule. Evidence collection adds work if logs, checksum settings and restore test records are not kept consistently. Ask any partner for a written scope that lists systems, sites, restore scenarios and evidence items so the quote can be compared line by line.
What does the work need from our team?
You need named owners for the business systems being protected, someone who can approve recovery time and recovery point targets, and engineers who can grant access to the Ceph hosts, network segments and any external key management service. You also need the current backup policy, retention requirements, network diagrams and previous restore test records if they exist. Plan time from your change board and your storage and security teams for reviews and test windows, because restore tests usually touch production-adjacent systems.
Can our in-house team design and run this without a partner?
Yes, if your team already runs Ceph in production and has experience with backup design, restore testing and audit evidence. The skills that are often thin in-house are documenting restore tests in a form auditors accept, separating backup administration from production administration, and aligning the Ceph configuration with the controls a regulator will ask about. A partner can cover one or more of these areas, or review your plan, while your team keeps operational ownership. Compare both options against the same written list of deliverables.
How long does the work take, and what drives the duration?
Duration depends on the number of sites, the number of systems in the backup plan, whether the Ceph clusters already exist or must be built, and how many restore tests must be run and repeated. Hardware lead times, change approval cycles and the time needed to fix issues found in testing often take longer than the design itself. No supplied fact gives a standard duration for this work, so ask for a timeline in the written scope with milestones for design review, build, restore testing and evidence handover.
Can DeployOpen certify that we comply with NIS2?
No. NIS2 does not create a certificate of compliance, and national competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. DeployOpen plans, implements and documents the systems and evidence that support these obligations and can prepare your backup and redundancy evidence for review. Audit reports, attestations and certifications are issued only by independent auditors and certification bodies, and you should confirm with your authority which assessments apply to your entity.
Which entities this applies to and what the directive timeline means
Start by establishing whether your organization is in scope at all. NIS2 is *Directive (EU) 2022/2555*, and a directive binds entities only through the national laws that Member States adopt to transpose it. Those laws decide how sectors are applied, which entities are named, and which authority supervises them. In-scope entities are classified as essential or important under Article 3 of the Directive. Both classes face the same risk-management duties under Article 21 and the same reporting duties under Article 23, but essential entities face ex ante supervision and important entities face ex post supervision. That difference affects how much evidence you should be able to produce on request, so confirm your classification with your national competent authority before you size a backup program.
The technical detail for backup and redundancy comes from *Commission Implementing Regulation (EU) 2024/2690*, which sets the technical and methodological requirements for the Article 21(2) measures. It applies to a defined list of digital service categories, including cloud, data center, CDN, managed service and online platform providers. If your organization falls outside those categories, the regulation may not apply to you directly, but your national law and competent authority may still expect comparable controls, so check that rather than assuming. Where it does apply, its point 4.2 duties on backup plans, integrity checks and recovery tests are the requirements this page maps to Ceph. The timeline matters too: NIS2 applied from 18 October 2024 under Article 41, and the first NIS Directive was repealed from the same date under Article 44. Existing backup programs should already be measured against these obligations.
The European Commission's proposal COM(2026) 13, dated 20 January 2026, would amend NIS2 with simplification measures and a new small mid-cap category. It is a proposal only. It has not been adopted, and it needs approval from the European Parliament and the Council before it changes any obligation. Treat it as a planning input, not a reason to defer work. Ask your legal or compliance team to record which version of the law governs your organization today, and to set a review point for the proposal's progress. Confirm the transposition status and the competent authority for your Member State with your national regulator, because enforcement and guidance differ between countries.
How DeployOpen scopes NIS2 backup and redundancy work on Ceph
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph clusters in your data centers or air-gapped networks. For NIS2 backup and redundancy, we turn the Implementing Regulation 2024/2690 expectations into a written scope, a tested build and handover material your team and auditors can read.
How we scope
- Map your backup plan requirements, recovery times and retention periods to specific Ceph pools, sites and storage targets.
- Document which copies sit off your primary network and how far they are placed from the main site.
- Agree in writing which evidence items, such as backup logs, checksum settings and restore test records, the engagement will produce.
How we build
- Configure Ceph failure domains, replication or erasure coding and cross-site placement to match the redundancy design agreed in scope.
- Set up separate backup access accounts, RGW or RBD backup targets, and integrity checks on backup copies with logged results.
- Run planned recovery tests against the built cluster and record restore times, failures and the corrective actions taken.
How we hand over
- Deliver the backup plan, architecture records, runbooks and restore test procedures in formats your compliance and operations teams can maintain.
- Provide an evidence map that links each NIS2 backup and redundancy requirement to the configuration, logs or test records that support it.
- Walk your operators through restoration, integrity check reruns and the review cycle for the backup plan before we close the engagement.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, Ceph upgrades and recurring recovery testing are available as a retainer, scoped separately from the build.
- Confirm with your national competent authority and legal advisers how the requirements apply to your entity, since DeployOpen prepares evidence but does not issue compliance certificates or audit reports.
