If found myself in a situation where my node is broken due to a corrupt
info.db file, and the instructions here put me in that last category –
your node is lost. The suggested course of action is to abandon the node.
Problem is, starting over you lose your repudiation and any tokens being held in escrow as the NEW node you will setup will be like starting from scratch.
Working with @Alexey, I discovered that if you remove your
info.db (and corresponding WAL file, etc), the storagenode will create a new one and continue to use the existing blob storage directory.
AUDITs appear to succeed, but the ingress/egress numbers as well as total storage are lost (start from
0). This means, you could go OVER your storage/bandwidth allotment.
Over time, I suspect, the info.db could rebuild it self (maybe?) as audits and GETs are performed, but I know I’m reaching here.
What I’m suggesting instead is that if your metadata sqlite DB is broken beyond repair, there be a script which could scan the blob directory and build a new metadata store (rather than starting from zero). In this way at least the storage used vs total would be accurate (and the ingress/egress would just fix itself when the month rolled over). Otherwise you have to make a guess and lower your total storage number to account for the uncounted pieces you had up until now and never self-correct.
Thoughts? Seems possible…