I’d like to propose a feature to improve the experience of Storj node operators who lose their physical disk data but still retain their node’s database and identity.
Current situation
When a node loses its stored data, it must rebuild all pieces from the network, taking a long time and incurring penalties for downtime and missing data. This discourages operators and risks node loss.
Proposal: Recovery Mode with automated, usage-based fee payment
Implement a recovery mode where:
Penalties for downtime and missing data are suspended during recovery.
Operators pay a fee proportional to the actual resources consumed (e.g., data downloaded, bandwidth used) to accelerate rebuilding.
Fees are automatically deducted from a pre-funded credit or from node rewards.
There’s no fixed duration or upfront estimated cost — charges are based on real usage.
Upon activation, the node immediately begins to check for missing pieces and requests them from the satellites to start rebuilding data.
Once the node has fully rebuilt its missing data, the recovery mode automatically ends, and the node resumes normal operation with standard audits and penalty enforcement.
How it would work
Pre-funded STORJ credit
Operators maintain a balance of STORJ tokens locked as recovery credit linked to their node.
Activate recovery mode
Operators activate recovery mode via CLI, for example:
./storagenode recovery start
This notifies satellites that the node is in recovery, suspends penalties, and triggers the node to start verifying and requesting missing data.
Resource usage monitoring and billing
The network tracks actual data and bandwidth used to rebuild the node, and deducts fees accordingly from the credit or rewards.
Automatic recovery completion
When the node finishes rebuilding all missing pieces, recovery mode automatically stops, and the node returns to normal operation, including standard audits and penalties.
Limits and safeguards
Usage is monitored to prevent abuse, e.g., by limiting maximum credit consumption or number of recoveries per period.
Benefits
Operators pay fairly for actual recovery resources used, no upfront guesswork.
Penalties are suspended only while actively rebuilding, encouraging timely recovery.
Simplifies operator experience through automated billing.
Preserves node identity importance and network resilience.
The node starts rebuilding missing data immediately upon recovery activation, minimizing downtime.
Recovery mode ends automatically when rebuilding is complete — no manual intervention needed.
Example
If a node’s disk fails, the operator starts recovery mode. Satellites prioritize sending data shards to that node, while penalties are suspended. The node automatically checks which pieces are missing and requests them. Fees accumulate based on the data sent and bandwidth used, automatically deducted from the operator’s recovery credit. Once recovery finishes, the system automatically ends recovery mode and the node resumes normal operation.
Future enhancements
This usage-based recovery mode can evolve into a flexible node lifecycle management system with modes for maintenance, emergencies, and migration.
I look forward to community feedback and suggestions!
Nodes should have their data available. If the node lost data, that means that something went wrong with the node. In a power failure scenario, it lost a tiny fraction of yet-to-be-written data. If the node lost a lot of data, that means that the disk/filesystem is failing which should disqualify the node.
I understand that losing significant data means a serious failure and data integrity is crucial. However, I know people who have lost Storj nodes due to disk failures, and I believe a controlled recovery mode would help prevent losing the entire investment when the node’s database and identity are still intact.
Storj is a decentralized network with many home-based nodes where hardware failures can happen. This proposal doesn’t remove penalties but suspends them only while the node is actively rebuilding data, charging fairly for used resources, with clear limits to prevent abuse.
Regarding AI, I only use it to help structure and translate my ideas faster, always reviewing and adapting content personally.
So you are trying to make an excuse for a failed disk to not have any bad reputation result on the node. Got it.
The databases aren’t part of the node. They are there to show pretty graphs and random values on the dashboard.
The identity is the node: it shows that node X isn’t storing any data from node Y. Node’s X data is married to the identity. Either of those gone = node should be disqualified as soon as possible.
Answer this: Your node in “maintenance mode” is storing the last part of a file needed for a rebuild. The minimum threshold is your node’s last part. If your node fails to come back, the customer’s data is lost forever since the network doesn’t have enough parts to rebuild the data. Would you like to explain to the customer that SpaDev was just trying to replace a failing disk, when the customer asks why they can’t access their files anymore? Or would you prefer to tell the customer that their data is available because SpaDev’s node got disqualified/suspended and data on it was proactively rebuilt on other nodes?
Any data not being available to the network immediately is data at risk, and you should stop trying to make up excuses as to why any SNO lost those data (and the node along with it).
For example, imagine an 8TB hard drive costs around 200 euros, and I’ve been running my Storj node for two years, earning X euros per month. I wouldn’t mind paying a portion of those earnings to Storj to guarantee that if the drive fails, I can recover the data without losing what I’ve invested. That way, I’m still contributing to the network.
Look, it’s very simple. If I’ve hired someone to store my data and pay them for it and they come to me with the message that they lost all my data and would like to pay me to get the data I entrusted to them back and get me to reinvest in a provable unreliable service provider, what do you think my answer would be?
Nodes that lose data should be ditched asap. If you want to try again, spin up a new node, go through vetting and prove anew that you can reliably store data. And be happy that a failed node on your IP won’t do anything with the reputation of your IP. But don’t expect Storj to reinvest in nodes that already proved to be unreliable. It makes no sense.
These type of concerns don’t exist if one aligns with the spirit of the project - which is “share underutilized, already online, resources”.
Nobody has single drives online for any conceivable purposes. Industry moved long ago from attempting to have a single ultra reliable drive to a cluster of sufficiently crappy devices, that yield system reliability significantly higher than what a single disk count humanly achieve, ignoring the exorbitant cost it would have come at. So, everyone is using redundant self-healing arrays. Those who don’t – should, and will right after next data loss.
Storj operates on exact same principle: ultra reliable system consisting in garbage and/or byzantine nodes. It’s a redundant array of independent devices nodes. Each individual node can be garbage. Does not matter. It’s redundant arrays all the way down and up.
Single disk has no place today anywhere near where the words “data” and “storage” are uttered in close proximity within each other.
You should not invest in a first place: use what you have now, otherwise it unlikely will have a ROI.
This idea is not acceptable at all. If you lost data - the node must be disqualified and you may start from scratch. The network doesn’t require bad nodes.
Current situation
Proposal: Recovery Mode with automated, usage-based fee payment
How it would work
Benefits
Example
Future enhancements