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.

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 !).

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.