How to backup the data partition¶

• Table of contents
• How to backup the data partition
  • /!\ Warning: Draft
  • What does the data partition contains?
  • Howto
    • • Galaxy S III (GT-I9300)
  • Using the backup
    • Restoring the partition
    • Restoring individual application data.
  • See also

/!\ Warning: Draft¶

This article is in draft form and is being written:

• Everybody is welcome to contribute
• Some things might not be accurate yet, so beware before using the information contained in it.

What does the data partition contains?¶

See DataPartition for more details.

Howto¶

TODO:

• Go in the recovery

Galaxy S III (GT-I9300)¶

First, you need to make sure that the data partition is not mounted.

To do that, you can run this command:

adb shell "umount -l /data" 

If the /data partition was mounted, it will unmount it. This will look like that:

$ adb shell "umount -l /data" 
$ 

If it was not mounted, it will instead show an error that we can ignore:

$ adb shell "umount -l /data" 
umount: /data: Invalid argument

Once this is taken care of, we can backup the partition with the following command:

adb pull /dev/block/platform/dw_mmc/by-name/USERDATA ./USERDATA.img

Using the backup¶

Restoring the partition¶

TODO

Restoring individual application data.¶

Here we will use the udisksctl command instead of the more classical mount and losetup as it integrates better with graphical environments like Gnome or KDE.

As the partition backup is now in a file, to access its data we will make it available as a partition again. This can be done with the following command:

udisksctl loop-setup -f  USERDATA.img

If that doesn't work you might need to use sudo like that:

sudo udisksctl loop-setup -f  USERDATA.img

Or you may also need to verify that your current users has the right to read and write the file that contains the partition (here USERDATA.img) file.

If this works, it should produce an output that looks more or less like that:

Mapped file USERDATA.img as /dev/loop0.

Here you can see that it made the file content available in the /dev/loop0 partition.

We can then reuse this information to mount that partition. We can do that with the following command:

udisksctl mount -b /dev/loop0 -o ro

The -o ro option will make sure that the partition is mounted in read only mode. This will make sure that we don't accidentally change its content.

The command above should produce an output that looks more or less like that:

Mounted /dev/loop0 at /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41

It most probably change a bit from the output above as:

• Your username is probably not gnutoo.
• The 2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41 is a randomly created identifier for the partition that is created when formatting it.
• Even /run/media/ can change depending on the GNU/Linux distribution and its version. For instance between Parabola and Trisquel 8 it is different.

You can write down the location of the directory where this partition is mounted (here /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41) as we will need it later on.

Now that this partition is mounted, we will be able to use the RestoreApplicationInternalData tutorial to make a backup of the data of a specific application and restore it.

To do that, locate the following command in the Backuping Silence's data from the old device section of the RestoreApplicationInternalData wiki page:

cd /data/data

You will then need to replace it by a command that looks like that:

cd /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41/data/

In the command above, you'll need to replace /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41/ by the location of the directory where the partition is mounted.

In addition you might not have the permissions to access the applications data.

For instance if you look at the permissions of the silence data you might have something that looks like that:

$ ls -ld org.smssecure.smssecure/
drwxr-x--x 9 10063 10063 4096 26 oct.  19:44 org.smssecure.smssecure/

See the How to find which directory holds the internal data of an application section in the RestoreApplicationInternalData wiki page for more details to understand why org.smssecure.smssecure directory has the Silence application's data.

In the output above, the first 10063 is the user ID and the second 10063 is the group id.

This is because Android sandboxes applications as part of their security model: each applications run in their own user and group ID. The result is that theses are most likely present on your phone but not on your GNU/Linux computer.

To fix that you can become root with the following command:

sudo su

Now you can then continue to follow the RestoreApplicationInternalData tutorial.

See also¶

• The BackupsResearch page has information on why the backup is done this way. It might also be useful to read and contribute to it if you intend to change the way the backups are done.