[Feature] Remove periodic database backup in favor of dual-node failover

[liuyifei001]

Problem Statement

The database backup feature was originally introduced to enable fast recovery during disk failover and played a certain role in the early stages of chain development. In the past, there were efforts to optimize this feature, such as completing the implementation of the backup database.

However, as the database size has grown rapidly, a series of negative effects have emerged. For example, long backup times can block block synchronization, causing the drawbacks to significantly outweigh the benefits.

Proposed Solution

Why should it be removed ?

The database backup feature is configured as follows:

storage.backup = {
  enable = false  // indicate whether enable the backup plugin
  propPath = "prop.properties" // record which bak directory is valid
  bak1path = "bak1/database" // you must set two backup directories to prevent application halt unexpected (e.g. kill -9).
  bak2path = "bak2/database"
  frequency = 10000   // indicate backup db once every 10000 blocks processed.
}

When this feature is enabled (enable = true), during execution of pushBlock(final BlockCapsule block), if block number % frequency == 0, all databases that implement the RevokingDatabase interface are copied to an alternative directory.

This mechanism was designed to address data corruption caused by sporadic disk failures, power outages, or abrupt process termination (e.g. kill -9) in the early stages of deployment.

Current Major Issues：

• After optimization and extensive testing, it has been confirmed that kill -9 does not corrupt the database, which significantly reduces the necessity of periodic database backups.

• State-related databases are extremely large. As of 2026-01-28, the mainnet state database is close to 3 TB, and a single copy operation can take several hours. During the backup window, the node is unable to synchronize blocks, which poses a fatal risk to service stability.

Alternative Solution

An alternative to database backup is to deploy dual FullNodes in a primary–backup configuration. The configuration is as follows:

node.backup {
  port = 10001
  # my priority, each member should use different priority
  priority = 8
  # peer's ip list, can't contain mine
  members = [
    # "ip"
  ]
}

If a node becomes unavailable due to database corruption or other issues, traffic can be switched to the backup node.

Specification

API Changes
None

Configuration Changes
Remove item storage.backup

Protocol Changes
None

Scope of Impact

Breaking Changes
Section of Database will be impacted.

Backward Compatibility
Not compatible with v4.8.1 or older.

Implementation

Do you have ideas regarding the implementation?
Yes

Are you willing to implement this feature?
Yes

Estimated Complexity
Medium

[warku123]

Thanks for the detailed proposal. A couple of thoughts:

This would be a breaking change for users currently relying on storage.backup. Would we expect all users to migrate to the dual-node setup? The resource cost (double hardware) might be significant for smaller operators.

Perhaps we could deprecate this feature first and remove it in a later version, giving users time to adjust their deployment strategy.

What do you think?

[Federico2014]

Good suggestion. I agree that the direction to remove the database backup feature is reasonable and aligns with the current mainnet scale requirements. However, we must enhance the effectiveness and stability of the dual-node backup mechanism.

[liuyifei001]

@warku123 The database backup feature has effectively been unusable in recent years, so there is no need to maintain compatibility anymore.

[halibobo1205]

See the issues before: @warku123 cc @liuyifei001

• Optimize RocksDB's backup function #5698
• Fullnode sync fails or stalls at block heights ending in 99 or 999 from official snapshot #6425
• Core Devs Community Call 45 pm#157
• Create Full Configuration File #6432

[lxcmyf]

@liuyifei001
For users with limited machine resources or insufficient hardware configuration, running two nodes may introduce a relatively high operational threshold.

Is there any plan to provide a lighter alternative deployment mode, or optimizations that could reduce the resource requirements for this architecture?

For example, are there recommended minimal configurations or possible approaches that allow smaller operators to adopt this solution without needing to maintain multiple nodes?

[liuyifei001]

@lxcmyf Real-time database backup is used to prevent data loss in the event of disk failures. However, it can be effectively replaced by using RAID disk arrays, which offer comparable cost but deliver better reliability and performance.