Repository navigation
[Feature] Remove periodic database backup in favor of dual-node failover #6595
Description
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
Activity
warku123 commentedon Mar 23, 2026
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 commentedon Mar 23, 2026
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 commentedon Mar 23, 2026
@warku123 The database backup feature has effectively been unusable in recent years, so there is no need to maintain compatibility anymore.
halibobo1205 commentedon Mar 23, 2026
See the issues before: @warku123 cc @liuyifei001
lxcmyf commentedon Mar 23, 2026
@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 commentedon Mar 24, 2026
@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.
lvs0075 commentedon Apr 7, 2026
This feature has been included in version 4.8.2; we look forward to the subsequent pull request.
lvs0075 commentedon Apr 16, 2026
@liuyifei001 What is the current status of this?
liuyifei001 commentedon Apr 18, 2026
A related PR will be submitted in a few days.