Project

General

Profile

Actions

How to backup the data partition

/!\ 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

Reserve some space

The data partition is often big as it contains space for user data. For instance on the Galaxy SIII (GT-I9300), its size is about 11.5GiB for the 16GiB versions of that device.

If you don't need to know precisely how much space it's going to take, you could make sure that you have as much space as the internal storage. For instance for a Galaxy SIII (GT-I9300) with 16GiB of internal storage, just make sure you have 16GiB of free space.

If instead you need to know the size more precisely (here 11.5GiB), you could look if your device's page has that information in its Partition section. For instance the Galaxy SIII (GT-I9300) wiki page has a Partitions section with the relevant information, but only for the 16GiB version of that device.

Setup ADB

Follow the instructions for setting up ADB on your computer so that you can access a root shell on your device.

NOTE: when prompted on your Replicant device, make sure that you check the box that says Always allow from this computer when you grant your computer USB debugging permissions. Otherwise, you will be unable to obtain root shell access on your Replicant device when you reboot it into the recovery OS to actually perform the backup.

NOTE: for security reasons, you may want to revoke these non-expiring permissions once the backup is complete.

Reboot into the recovery

To reboot in the recovery, you can follow the instructions in the RebootIntoTheRecovery wiki page.

Making sure that the data partition isn't mounted

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, and your command and its output will look more or less like that:

$ adb shell "umount -l /data" 
$ 

If it was not mounted, it will instead show an error that we can ignore. In this case your command and its output will look more or less like that:

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

Backing up the data partition

Once we verified that the data partition isn't mounted, we can finally backup the partition.

Galaxy SII (GT-I9100) and Galaxy Note (GT-N7000)

For the Galaxy SII (GT-I9100) and the Galaxy Note (GT-N7000), this can be done from your computer with this command:

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

Galaxy S III (GT-I9300, GT-I9305), Galaxy Note II (GT-N7100) and Galaxy Note 8.0 (GT-N51xx)

For the Galaxy S III (GT-I9300), Galaxy S III 4G (GT-I9305), Galaxy Note II (GT-N7100), and Galaxy Note 8.0 (GT-N51xx) you can use the following command:

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

Galaxy Nexus (GT-I9250)

For the Galaxy Nexus (GT-I9250), you can use the following command:

adb pull /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata ./USERDATA.img

Galaxy Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510)

For the Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510), you can use the following command:

adb pull /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS ./USERDATA.img

Other devices.

We don't have instructions yet for other devices yet.

Feel free to request instructions for the device you have on IRC, the mailing list, or to add the instructions here if you're confortable enough with the command line.

Using the backup

Restoring the partition

Finding the real path of the partition

Before we did command like that to backup the device:

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

However if we use the following command:

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

It will fail to write any data to the partition: Instead of writing to it, it deletes the /dev/block/platform/dw_mmc/by-name/USERDATA symlink and recreate a file at the same path with the data from USERDATA.img.

Since no data is being written on the disk, it most often ends up exhausting the ramdisk of the recovery (which is smaller than the data partition) and we are left with this error:

adb: error: failed to copy 'USERDATA.img' to '/dev/block/platform/dw_mmc/by-name/USERDATA': remote No space left on device
USERDATA.img: 0 files pushed. 4.3 MB/s (436154368 bytes in 96.842s)

So to avoid that we will need to find the path that symlink points to.

The sections below documents how to do if for various devices.

You should also really not skip that part, and make sure that the commands in these sections don't output any error.

Galaxy SII (GT-I9100)

For the Galaxy SII (GT-I9100), we can get the symlink path with the following command:

adb shell "readlink /dev/block/platform/dw_mmc/by-name/DATAFS" 

On my Galaxy SII (GT-I9100), 16GiB version, it gives the following:

/dev/block/mmcblk0p10

Galaxy SIII (GT-I9300)

For the Galaxy SIII (GT-I9300), we can get the symlink path with the following command:

adb shell "readlink /dev/block/platform/dw_mmc/by-name/USERDATA" 

On my Galaxy SIII (GT-I9300), 16GiB version, it gives the following:

/dev/block/mmcblk0p12

You will then need to down the result (here /dev/block/mmcblk0p12) as we will reuse it later.

Galaxy Nexus (GT-I9250)

For the Galaxy Nexus (GT-I9250) We can get the symlink path with the following command:

adb shell "readlink /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata" 

Other devices

We don't have instructions yet for other devices yet.

Feel free to request instructions for the device you have on IRC, the mailing list, or to add the instructions here if you're confortable enough with the command line.

Do not skip the sections above

If you skip the sections above and use the wrong partition, for instance if you blindly copy /dev/block/mmcblk0p12 from this tutorial instead of running the commands above and copying the result of these commands, you could end up breaking your device because some partitions are really needed for the device to work.

So make sure to do that right.

This is also why we have backup instructions (like BackupTheEFS ) to backup important partitions, however other partitions than the EFS are probably crucial too (but less susceptible to data corruption as they are not constantly written to).

Actually restoring the partition

To restore the data partition, you could use the following command:

adb push USERDATA.img /dev/block/PARTITION

Make sure to replace /dev/block/PARTITON with the data you just wrote down. The example above uses /dev/block/mmcblk0p12, but it might differ for your device, so make sure to replace /dev/block/mmcblk0p12 with the result you got on your device.

If everything goes fine, the output of the command above should look like this:

USERDATA.img: 1 file pushed. 3.6 MB/s (1760559104 bytes in 466.067s)

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.

We will also reuse the partition location (here /dev/loop0) at the end.

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 we can look at the permissions of the silence data with the following command:

ls -ld org.smssecure.smssecure/

And it should give you something that looks more or less like that:

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.

Unmount and close the loop

Once you are finished with the RestoreApplicationInternalData tutorial, it would be a good idea to umount the data partition and make it inaccessible again.

To umount the data partition we can use a command that looks like that:

udisksctl unmount -b /dev/loop0

Here the /dev/loop0 may differ, so make sure to use the partition location you used earlier.

The output of that command will look like that:

Unmounted /dev/loop0.

Once it is unmounted you can make it inaccessible again with the following command:

udisksctl unmount -b /dev/loop0

Again here may will need to replace /dev/loop0 by your partition location if it differs.

The output of that command should then show something that looks like that:

Unmounted /dev/loop0.

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.

Updated by Kurtis Hanna about 1 month ago ยท 39 revisions