Replicant

h1. How to backup the data partition

{{toc}}

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

h2. What does the data partition contains?

See [[DataPartition]] for more details.

h2. Howto

h3. Setup ADB

Follow the instructions for [[ADB|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 [[ADB#Revoking-all-computers-USB-debugging-permissions|revoke these non-expiring permissions]] once the backup is complete.

h3. Reboot into the recovery

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

h3. Title TBD

h4. 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:

<pre>

adb shell "umount -l /data"

</pre>

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

<pre>

$ adb shell "umount -l /data"

$ 

</pre>

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

<pre>

$ adb shell "umount -l /data"

umount: /data: Invalid argument

</pre>

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

<pre>

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

</pre>

h2. Using the backup

h3. Restoring the partition

TODO

h3. 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:

<pre>

udisksctl loop-setup -f  USERDATA.img

</pre>

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

<pre>

sudo udisksctl loop-setup -f  USERDATA.img

</pre>

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:

<pre>

Mapped file USERDATA.img as /dev/loop0.

</pre>

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:

<pre>

udisksctl mount -b /dev/loop0 -o ro

</pre>

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:

<pre>

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

</pre>

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 [[RestoreApplicationInternalData#Backuping-Silences-data-from-the-old-device|Backuping Silence's data from the old device]] section of the RestoreApplicationInternalData wiki page:

<pre>

cd /data/data

</pre>

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

<pre>

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

</pre>

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:

<pre>

$ ls -ld org.smssecure.smssecure/

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

</pre>

See the [[RestoreApplicationInternalData#How-to-find-which-directory-holds-the-internal-data-of-an-application|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:

<pre>

sudo su

</pre>

Now you can then continue to follow the RestoreApplicationInternalData tutorial.

h2. 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.