BackupsResearch » History » Revision 15
Revision 14 (Denis 'GNUtoo' Carikli, 01/20/2020 09:43 AM) → Revision 15/24 (doak complex, 01/20/2020 09:55 AM)
h1. BackupsResearch
{{>toc}}
h2. Introduction
The [[BackupTheEFS]] page has instructions to backup the EFS. This page instead tries to document why it is done in that way, and what are the advantages and disadvantages of various other backups methods.
This can also be useful to write more generic backup instructions to do a more complete backup.
h2. Doing the backup of partitions or other block devices
h3. adb shell cat pipe
Old versions of the "EFS backup instructions":https://redmine.replicant.us/projects/replicant/wiki/BackupTheEFS (revision 17) used the following command:
<pre>
adb shell "cat /dev/block/platform/*/by-name/EFS > /EFS.img"
</pre>
At some point or under some condition, this stopped working and the backup were corrupted.
h3. adb shell cat adb pull
With something like that:
<pre>
adb shell "cat /dev/block/platform/*/by-name/EFS > /EFS.img"
adb pull /EFS.img ./
</pre>
doing it in two stages like that seem to be widely used in other instructions (like the ones found in XDA forums).
Normally cat should produce a valid backup, however it might be better to use dd for extra safety.
On Replicant 6.0 0004, at least the recoveries for the following devices have 'dd':
* Galaxy Nexus
* Galaxy SIII
h3. adb pull the block device
The following should also work:
<pre>
adb pull /dev/block/mmcblk0p3 ./EFS.img
</pre>
The advantage is that it can also backup huge partitions like the user data partition or Replicant system partition.
TODO:
* Validate if doing "adb pull /dev/block/platform/*/by-name/EFS ./EFS.img" work, and if so, validate it for all the devices.
* [by doak] No, it does not (expansion of @*@ fails), but this would do:
<pre>
part="`adb shell "ls /dev/block/platform/*/by-name/EFS" | head --bytes=-2`"
adb pull "$part" ./EFS.img
</pre>
Be aware of the @head --bytes=-2@ which is needed to get rid of the nasty @0x0d 0x0a@ line ending returned by @adb@.
(Tested on Recovery of Replicant 6.0 0003.)
h2. Backup applications.
It might be a good idea to have a list of backup applications and/or to ship one with Replicant.
* This backup app might be a good option for Replicant 9 or 10: https://github.com/stevesoltys/backup
* F-droid might also has applications. As F-droid packages are not all FSDG compliant, we would need to make sure that the backup application we recommend or ship are FSDG compliant.
It might also be a good idea to understand if the backup solution chosen is sustainable in the long term: If the development stop or upstream decide to make the new version proprietary some users might have a hard time adapting to new backup applications or systems.