Meeting DORA Article 12 backup duties on a Besu network
A financial entity running Besu validators or RPC nodes must show under DORA Article 12 that its backups, restores and recovery procedures work. Besu can help with the technical parts, such as keeping node keys, permissioning files and configuration under your control, but it does not carry the regulatory duties. The backup policy, the scope of what is backed up, the minimum backup frequency, the recovery time and recovery point objectives per function, and the evidence of testing are organizational decisions that your entity owns and must document. DeployOpen prepares systems, controls and evidence for this work. It does not issue audit reports, attestations or certifications, and independent assessment remains with your competent authority and auditors.
Article 12(1) asks for a documented backup policy that sets the scope of data backed up and the minimum frequency, based on how critical or confidential the data is. For a Besu node, the chain database is only one part of that scope. Ask your team to inventory the files that let a node rejoin and sign correctly: the node private key file, which Besu documentation says is not encrypted, so its storage and access controls must be defined; the permissions configuration files used for node and account permissioning; the JSON-RPC credentials file or JWT validation key; the TLS material in front of the RPC endpoint, since Besu does not terminate HTTPS natively; and the configuration and deployment code that rebuilds the node. Each item needs an owner, a frequency and a restore test.
Article 12(2) requires backup systems that can be activated without jeopardising security or data integrity, and periodic testing of both backup and restoration procedures. Article 12(3) adds that when restores run on your own systems, those systems must be physically and logically segregated from the source and protected from unauthorised access or corruption. In practice, restore a Besu node into an isolated environment, not onto the live validator host. Confirm the Besu version before any restore, because the Besu 26.10.0 release notes state that the Bonsai database upgrades automatically on first start and older versions cannot open it, so a pre-upgrade backup is the only rollback path. Record the results of each test, including the time taken and any reconciliation checks you ran against the restored chain.
Mapping Article 12 requirements to Besu capabilities and configuration
This table maps each DORA Article 12 duty to what Besu provides and the configuration your team must add. Besu does not back up for your entity: it supplies data directories, permissions files, keys and metrics, and the policy, schedule, storage and test evidence are yours to build. Read each row as a gap check: if the right-hand column is not in place, the requirement is not met.
| Requirement | What Besu provides | Configuration needed |
|---|---|---|
| Article 12(1): backup policy, scope and frequency | Node data directory holding chain data, the node private key file and permissions configuration files. No built-in backup policy or schedule. | Written policy listing each item in scope, backup frequency by criticality, and an owner for each validator, RPC node and permissions file. |
| Article 12(2): activatable backups and periodic testing | Bonsai database auto-upgrades on first start, and older Besu versions cannot open an upgraded database. | Snapshot taken before every client upgrade, a documented restore runbook, and scheduled restore tests with recorded results. |
| Article 12(3): segregated restores | Restores run as ordinary Besu starts against a chosen data directory, so isolation depends entirely on where that directory lives. | Restore into a separate network segment with no live peer connections, separate credentials, and access controls that block changes to the source system. |
| Article 12(4): redundant capacity | Validator set and node roles are set in genesis and node configuration, so spare validators and RPC nodes must be planned at design time. | Enough validators to keep QBFT quorum after a single node loss, standby nodes with their own keys, and documented capacity for business needs. |
| Article 12(6) and 12(7): RTO, RPO and reconciliation | Block height and sync status are visible through Prometheus metrics enabled with the metrics option (default port 9545). | RTO and RPO set per function, alerts on sync lag, and post-restore checks comparing restored state with peer nodes and transaction records. |
| Article 40, Delegated Regulation (EU) 2024/1774 (simplified regime) | No regulatory test cadence is built into Besu. The runbooks and restore logs are your evidence. | Backup and restore test at least once a year, and again after any major change to the continuity plan, with results kept for the supervisor. |
| Key and permissions recovery | Node private key file is not encrypted. HSM plugin is available through the security module option. | Encrypted off-site copies or HSM-held keys, and backup of permissions files so node and account allowlists can be rebuilt. |
| Client version recovery | Besu ships roughly monthly, and release notes state rollback needs a backup taken before the upgrade. | Pin the version in each environment, keep a pre-upgrade snapshot, and record the version used to restore each backup. |
What to back up beyond the ledger
Ledger data is only one part of what a Besu node needs to recover. A restore that rebuilds the chain but not the node's identity, access rules and configuration gives you a node that may not start, may not connect to its peers, or may not accept the callers it served before. Treat the node's files as a backup scope in their own right, and set the minimum backup frequency for each category based on how hard it is to rebuild and how sensitive it is.
The most sensitive item is the node private key file. Besu's documentation states that this file is not encrypted, so every copy of it, including backups, snapshots and copies in a recovery environment, must sit in storage with access control, encryption at rest and logged access. Confirm whether your validator and node keys are held in an HSM through the --security-module option, because if they are, the backup scope changes: you back up the HSM's own recovery material under its vendor procedure, not the key file. Also back up the permissions configuration files for node and account permissioning, since a restored node without them may accept peers or accounts that should be blocked. Keep JSON-RPC credentials files or the public keys used to validate JWTs with the same protection.
Back up the genesis file, the node configuration files, the plugin and security module configuration, and the monitoring and logging configuration (including your Prometheus and log pipeline settings). Record the Besu version alongside each backup. The Bonsai database auto-upgrades on first start, and older Besu versions cannot open an upgraded database, so you need a backup taken before every upgrade if you want a rollback path. Keep that pre-upgrade backup until the new version has run cleanly for a period you define in your change process. Ask your vendor or your own test team to confirm the exact directories and files that a complete node restore needs.
How to set up backup, restore and recovery testing
This sequence turns DORA Article 12 duties into a working Besu backup and recovery programme: documented scope and objectives first, then backups, redundant nodes, a segregated restore environment, and tests that prove the restored network reconciles with the source.
Classify functions and set recovery objectives
Start by listing the functions the Besu network supports, such as token issuance, settlement finality, RPC access for downstream applications and key custody. For each function, record whether it is critical or important, the data it depends on and its confidentiality level. Agree a recovery time objective and a recovery point objective per function with the business owner and the risk function. The step is complete when every function has a signed classification and objectives that the backup design can be checked against. Ask your external partner, if you use one, to show how it records these decisions in the written scope.
Document the backup policy and scope
Write the backup policy and the restoration and recovery procedures that Article 12(1) requires. Beyond the chain data, the scope should cover the node data directory, the genesis and configuration files, the permissions configuration files, the JSON-RPC credentials file and JWT validation keys, node and validator key material held in the HSM or its backup process, monitoring and deployment definitions, and the runbooks themselves. Set minimum backup frequencies by criticality. The step is complete when an approver has signed a policy that names each artefact, its owner and its frequency.
Configure backups and pre-upgrade snapshots
Implement the backup jobs against the scope, using the storage and encryption standards your organization already operates. Add a trigger that takes a full snapshot of each node's database before any Besu version change. This matters because the Besu 26.10.0 release notes state that the Bonsai database auto-upgrades on first start and that older versions cannot open an upgraded database, so rollback depends on that snapshot. Confirm the backup system can be activated without weakening access controls or data integrity, as Article 12(2) requires. The step is complete when a scheduled backup and a pre-upgrade snapshot both produce records that an operator can list and verify.
Plan redundant validators and nodes
Size the validator set and the RPC node pool so that the network keeps producing blocks and serving applications when one site, host or operator is lost. Confirm the QBFT quorum arithmetic with your validator design and record what happens if quorum is lost. Place validator and node keys so that a replacement node can be stood up without exposing the key material outside its controlled store. Document the switchover between primary and secondary RPC endpoints. The step is complete when a failure-scenario table shows, for each component, the replacement path and the owner who triggers it.
Build a segregated restore environment
Provision a restore environment that is physically and logically separate from the production network, with its own accounts, network segments and credentials. Article 12(3) requires that restores done on the entity's own systems are segregated from the source and protected from unauthorized access or corruption. Restrict who can reach the environment and prevent it from connecting to production peers or submitting transactions. Confirm that restored nodes can join an isolated test network built from the same genesis and permissions files. The step is complete when access tests show that the restore environment cannot reach production validators or RPC endpoints.
Run restore tests with reconciliation checks
Restore the backed-up node data, configuration, permissions and key material into the segregated environment, then start the node and let it sync. Compare block height, state roots at agreed checkpoints and the account and token balances your reconciliation process defines against the source. Record any gap as a finding and rerun the test until it is closed. Measure the elapsed time and the data loss window against the objectives set in the first step. Article 12(6) and 12(7) call for recovery checks and reconciliations to keep data integrity at the highest level. The step is complete when a dated test report shows the achieved recovery time and recovery point for each function.
Schedule periodic and change-triggered retests
Set a recurring test calendar for backup and restore procedures and make sure it runs at least as often as your own policy requires. For entities under the simplified regime, Article 40 of Delegated Regulation (EU) 2024/1774 requires testing of backup and restore procedures at least once every year or upon every major change to the plan, so confirm which regime applies to you. Add a retest trigger to the change process for client upgrades, genesis transitions and validator set changes. Feed each test report back into the policy and the runbooks. The step is complete when the calendar, triggers and owners are recorded and the next test date is booked.
Redundant validators and capacity under Article 12(4)
Article 12(4) asks entities other than microenterprises to keep redundant ICT capacity adequate for business needs. For a Besu network, that redundancy is set by validator count, node roles, site placement and spare capacity, and it only counts once failover has been tested.
Validator count and QBFT fault tolerance
QBFT tolerates a limited number of faulty or unavailable validators, and the tolerated number depends on the total validator count. Choose the count from your own availability target, then confirm the exact fault tolerance arithmetic in the Besu documentation for your chosen version. Record the decision in your risk assessment so an examiner can see why the network was sized that way.
Validator placement across operators
Validators held by a single operator, in a single cluster, share the same failure modes. Where several organizations share the network, decide which operator hosts which validators and how a validator is replaced if its operator is unavailable. Document the agreed validator roster and the process for changing it.
Node roles and separation
Validators, boot or peer nodes, and RPC nodes carry different loads and different risks. Keep validator nodes off the public API path, and run RPC nodes so that losing one does not stop client traffic. Map each role to the systems and access rules it depends on, since restores must follow the same segregation.
Geographic separation of nodes
Article 12(5) requires a geographically distant secondary site only for central securities depositories, so other entities set site separation through their own risk assessment. Where that assessment calls for it, place validators across sites or data centers that do not share power, network or storage. Confirm that the chosen topology still reaches quorum when one site is lost.
Spare capacity for peak load
Redundant nodes only help if the surviving nodes can carry the load. Size storage, CPU, memory and network for the period when one node is down and a replacement is syncing. Monitor disk growth on the chain database, since a node that has fallen behind may take a long time to catch up. Treat the sizing figures as results of your own load tests, not vendor defaults.
Failover switchover testing
A redundant design is not evidence of recovery until a validator or RPC node has been removed and the switchover has been timed and observed. Run these tests on segregated systems, record the results, and repeat them after major configuration or client changes. Keep the test plan and results in the same evidence set as your restore tests.
Confirm QBFT recovery behavior
Recovery behavior when quorum is lost, and how a stalled network resumes, depends on the Besu version and the consensus configuration in use. Ask the vendor or check the Besu documentation for the version you run, and write down the procedure you will follow. Do not assume that behavior from an older release still applies.
Segregated restores by environment and option
A dedicated recovery environment is a separate set of infrastructure, built for restores and kept apart from the production network. Article 12(3) requires that when backup data is restored using your own systems, those ICT systems are physically and logically segregated from the source system and protected from unauthorized access or corruption. For a Besu network, this usually means restored nodes run in their own cloud account, data center segment or cluster, with their own keys, network routes and administrative accounts.
- Separate identity and secrets: Restored nodes should not reuse production administrator accounts, JSON-RPC credentials or signing material unless your risk assessment accepts that.
- Network isolation: Confirm that recovery peers cannot reach production validators or RPC endpoints by default, and that any bridge is opened only for a defined test window.
- Storage separation: Restore the database and node data onto volumes that production systems cannot mount or overwrite.
- Logging and clock sources: Forward recovery logs to a store that your monitoring team controls, with time synchronization that matches production.
Confirm these controls with your infrastructure and security teams before the first restore, and record the results as evidence for the test.
Some entities restore directly onto production hosts, for example when a validator must rejoin quickly after hardware loss. Article 12(3) still applies. Because the restored system is the live system, the controls must prevent a restore from corrupting the source data, reintroducing compromised material or giving an unauthorized party a path into the network. Treat this option as a controlled change, with approvals, a rollback point and a defined verification step before the node returns to service.
- Preserve the source: Snapshot or copy the current data directory before any overwrite, so a failed restore does not destroy evidence or the only good copy.
- Verify the backup first: Check the backup set in an isolated location before it is written to a production host.
- Restrict the window: Limit who can start the restore and keep the node out of validator duty until integrity checks pass.
- Check keys and permissions: Confirm the node and validator keys, and the local permissioning configuration, match the approved network state.
- Record each step: Keep the change ticket, operator identity and the output of each check.
Confirm with your change management owner that this path is documented, approved for the specific failure scenarios it covers, and tested at least as often as the recovery plan requires.
A shared test environment is useful for rehearsing restores, checking backup sets and measuring recovery steps. It is not a safe default target for production data. Many test environments are shared with developers, vendors or other business lines, have looser access rules and receive copies of production data that were never meant to leave production. Article 12(3) does not allow those weaker controls to be treated as segregation.
- Use synthetic or reduced data where possible: If production-like data is needed, confirm that its handling meets your confidentiality and data protection rules.
- Isolate the network: Keep test nodes off production peer lists and off any routes that reach production RPC or key stores.
- Separate credentials: Issue test-only keys and accounts, never production validator keys.
- Review access: Confirm who can reach the environment and remove shared administrator access.
- Clean up after tests: Destroy restored data and temporary keys once the exercise ends, and record that the cleanup happened.
Confirm with your data protection and security owners whether the shared environment qualifies for the test you plan to run, and document the boundary between it and production.
Evidence auditors and supervisors will ask for
Article 12 is a documentation and testing duty as much as a technical one, so supervisors will ask for records that show the backup policy was followed and the restores actually worked. The cards below cover the artifacts that connect a Besu node's data, its releases and its health to the recovery design, and each one needs an owner and a refresh cycle.
Written backup policy and scope
The policy is the document that sets which data is backed up, how often, and why. For a Besu network, it should list the chain data, the node key and validator key files, the permissions configuration files, the JSON-RPC credentials file, the genesis file and the monitoring configuration, and state the minimum frequency for each based on criticality. Ask whether the scope was reviewed after the last topology change, since a new validator or a moved node changes what must be captured.
Backup job records and frequency
Auditors will sample backup job logs to confirm that jobs ran at the frequency the policy states, that failures were detected and that someone acted on them. Keep job history for each node and each backed-up asset, including the backup timestamp, the size, the target location and the checksum or verification result. Alerts on failed or missed jobs should feed the same monitoring stack that tracks node health, so gaps are visible rather than discovered at restore time.
Restore test reports and reconciliation
Article 12(2) requires periodic testing of restoration and recovery procedures, and Article 12(6) and (7) require checks and reconciliations during recovery. Each test report should record the restore environment, which must be segregated from production under Article 12(3), the backup used, the block height reached after restore, and the reconciliation results comparing restored state with the expected chain head. A report that shows only a successful start is weak evidence; one that shows reconciled state is what supervisors look for.
RTO and RPO records per function
Recovery time and recovery point objectives must be set per function, with attention to whether the function is critical or important. For a tokenization or settlement network, record which node roles support which business functions, the RTO and RPO agreed for each, and the measured results from restore tests. Confirm with the business owners and your risk function how these targets were approved, because an objective that no test has ever measured is an assertion, not a control.
Besu release and database version records
Before each upgrade, record the Besu version in use, the target version, the JDK in use and the database format. Besu 26.10.0 auto-upgrades the Bonsai database on first start, and older versions cannot open an upgraded database, so a rollback depends on a backup taken before the upgrade and on that backup being restorable with the prior binary. Keep the release notes reviewed, the pre-upgrade backup reference and the sign-off for each change, aligned with your change management process.
Prometheus metrics and monitoring logs
Node health evidence comes from the metrics Besu exposes through Prometheus when metrics are enabled, along with the logs and alerts that surround them. Retain peer counts, sync state, block height and validator participation over the period under review, and keep the dashboards and alert rules under version control. These records show whether a node was healthy before a backup was taken and whether a failover was triggered as designed. Confirm your retention periods with your compliance function.
How much effort and cost does DORA backup work on Besu take?
What drives the effort of DORA backup and recovery work on a Besu network?
The main drivers are the number of validator and RPC nodes, how many distinct backup scopes you must define, the key storage choice, whether restores run on segregated systems, and how much existing backup tooling you can reuse. A small permissioned network with a few validators and one RPC tier has far fewer restore paths to test than a multi-organization network with separate RPC estates. Each added node type, storage backend or segregated environment adds procedures to document and exercises to run. No supplied figure gives a duration, so confirm the scope against your own topology before estimating effort.
Which parts of DORA backup work are one-time and which recur?
One-time work includes the written backup and restoration policy, the scope of data and node configuration to back up, the recovery time and recovery point objectives per function, and the first segregated restore test. Recurring work includes running and monitoring backups, periodic retesting of restoration and recovery procedures, and updating runbooks after each client upgrade or change to the network. Article 12(2) requires periodic testing, and for entities under the simplified regime, Article 40 of Delegated Regulation (EU) 2024/1774 requires testing at least once every year or upon every major change. Confirm the testing cadence your competent authority expects for your entity type.
What does the financial entity need to provide for this work?
The entity needs named owners who set the recovery time and recovery point objectives for each function, since Article 12(6) ties them to whether the function is critical or important. It also needs access to the infrastructure, including the nodes, storage, key material handling and any segregated restore environment, plus approvals for test restores and change windows on live validators. Security and compliance staff must agree how restored systems are isolated from the source system. Without these owners and approvals, the work stalls at the policy stage.
Can our own team run DORA backup and recovery for Besu internally?
Often yes, if your team already operates Besu, Linux infrastructure and backup tooling, and has capacity to run segregated restore tests on a schedule. The hard parts are usually not the backup command but the evidence: documented procedures, test records, reconciliation results and proof of segregation. Teams without recent Besu operating experience, or without a restore environment separate from production, often find the first test takes longer than expected. A gap assessment against Article 12 is a practical way to decide which parts to build in-house.
How do we ask for a quote for DORA backup work on Besu?
Start with a written scope that lists the network topology, node roles, validator count, RPC nodes, key storage approach, backup tooling, the restore environments you must segregate, the functions in scope with their recovery objectives, and the deliverables you expect, such as a policy, runbooks, restore test reports and a retest schedule. Ask the provider to separate one-time work from recurring testing and to state assumptions about your environment and access. DeployOpen does not publish a price list; a quote follows from the written scope, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts.
Does a retainer cover the recurring backup testing?
A retainer can cover ongoing support, periodic restore testing, upgrade-driven runbook updates and continuity checks, because DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Confirm in writing which test types, how many restore exercises per period, which environments are included, and how out-of-cycle tests after a major change are handled. Also confirm who owns the evidence produced, since the entity remains responsible for its own DORA compliance. The retainer scope should match the testing cadence your competent authority expects.
What is the cost of backup storage and infrastructure for a Besu network?
Storage and infrastructure costs depend on your chain size, how often you snapshot node data, retention periods, the location and redundancy of backup copies, and whether a segregated restore environment must run continuously or only during tests. Those costs are paid to your cloud or data center provider and storage vendor, not to the implementation partner. No supplied figure gives storage sizes or prices, so measure your node data growth and request your provider's pricing for the chosen retention and redundancy model.
How DeployOpen scopes and delivers DORA backup evidence
DeployOpen agrees the backup and recovery scope in writing before any build starts. The written scope names each Besu node role in the estate (validators, RPC nodes, any observer or gateway nodes), the data classes to protect for each (the Bonsai database, node key files, the permissions configuration files, JSON-RPC credentials or JWT validation keys, genesis and configuration files, and the monitoring and log stores that support recovery), the backup frequency for each class, and the recovery time and recovery point objectives per supported function. It also records which Besu version each backup set was taken under, because the 26.10.0 release notes state that an upgraded Bonsai database cannot be opened by an older Besu version. Confirm with your engineers that the scope covers the database and configuration state an operator would need to rebuild a node from a clean host.
DeployOpen then configures the backup jobs, retention and restore runbooks inside your cloud accounts, data centers or closed networks, and builds the segregated restore environment as a separate network segment with its own credentials, storage and access logs, so that a restore cannot reach or corrupt the source system. Key material follows the approach agreed in your key management design, including any HSM-backed signing. Work that is usually one-time includes the scope, the backup configuration, the restore environment and the first full restore test. Recurring work includes scheduled restore tests, reconciliation checks after each restore, and runbook updates after each Besu upgrade. Ask any provider to price these two groups separately.
Each restore test is run from the runbook, timed against the agreed objectives, and recorded with the Besu version, the backup identifier, the reconciliation results and any deviations. DeployOpen prepares this evidence pack for your internal risk function and for the auditors or competent authority you answer to. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and your supervisor make those determinations. Ongoing periodic testing, runbook maintenance and evidence refresh are available as a retainer, which suits entities that must test at least annually or after each major change to the continuity plan.
