Originally I already had the pools set up on an existing server so I just decided to give it a shot. Multiple nodes was mainly for manageability later on as I suspected the pool might not be the best option in the long run. That and I would also have the ability to run them in different locations …

[image] arrogantrabbit: Ultimately, I would not worry about failing slog. [image] arrogantrabbit: And these databases are not really critical—the downside of losing them is purely cosmetic. This I was not aware of. Although I dabble in programming here and there I am by no means a pro…

Databases are used for statistic, if you lose them, you may start without databases at all and they will be recreated. You will only lost your history. But losing data from blobs more than 4% will lead to disqualification.

Good to know, thanks for clarifying that.

[image] Alexey: You will only lost your history. Then wouldn’t it make sense to make a database backup let’s say every start of a new month to keep most of the history? I think it was under consideration to make database backups on Storj DCS if I remember correctly. Wouldn’t that be amazing …

I did not see such a feature request on our roadmap or on GitHub, so it perhaps was only an idea, but no real action items. However, you may implement it right now with Duplicati (it has an integrated scheduler and web UI), with restic or HashBackup (you will need to configure a cron job).

[image] Alexey: I did not see such a feature request on our roadmap or on GitHub STORJ sqlite databases should be backed up on STORJ distributed network using node-identifier-key for improved node-recovery opened 08:38AM - 16 Nov 22 …

Since the database files are only for node statistics and are recreated by the node if lost I don’t really see this solution being relevant to the stated issue it’s trying to solve.

[image] MattJE96011: and are recreated by the node if los I understand it that the history remains lost once it has gone which is all the previous months and includes the earning data etc. .

Point being, backing up / restoring the database files won’t have an effect on node downtime or disqualification so I doubt it’s something Storj is overly concerned with.

[image] MattJE96011: Point being, backing up / restoring the database files won’t have an effect on node downtime or disqualification 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 corru…