3 ms·

You still have to keep the database nature of the SQLite file in mind when doing backups, as far as I understand it is not safe to just copy the file while the

You still have to keep the database nature of the SQLite file in mind when doing backups, as far as I understand it is not safe to just copy the file while the DB is running unless you use snapshots or ensure that nothing is written to the DB during that time. SQLite is still easier to manage than a standalone database server, so it is interesting in any case. But I'm not sure it makes backups easier.

deleted 4y ago
[deleted]
duskwuff 4y ago
Copying the database file is fairly safe, especially for an application that's likely to be read-mostly like WordPress. It could fail if the database was large enough that copying it took a nontrivial amount of time, and the database was modified during the copy operation -- but even then, there's a fair chance it'd be recoverable. SQLite is pretty resilient. The "safe" way of doing the backup would be: sqlite3 wordpress.db ".backup wordpress-backup.db" which writes out a new copy of the database file. Restoring the database would be as simple as renaming the backup to the main file -- the backup is a "real" database file; there's no import operation required.
johnchristopher 4y ago
Well, you don't have to fiddle with drop statements and tag.gz formats and things like that and restoring is just a matter of putting the file back instead of importing huge numbers SQL instructions. You don't depend on php/phpmyadmin or a sql command to get a backup or to run it (no cpu are harmed during the process). Just copy the file. I can see old gotchas disappear like that (can't wait for the new ones !).
stonemetal12 4y ago
The traditional back up process is 3 steps, 1) lock the file 2) copy the file 3) unlock the file. A second option is to use the SQLite command line tool, it provides a backup command. If you need something more complicated, SQLite provides a backup API you can make use of.

deleted 4y ago

[deleted]

duskwuff 4y ago

Copying the database file is fairly safe, especially for an application that's likely to be read-mostly like WordPress. It could fail if the database was large enough that copying it took a nontrivial amount of time, and the database was modified during the copy operation -- but even then, there's a fair chance it'd be recoverable. SQLite is pretty resilient. The "safe" way of doing the backup would be: sqlite3 wordpress.db ".backup wordpress-backup.db" which writes out a new copy of the database file. Restoring the database would be as simple as renaming the backup to the main file -- the backup is a "real" database file; there's no import operation required.

johnchristopher 4y ago

Well, you don't have to fiddle with drop statements and tag.gz formats and things like that and restoring is just a matter of putting the file back instead of importing huge numbers SQL instructions. You don't depend on php/phpmyadmin or a sql command to get a backup or to run it (no cpu are harmed during the process). Just copy the file. I can see old gotchas disappear like that (can't wait for the new ones !).

stonemetal12 4y ago

The traditional back up process is 3 steps, 1) lock the file 2) copy the file 3) unlock the file. A second option is to use the SQLite command line tool, it provides a backup command. If you need something more complicated, SQLite provides a backup API you can make use of.