3 ms·
> While it is possible to continually copy the SQLite file to a backup server every time it is changed, this file-copy must not take place while the database is
by kijin 12y ago
> While it is possible to continually copy the SQLite file to a backup server every time it is changed, this file-copy must not take place while the database is being accessed.
What about the `.dump` command?
I've been using it to backup SQLite databases since forever. It produces an SQL script (similar to `mysqldump`) that you can import back into another SQLite database, or even into another RDBMS. It's much more elegant than copying the database file itself.
But come to think of it, I never really checked whether the `.dump` command produces a consistent backup, and the official documentation doesn't seem to answer that, either. If you're familiar with the internals of SQLite, please let me know whether I should keep trusting `.dump`.
- otoolep 12y agoYou could be right, it might well produce a consistent backup. If fact, I'd be very surprised if it didn't. But doing that misses the point of rqlite, of course. rqlite replicates the database to other machines, after every transaction, without copying the entire sqlite file everytime.
- jakobegger 12y agoI'm not sure a backup that was never tested qualifies as backup.
- kijin 12y agoThe backups do restore properly all the time, I made sure of that. I simply don't have enough transaction volume to test all the edge cases that might produce an inconsistent dump (and if I did, I wouldn't be using SQLite).