The following is the first few sections of a chapter from Android's Architecture Components, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Backing Up a Room

In some apps, the local database is little more than a cache. Perhaps it is a true cache, where the app directly hits the network when some necessary data is not in the database. Perhaps the app uses a synchronization model, where the network is still the “system of record”, but the local copy can be used offline and is periodically synchronized with the server.

But, in other apps, the local database itself is the “system of record”. Android does not offer a real backup solution — the best it has amounts to a disaster recovery option, since users have little ability to restore a backup. Third-party apps cannot back up the internal storage of other apps (except perhaps on rooted devices), which is why there are few backup utilities for Android. Instead, if you want your app’s local data to be backed up, you need to do that yourself.

So, with that in mind, let’s explore backing up SQLite databases, with an eye towards Room.

What Do We Need to Back Up?

The first question whenever “backup” is discussed is that of scope: what files are we supposed to back up and be able to restore?

Plan A: The Whole Directory

The simple solution is to back up the entire directory that contains database files. That way, you do not care exactly what files are in there — you just back up everything.

To find out the default directory for Room database files, use:


where ctxt is some Context and "foo" is, well, "foo". In theory, you could replace "foo" with the name of a real database, but since you are not actually going to use that value, it just needs to be some valid string. This code snippet will return the directory where that database would be stored.

Given that directory, you could then just back up the entire directory’s contents, knowing that your database and its files will be in there.

Plan B: Just SQLite’s Files

However, that directory may contain databases other than yours. For example, if you are using WebView, it may have databases there for its own caches. Third-party libraries might have databases as well. It may make sense to back all of them up as well, in which case Plan A is ideal. But, perhaps you have reasons to only back up your own database.

You are in control over the name of the database file, as you provide it to your RoomDatabase as a part of configuring the RoomDatabase.Builder:

Room.databaseBuilder(ctxt.getApplicationContext(), ToDoDatabase.class, "stuff.db").build();

Here, stuff.db is the name of the database.

It is possible that Room and SQLite will have more files than just this one, though. Ideally, that will not be the case. But, you may want to consider backing up all files that begin with your database name, as other files, such as ones with -shm or -wal suffixes, might be around.

One risk with this would be if Room started writing other files of its own, instead of just whatever SQLite uses. The same risk holds if you use other SupportSQLiteDatabase implementations.

Beware of Open Rooms

The preview of this section may contain nuts.

When Do We Back Up the Database?

The preview of this section was the victim of a MITM ('Martian in the middle') attack.

A Basic Backup Example

The preview of this section is unavailable right now, but if you leave your name and number at the sound of the tone, it might get back to you (BEEEEEEEEEEEEP!).

Backing Up Off-Device

The preview of this section was fed to a gremlin, after midnight.