Backing up Database files moved to SSD - any point?

having moved my four nodes DB files to (the system) SSD recently, is there any point in keeping an up to date backup of them on the data drive as well?

I’m thinking a simple Robocopy /MIR to run every ten minutes or hour or so…

So, assuming there is a point…

  1. how frequently would it need to be, to be relevant and useful, if the system drive (with the DB files) fell over?

  2. how “old” can the DB files be before they become out of date and no good for anything like recovering the node.

  3. So for example if the node is subsequently rebuilt with the current storj data folder, but the DB files are from an hour earlier than the current blob data, is the node able to recover and update the older DB files, building on what is included in the hour old DB files?

  4. or is it a pointless exercise and I shouldn’t bother and just use the newly created DB files when rebuilding the node?

I hope I have explained this well enough…

They are not required to recover the node. You only need an identity folder and the related data.
Databases are mostly for the dashboard, if you would recreate databases, you would lose the historic information and the current bandwidth usage would be displayed wrongly until the next month. The only essential database is piece_expiration.db because it contains information for data with TTL. So in the worst case the data which otherwise would be deleted when expired right away, it will be collected by a retain process and moved to the trash instead, so it will be for 1-2 weeks longer on the disk.
So, you may do backups if you expect that they could be corrupted. Since you are on Windows you may also use the integrated Windows backup to create versions of database files.
To have a correct usage it’s enough just restart the node with enabled scan on startup.

2 Likes