Project

General

Profile

BackupTheDataPartition » History » Version 32

Denis 'GNUtoo' Carikli, 11/10/2020 07:43 PM
readlink: add Gt-i9100

1 1 Denis 'GNUtoo' Carikli
h1. How to backup the data partition
2
3
{{toc}}
4
5
h2. /!\ Warning: Draft
6
7
This article is in draft form and is being written:
8
* Everybody is welcome to contribute
9
* Some things might not be accurate yet, so beware before using the information contained in it.
10
11 3 Denis 'GNUtoo' Carikli
h2. What does the data partition contains?
12 1 Denis 'GNUtoo' Carikli
13 8 Denis 'GNUtoo' Carikli
See [[DataPartition]] for more details.
14 1 Denis 'GNUtoo' Carikli
15
h2. Howto
16
17 23 Denis 'GNUtoo' Carikli
h2. Reserve some space
18
19
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.
20
21
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.
22
23
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 [[GalaxySIIIGTI9300|Galaxy SIII (GT-I9300)]] wiki page has a [[GalaxySIIIGTI9300#Partitions|Partitions section]] with the relevant information, but only for the 16GiB version of that device.
24
25
26 15 Denis 'GNUtoo' Carikli
h3. Setup ADB
27
28
Follow the instructions for [[ADB|setting up ADB on your computer]] so that you can access a root shell on your device.
29
30
*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.
31
32
*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.
33
34
h3. Reboot into the recovery
35
36
To reboot in the recovery, you can follow the instructions in the [[RebootIntoTheRecovery]] wiki page.
37
38 16 Denis 'GNUtoo' Carikli
h3. Making sure that the data partition isn't mounted
39 1 Denis 'GNUtoo' Carikli
40
First, you need to make sure that the data partition is not mounted. 
41
42
To do that, you can run this command:
43
<pre>
44
adb shell "umount -l /data"
45
</pre>
46
47 18 Denis 'GNUtoo' Carikli
If the /data partition was mounted, it will unmount it, and your command and its output will look more or less like that:
48 1 Denis 'GNUtoo' Carikli
<pre>
49
$ adb shell "umount -l /data"
50
$ 
51
</pre>
52
53 18 Denis 'GNUtoo' Carikli
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:
54 1 Denis 'GNUtoo' Carikli
<pre>
55
$ adb shell "umount -l /data"
56
umount: /data: Invalid argument
57
</pre>
58
59 16 Denis 'GNUtoo' Carikli
h3. Backuping the data partition
60
61
Once we verified that the data partition isn't mounted, we can finally backup the partition.
62
63 31 Denis 'GNUtoo' Carikli
h4. Galaxy SII (GT-I9100)
64
65
For the Galaxy SII (GT-I9100), this can be done from your computer with this command:
66
<pre>
67
adb pull /dev/block/platform/dw_mmc/by-name/DATAFS ./USERDATA.img
68
</pre>
69
70 16 Denis 'GNUtoo' Carikli
h4. Galaxy S III (GT-I9300)
71
72
For the Galaxy S III (GT-I9300), you can use the following command:
73 1 Denis 'GNUtoo' Carikli
<pre>
74
adb pull /dev/block/platform/dw_mmc/by-name/USERDATA ./USERDATA.img
75 16 Denis 'GNUtoo' Carikli
</pre>
76
77 26 Denis 'GNUtoo' Carikli
h4. Galaxy Nexus (GT-I9250)
78
79
For the Galaxy Nexus (GT-I9250), you can use the following command:
80
<pre>
81
adb pull /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata ./USERDATA.img
82
</pre>
83
84 30 Denis 'GNUtoo' Carikli
h4. Galaxy Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510)
85
86
For the Tab 2 (GT-P3100, GT-P3110, GT-P5100, GT-P3510), you can use the following command:
87
88
<pre>
89
adb pull /dev/block/platform/omap/omap_hsmmc.1/by-name/DATAFS ./USERDATA.img
90
</pre>
91 26 Denis 'GNUtoo' Carikli
92 16 Denis 'GNUtoo' Carikli
h4. Other devices.
93
94
We don't have instructions yet for other devices yet.
95
96
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.
97 10 Denis 'GNUtoo' Carikli
98
h2. Using the backup
99
100
h3. Restoring the partition
101
102 27 Denis 'GNUtoo' Carikli
h4. Finding the real path of the partition
103
104 20 Denis 'GNUtoo' Carikli
Before we did command like that to backup the device:
105
<pre>
106
adb pull /dev/block/platform/dw_mmc/by-name/USERDATA ./USERDATA.img
107
</pre>
108
109 22 Denis 'GNUtoo' Carikli
However if we use the following command:
110
<pre>
111
adb push USERDATA.img /dev/block/platform/dw_mmc/by-name/USERDATA
112 1 Denis 'GNUtoo' Carikli
</pre>
113 22 Denis 'GNUtoo' Carikli
114 25 Denis 'GNUtoo' Carikli
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.
115 22 Denis 'GNUtoo' Carikli
116 25 Denis 'GNUtoo' Carikli
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:
117 22 Denis 'GNUtoo' Carikli
<pre>
118 1 Denis 'GNUtoo' Carikli
adb: error: failed to copy 'USERDATA.img' to '/dev/block/platform/dw_mmc/by-name/USERDATA': remote No space left on device
119
USERDATA.img: 0 files pushed. 4.3 MB/s (436154368 bytes in 96.842s)
120
</pre>
121 22 Denis 'GNUtoo' Carikli
122 28 Denis 'GNUtoo' Carikli
So to avoid that we will need to find the path that symlink points to.
123 1 Denis 'GNUtoo' Carikli
124 27 Denis 'GNUtoo' Carikli
The sections below documents how to do if for various devices.
125
126 32 Denis 'GNUtoo' Carikli
You should also really not skip that part, and make sure that the commands in these sections don't output any error.
127 1 Denis 'GNUtoo' Carikli
128 32 Denis 'GNUtoo' Carikli
h4. Galaxy SII (GT-I9100)
129
130
For the Galaxy SII (GT-I9100), we can get the symlink path with the following command:
131
<pre>
132
adb shell "readlink /dev/block/platform/dw_mmc/by-name/DATAFS"
133
</pre>
134
135
On my Galaxy SII (GT-I9100), 16GiB version, it gives the following:
136
<pre>
137
/dev/block/mmcblk0p10
138
</pre>
139
140 1 Denis 'GNUtoo' Carikli
h5. Galaxy SIII (GT-I9300)
141 27 Denis 'GNUtoo' Carikli
142 32 Denis 'GNUtoo' Carikli
For the Galaxy SIII (GT-I9300), we can get the symlink path with the following command:
143 22 Denis 'GNUtoo' Carikli
<pre>
144
adb shell "readlink /dev/block/platform/dw_mmc/by-name/USERDATA"
145 1 Denis 'GNUtoo' Carikli
</pre>
146
147 27 Denis 'GNUtoo' Carikli
On my Galaxy SIII (GT-I9300), 16GiB version, it gives the following:
148 1 Denis 'GNUtoo' Carikli
<pre>
149 25 Denis 'GNUtoo' Carikli
/dev/block/mmcblk0p12
150 1 Denis 'GNUtoo' Carikli
</pre>
151
152
You will then need to down the result (here @/dev/block/mmcblk0p12@) as we will reuse it later.
153
154 27 Denis 'GNUtoo' Carikli
h5. Galaxy Nexus (GT-I9250)
155 1 Denis 'GNUtoo' Carikli
156 27 Denis 'GNUtoo' Carikli
For the Galaxy Nexus (GT-I9250) We can get the symlink path with the following command:
157
<pre>
158
adb shell "readlink /dev/block/platform/omap/omap_hsmmc.0/by-name/userdata"
159
</pre>
160 1 Denis 'GNUtoo' Carikli
161 27 Denis 'GNUtoo' Carikli
h5. Other devices
162
163
We don't have instructions yet for other devices yet.
164
165
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.
166
167
h5. Do not skip the sections above
168
169
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.
170
171
So make sure to do that right.
172
173
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).
174
175
h5. Actually restoring the partition
176 25 Denis 'GNUtoo' Carikli
177 29 Denis 'GNUtoo' Carikli
To restore the data partition, you could use the following command:
178 1 Denis 'GNUtoo' Carikli
<pre>
179 25 Denis 'GNUtoo' Carikli
adb push USERDATA.img /dev/block/PARTITION
180 22 Denis 'GNUtoo' Carikli
</pre>
181
182 25 Denis 'GNUtoo' Carikli
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.
183
184
If everything goes fine, the output of the command above should look like this:
185 22 Denis 'GNUtoo' Carikli
<pre>
186 25 Denis 'GNUtoo' Carikli
USERDATA.img: 1 file pushed. 3.6 MB/s (1760559104 bytes in 466.067s)
187 10 Denis 'GNUtoo' Carikli
</pre>
188
189
h3. Restoring individual application data.
190
191
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.
192
193
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:
194
<pre>
195
udisksctl loop-setup -f  USERDATA.img
196
</pre>
197
198
If that doesn't work you might need to use @sudo@ like that:
199
<pre>
200
sudo udisksctl loop-setup -f  USERDATA.img
201
</pre>
202
203
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.
204
205
If this works, it should produce an output that looks more or less like that:
206
<pre>
207
Mapped file USERDATA.img as /dev/loop0.
208
</pre>
209 19 Denis 'GNUtoo' Carikli
210 10 Denis 'GNUtoo' Carikli
Here you can see that it made the file content available in the @/dev/loop0@ partition. 
211
212
We can then reuse this information to mount that partition. We can do that with the following command:
213
<pre>
214
udisksctl mount -b /dev/loop0 -o ro
215
</pre>
216
217
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.
218
219
The command above should produce an output that looks more or less like that:
220
<pre>
221
Mounted /dev/loop0 at /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41
222
</pre>
223
224
It most probably change a bit from the output above as:
225
* Your username is probably not @gnutoo@.
226
* The @2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41@ is a randomly created identifier for the partition that is created when formatting it.
227
* Even @/run/media/@ can change depending on the GNU/Linux distribution and its version. For instance between Parabola and Trisquel 8 it is different.
228
229 1 Denis 'GNUtoo' Carikli
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.
230 19 Denis 'GNUtoo' Carikli
231
We will also reuse the partition location (here @/dev/loop0@) at the end.
232 10 Denis 'GNUtoo' Carikli
233
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.
234
235
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:
236 12 Denis 'GNUtoo' Carikli
<pre>
237 10 Denis 'GNUtoo' Carikli
cd /data/data
238
</pre>
239
240
You will then need to replace it by a command that looks like that:
241
<pre>
242
cd /run/media/gnutoo/2Of967c7-ac7e-7ae0-ef5b-30f0b6e2dc41/data/
243
</pre>
244
245
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.
246
247
In addition you might not have the permissions to access the applications data. 
248 17 Denis 'GNUtoo' Carikli
249 1 Denis 'GNUtoo' Carikli
For instance we can look at the permissions of the silence data with the following command:
250 17 Denis 'GNUtoo' Carikli
<pre>
251
ls -ld org.smssecure.smssecure/
252
</pre>
253
254
And it should give you something that looks more or less like that:
255 11 Denis 'GNUtoo' Carikli
<pre>
256
drwxr-x--x 9 10063 10063 4096 26 oct.  19:44 org.smssecure.smssecure/
257 1 Denis 'GNUtoo' Carikli
</pre>
258 11 Denis 'GNUtoo' Carikli
259
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.
260
261
In the output above, the first @10063@ is the user ID and the second @10063@ is the group id. 
262
263
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.
264 10 Denis 'GNUtoo' Carikli
265
To fix that you can become root with the following command:
266
<pre>
267
sudo su
268
</pre>
269 1 Denis 'GNUtoo' Carikli
270 19 Denis 'GNUtoo' Carikli
Now you can then continue to follow the RestoreApplicationInternalData tutorial.
271
272
h4. Unmount and close the loop
273
274
Once you are finished with the RestoreApplicationInternalData tutorial, it would be a good idea to umount the data partition and make it inaccessible again.
275
276
To umount the data partition we can use a command that looks like that:
277
<pre>
278
udisksctl unmount -b /dev/loop0
279
</pre>
280
Here the @/dev/loop0@ may differ, so make sure to use the partition location you used earlier.
281
282
The output of that command will look like that:
283
<pre>
284
Unmounted /dev/loop0.
285
</pre>
286
287
Once it is unmounted you can make it inaccessible again with the following command:
288
<pre>
289
udisksctl unmount -b /dev/loop0
290
</pre>
291
292
Again here may will need to replace @/dev/loop0@ by your partition location if it differs.
293
294
The output of that command should then show something that looks like that:
295
<pre>
296
Unmounted /dev/loop0.
297 1 Denis 'GNUtoo' Carikli
</pre>
298
299
h2. See also
300
301
* 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.