Sqlite DB Android Backup/Restore

Question

I wanted to know what the best practices are for backing up and restoring a SQLite DB on android. Currently I approach the issue by taking the DB to be backed up and using F

Answer 1

I'd add one additional comment to Kingamajick's answer (the forum won't let me add it as an actually comment there). In the approach that simply copies the file, if a user ever restores the DB and there happens to be any data already in it, it will be overwritten. For example, if a user upgrades to a new phone, uses it for a while, and then restores the DB from their old phone, any data already on the new phone will be lost. That is one advantage to the complexity of reading the DB and writing it out to a file (XML or CSV, etc.).

I posted another question (Android sqlite backup/restore without overwriting) in hopes someone had a better solution that avoided this problem, but so far it seems like there isn't one. Between that and the concerns ssuperz28 noted it seems like a much safer way to backup your DB is to write it out to xml and then read it and add it back in on restore.

Also, https://stackoverflow.com/a/34477622/3108762 is the best of the other suggestions I've seen so far and promises a better way to approach this starting in Marshmallow.

Answer 2

This seems like it would be the best approach. You may want to consider taking a checksum of the SQLite file before copying and comparing it with the destination file for extra assurance. Just ensure there are no open connections to the database when you take the copy, otherwise you may end up with the DB in an unexpected state when it's restored.

The only other way I could see to do it, would be to read the actual contents of the DB and generate a file containing the SQL which which it can be restored from, this is obviously a more complex and doesn't offer any advantages to justify this complexity.

Answer 3

Just an FYI on backing up the database. I currently do this in my app the same way you are explaining above. Beware when creating backups this way. It works great for the most part, but the problem is that the backup that's created is not guaranteed to be compatible with all devices and Android versions. I thought this sounded odd the first time I heard that, but I'm now finding that it's true. I have been receiving several reports lately of missing data, disappearing data and such. This was all happening when the user was restoring a backup either from a different device or a different Android version or ROM. A few of them contacted me directly, which was great, so I was able to get backup files from the to test them out and examine them. When I tried to restore them, I would get the following logcat error: android.database.sqlite.sqlitedatabasecorruptexception: database disk image is malformed

What I was finding out was that, mainly, certain HTC devices and some custom roms (on any device) were creating these backups that wouldn't restore to other devices or roms. The databases weren't really corrupt, but Android thought they were. I would take them into a SQLite browser and no data would show there either. It turns out that newer versions of SQLite have WAL (Write Ahead Logging) enabled by default and if it is enabled and a backup is made with that database, it cannot be restored to an older version of SQLite or even sometimes the same version (for some odd reason). So, I disabled WAL with "PRAGMA journal_mode = DELETE" and then I was able to view the database in the browser and able to restore it on my test device fine. The other problem is that there doesn't seem to be a way to catch this exception in code and Android automatically deletes the database when it comes across this exception (very bad management on Android's part in my opinion).

Sorry for the long response, but I wanted to explain what I was seeing happening with this sort of backup. I'm in the process of trying to find another way to create a universal backup on the SD card. Creating csv files and sql scripts like @Kingamajick said may be another way to do it. It is more code and more work, but if it works on any device, SQLite version and ROM then it would be worth it. Your customers losing data is never a good thing.