diff options
author | Julien Dessaux | 2021-11-09 16:46:42 +0100 |
---|---|---|
committer | Julien Dessaux | 2021-11-09 16:46:42 +0100 |
commit | 13740a0bf8101f49069301fc9b58c87d40e36c34 (patch) | |
tree | 5a1a4c9a5c9ff0684953e1ec61cfac400cfb3d5e /content/blog/miscellaneous | |
parent | Fixed tags links in blog articles (diff) | |
download | www-13740a0bf8101f49069301fc9b58c87d40e36c34.tar.gz www-13740a0bf8101f49069301fc9b58c87d40e36c34.tar.bz2 www-13740a0bf8101f49069301fc9b58c87d40e36c34.zip |
Added SQLite backups blog article
Diffstat (limited to 'content/blog/miscellaneous')
-rw-r--r-- | content/blog/miscellaneous/sqlite-backups.md | 34 |
1 files changed, 34 insertions, 0 deletions
diff --git a/content/blog/miscellaneous/sqlite-backups.md b/content/blog/miscellaneous/sqlite-backups.md new file mode 100644 index 0000000..4cf9bae --- /dev/null +++ b/content/blog/miscellaneous/sqlite-backups.md @@ -0,0 +1,34 @@ +--- +title: How to properly backup your SQLite databases +description: I used to simply .dump those +date: 2021-11-09 +tags: +- backups +- SQLite +--- + +## Introduction + +SQLite is great and I have been using it for years while self-hosting various services. It is easier, lighter and fast enough for most needs which is critical when the time you can spend managing your personal infrastructure is finite. + +Recently while talking with a developer friend I learned about the `user_version` PRAGMA, which could be a simple way to handle migrations in a custom app. For migrations to work you need a way to save the current revision of your schema somewhere : I was using a table for that, with a single column and a single row to store that revision. This PRAGMA would be a nice way to handle this in SQLite. + +## The backup problem + +The problem with this PRAGMA is that it does not appear in a `.dump`! So if you rely on this to backup your databases (like I did) then you would lose the schema revision upon restoring your service, or migrating it to another host. + +When looking into this problem I learned that a better way to handle SQLite backups is with `VACUUM INTO 'file.db';` (added in SQLite 3.27 in early 2019). Not only does this create a perfect copy of your database at the point in time you run this command, the PRAGMA are kept and the indexes will not need to be rebuilt! + +## Conclusion + +I switched all my SQLite backups to `VACUUM INTO` and will not look back! + +If by chance you are using my [borg ansible role]({{< ref "docs/adyxax.org/backups/borg-ansible-role.md" >}}) to manage your backups, here is what an SQLite job entry looks like : +``` +- name: srv-short-db + path: "/tmp/short.db" + pre_command: "echo 'VACUUM INTO \"/tmp/short.db\"'|sqlite3 /srv/short-data/short.db" + post_command: "rm -f /tmp/short.db" +``` + +I did not yet migrate away from my schema version table to replace it with the pragma : I need to think about it more before committing to this kind of change. |