BackupsResearch

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.

Doing the backup of partitions or other block devices

adb shell cat pipe

Old versions of the EFS backup instructions (up to revision 17) used the following command:

adb shell "cat /dev/block/platform/*/by-name/EFS" > EFS.img

At some point or under some condition, this stopped working and the backup were corrupted.

adb shell cat adb pull

With something like that:

adb shell "cat /dev/block/platform/*/by-name/EFS > /EFS.img" 
adb pull /EFS.img ./

Two steps

Doing it in two stages like that seem to be widely used in other instructions (like the ones found in XDA forums).

The advantage is that the '*' enables to use the same command across many more devices.

And we need two steps because the '*' is not interpreted by a shell when using adb pull:

$ adb pull /dev/block/platform/*/by-name/EFS
adb: error: remote object '/dev/block/platform/*/by-name/EFS' does not exist
$ adb pull "/dev/block/platform/*/by-name/EFS" 
adb: error: remote object '/dev/block/platform/*/by-name/EFS' does not exist
$ adb pull '/dev/block/platform/*/by-name/EFS'
adb: error: remote object '/dev/block/platform/*/by-name/EFS' does not exist

See the part on adb-pull-the-block-device for more details on how to workaround the lack of expansion and have only 1 command to do the job.

This method requires the partition to be small enough. Otherwise it will create several issues:

dd

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':

adb pull the block device

The following should also work:

adb pull /dev/block/mmcblk0p3 ./EFS.img

The advantage is that it can also backup huge partitions like the user data partition or Replicant system partition.

You cannot do adb pull /dev/block/platform/*/by-name/EFS as the expansion of * will fail.

There are possible workarounds:

part="`adb shell "ls /dev/block/platform/*/by-name/EFS" | head --bytes=-2`" 
adb pull "$part" ./EFS.img

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

Symlinks and adb push

adb push doesn't handle symlinks properly. For instance, with a Galaxy SIII (GT-I9300) with a Replicant 6 recovery, if we use:

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

we get the following failure:
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 here no data has been being written on the data partition and it exhausted the ramdisk of the recovery.

This is because instead of writing to that partition, it deleted the /dev/block/platform/dw_mmc/by-name/USERDATA symlink and recreated a file at the same path (/dev/block/platform/dw_mmc/by-name/USERDATA) with the data from USERDATA.img.

Backup applications

It might be a good idea to have a list of backup applications and/or to ship one with Replicant.

As of 2024, many after market distributions are using SeedVault. It seems a good candidate to ship by default on Replicant.

F-Droid also has other 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 may also be a good idea to understand if the backup solution chosen is sustainable in the long term. If development stops or upstream decides to make the new version proprietary some users might have a hard time adapting to new backup applications or systems.