Storagenode enables the sqlite journal, so a power cut should not be sufficient to corrupt the database. (When the database is opened after a power cut, the journal would be replayed and the database restored to a consistent state.)
Of course, this requires that sync() actually push buffered writes to persistent storage. If there is a writeback cache anywhere between the application and the final persistent storage layer that cannot survive a power cut, then pulling the plug can corrupt the data. This is true no matter which database engine is used.
It will not give you possibility to graceful exit. Probably your node will be disqualified already on that time. It’s not possible to apply a graceful exit on disqualified node.
A node is only disqualified if it fails too many audits or is offline for too long.
So if I notice that my node is offline because of a database corruption, I would still have time to revert to an old backup and bring it back online.
The satellite might need many hours to audit the pieces the db backup is missing, which would give time for a graceful exit.
Question: Is the node still being audited after a graceful exit is started? Basically can it get disqualified while doing a graceful exit?
Thanks for the answer.
So as of now, backups are a complete waste of space and effort since you probably won’t even be able to gracefully exit without getting disqualified during the process (but will have wasted a lot of time and upload until you get disqualified, however you would have lowered the repair costs for STORJ :D)
I don’t mean to throw a wrench into this discussion, but the way I understood it the databases are not actually vital to the core function of your node.
Even if you start over with all empty databases, you lose stats, you may lose some bandwidth contracts that weren’t sent yet and you won’t be paid for, but your node is still able to respond correctly to audits and downloads by customers. Don’t get me wrong, your node will be a mess. It won’t be able to manage storage limits and bandwidth limits correctly, the dashboard would show wrong numbers, you can’t calculate earnings anymore. But from what I understand, it will still work and wouldn’t necessarily be disqualified.
You wouldn’t lose an entire months income. Only unsent orders. Since orders are sent every hour the impact of that is negligible. Wouldn’t worry about that too much.
At the moment you can use a Windows backup feature (don’t forget to exclude the blobs folder).
On the Linux you can use a cron with rsync.
Or scheduler/cron to run an uplink to backup databases to Storj network
Does “on the fly” (while client is still running and using DB) copy of DB files result in working DB bacup? Or it can de done properly only after shut down node for a time of bacup?
The only multiple rsync (robocopy in case of Windows) can make it possible. Also, Windows shadows copy is reliable enough.
But better to stop the storagenode before the database backup.
