Nodes autorepair

[Pac]

I truly think Nodes should fix themselves whenever possible.

Let’s take database corruption as an example: it is a common problem and is likely to keep happening in the future to many SNOs as a simple power outage can cause this issue.

There is a known procedure (https://support.storj.io/hc/en-us/articles/360029309111?_ga=2.6254707.1330931111.1590396912-5329027.1585062953) for fixing corrupted/malformed databases.

The Node could run a pragma check on its database files regularly (or when a Node just got started after a reboot, or an update), or whenever something goes wrong with it.
If a database file proves to be broken, the Node could pause (disconnect from the sat’) and take the time to check and repair what can be repaired.
If the repair fails, then the SNO should be warned, and the node suspended I guess.

---

More globally, I think that whenever a problem has a known solution that could be applied by the Node software itself automatically, this should be implemented.
That would greatly improve SNOs’ peace of mind, and also the STORJ network quality/reliability, I think

_This is somehow related to https://forum.storj.io/t/ability-to-recover-part-of-lost-data-restore-the-node-from-backup/6855_

[victorelec14]

+1 Just the same as I was thinking, it is one of the bigger problems that there are right now, a few days ago I lost a node of 10 TB due to an error in the DB.

Also the held amount is used to repair all the nodes the files when actually only a part is damaged …

Cheers

[Alexey]

You can lose DB and do not lose the node:

What is the worst that would happen if I delete all of my SQLite databases and restart storagenode?

Do you have a citation where anyone has found that to be the case? All I’ve heard on the forums for when there’s a database corruption error is “the databases aren’t critical, just delete it and restart storagenode.” Ping @Alexey… can you chime in on this? What is the worst that would happen if I delete all of my SQLite databases and restart storagenode?

You lost node for too much audit failures, i.e. missed or inaccessible customers’ data.
The data lose can’t be recovered itself.

[joesmoe]

I also think this is a great idea.

I have lost many many TB’s of data stored on old nodes due to database and other random errors and my impatient and failed attempts to fix them.

Why can’t we use repair function on a node that has lost data?

I would rather pay for all the repair traffic (out of my esrow) than lose 100% of the escrow.

[Alexey]

@joesmoe

I have lost many many TB’s of data stored on old nodes due to database and other random errors and my impatient and failed attempts to fix them.

The losing database will lead only to lose the stat, not the customers’ data. Seems you have a mass disruption problem there. And if you have several failed attempts I would suggest to check your hardware more precisely, perhaps it’s not suitable to handle data anymore.

@joesmoe

I would rather pay for all the repair traffic (out of my esrow) than lose 100% of the escrow.

This is not possible because of simple reason:

Ability to recover part of lost data / restore the node from backup

While I agree with the general purpose of the proposal, I highly doubt it will function as intended. There simply is no possible method that could audit enough prior data pieces to ensure a node that has been disqualified could safely reenter the network. A full audit of all data would take a very long time. A node which voluntarily pays to remain in the network would lose funds rather than earning funds. The current system functions fairly well for both sides… even if a long running node lo…