The point in the Github issue is
Database images get corrupted too often:
This takes nodes offline and causes user frustration.
When the database is corrupted then the node won’t start. When nodes are down and you need to scan and repair databases that’s not good. And frustrated SNOs are not good either.
Retaining the history of a node would be a welcomed side effect if such backups would be implemented.
Ok then I’m confused. First, I’ve been running many nodes since the start of V3 as well as back during V2 and have never had any issues with databases. Maybe I’m just lucky, I dont know. Second,
Is this not true? I feel like theres some conflicting information here.
After I moved databases to SSD, I haven’t any trouble with them for several years. I have 70 nodes, so it is good point for statistics.
In the past Storj holds pieces information in DBs but from some version it moved from there to more reliable solution. Event order information is not there any more.
databases stores your statistics, historic data like past months usage or previous payouts, they are used to expose information via storagenode API, dashboards (single, multinode, CLI), etc.
So yes, if they are corrupted, your node could crash until you fix/recreate them.
Of course, if you recreate them, they will not contain an information about past usage (and it will not be recovered).
So the node will not automagically recreate them? I got the impression they did so I couldn’t understand why it would prevent a node from starting. This seems like a flaw to me. I would at least expect a prompt like “Hey dummy you lost your database files somewhere in your digital abyss. Would you like to recreate them or restore from backup?”. I would think this would be easier and more productive to impliment than a whole backup procedure for files that aren’t absolutely essential to begin with.
It will recreate them, if there is no any. But it will not remove databases automatically.
Our team will be happy to accept your PR - the Community contribution is very welcome!
Ok, so if they are gone completely it will recreate them, but if their partially gone or corrupt in some way or maybe don’t have the proper permissions the node will just fail to start? Again, I’ve never had this problem so I’m just trying to understand. If that’s the case then yeah I think it would save people a lot of headaches to have the node address this. I would think this would be a simple enough and useful thing to do especially if it prevents less technical people from walking away from the project. Although I suppose I would recommend someone else with more knowledge of the actual problem make the formal recommendation to Storj or however it’s done.
yes. It requires operator to make a decision. Maybe you have a backup and can restore databases, or you willing to fix them or re-create.
You can try to submit a PR since it’s look simple for you 
As you may know there is no straight simple setup like download, Next, Next, done. The reason is we need Operators, who can fix issues with their nodes themselves. If the setup and operation would be simple, Operators who meet any problem will just uninstall and start over, right?
The high churn rate is not what the network need, it will increase repair costs significantly. So better to have only quality nodes operated by people who understand tech and be able to fix simple issues as port forwarding, or more complex as a database fix themselves using documentation.
But anyway - we are welcome any contribution, include self-healing features.
Agreed. For whatever reason I was thinking this was causing nodes to fail to start without giving any indication as to why, and that you had to recreate the files manually. Maybe I misread something along the way, but after what you just said it sounds like it’s already doing what should be the expected behavior. Nothing to do, case closed I guess!
A post was split to a new topic: Hay alguna forma de optimizar las bases de datos sin correr peligro de perder algo?