How I can do periodic database backups?

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.

1 Like

Also, for Windows you should disable the write cache for the disk, if you do not have a managed backup power supply

The backup will not help, because it would be outdated in the moment of backup

1 Like

Backup will give you posibilitie of grcefull exit, and upload most data back, and not loose money for sudden breakdown and discvalification

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.

why not give people to upload data back and exit, it much cheper than rebuild all his storege
even in cace of disqualified node

You can add your idea or vote for existing there:
Also, here is discussion regarding graceful exit:

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?

Yes, the node is still audited and yes, it could be disqualified in the process of graceful exit.

Aded my idea here, please feel free to comment/vote?

So what happens if a node gets disqualified while performing a graceful exit? Will it not get any money back?

The graceful exit will be marked as failed and you will not receive a money back.
The link to the updated design:

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.

Well that doesn’t sound too bad then :slight_smile:

then older database, where is lost 1 day may be is much better than no incom for month

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.