How To Guide How to backup your partitions with command line (requires root)

Search This thread

How to backup partition images with dd on the command line (root required)​

  • We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
  • This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
  • You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.

Special partitions:

  • The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
  • The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.

Using a helper script:

There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.

On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.

So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')

And here's one that also skips super:
Code:
backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')

How to dump partitions manually:

If you can't/won't use the helper script you can do it by hand. All the following commands need root:

Find the names of all the partitions:
Code:
ls /dev/block/bootdevice/by-name/

Dump one specific partition identified by NAME:
Code:
dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img

Dump all partitions except userdata:
Code:
ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done

Find the active slot:
Code:
getprop ro.boot.slot_suffix

Get checksums for all the images after the dump:
Code:
md5sum *.img

Confused about _a and _b partitions?

You should read about A/B Seamless Updates.

Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.

This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.
 
I used a 128 GB card to take a backup of userdata. The backup script had some trouble with the backup location being on the storage card for some reason and I didn't have time to figure it out, but the dd command I gave above worked fine.

Code:
# time dd if=/dev/block/bootdevice/by-name/userdata of=userdata.img
112111374336 bytes (104 G) copied, 2342.274225 s, 46 M/s
   39m02.31s real     1m11.78s user    14m44.72s system

Code:
# adb pull /storage/1234-ABCD/backup/userdata.img ./
/storage/1234-ABCD/backup/userdata.img: 1 file pulled, 0 skipped.
87.2 MB/s (112111374336 bytes in 1225.663s)

So that's 104 GB that took 39 minutes to be written to a new Samsung Evo U3/V30 microSDXC (46 MB/sec real write speed) and 20 minutes to be read to the PC (Samsung Evo M.2) with adb pull over USB (87 MB/sec read speed). Just so you know what you're in for.
 
Last edited:
I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.

If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
Code:
# adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img

If you want to use the Python script:
Code:
# adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img

Using the same fast SSD on the PC side as above, I now get:

Code:
218967528+0 records in
218967528+0 records out
112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
real    17m57.910s

So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.
 
  • Like
Reactions: psychofaktory
Are you able to switch to a different backup location? Say a USB OTG if possible.
With dd yes, simply move to the directory you want before you call dd.

The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
 

mikeshutte

Member
Feb 21, 2015
33
10
With dd yes, simply move to the directory you want before you call dd.

The backup script is bugged and seems to ignore the -d parameter for the backup location so it always uses /sdcard/backup. (I think it might be expecting a different version of getopts...) Normally I would say to try creating a symlink from /sdcard/backup to the OTG storage but the ln utility is also behaving strangely and I can't make any symlinks (even with root).
Ok I'll give it a try and see what happens. Thanks for your help.
 

jakito

Senior Member
Aug 9, 2016
129
69
OnePlus 7 Pro
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?

Thanks!
 
Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?

Thanks!
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.

Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.

Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.

There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.

TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them. :(
 
Last edited:
  • Like
Reactions: jakito

jakito

Senior Member
Aug 9, 2016
129
69
OnePlus 7 Pro
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.

Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.

Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.

There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.

TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them. :(

I see. Thank you nonetheless!
 

Techguy777

Senior Member
This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.

Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.

Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.

There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.

TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them. :(
I don't know how I ended up but making a backup you can't restore is completely pointless.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 2

    How to backup partition images with dd on the command line (root required)​

    • We don't currently have a working custom recovery for the Xperia 10 III, but if you have root there's a simple method to dump partition images.
    • This is a very good idea and you should do it at least once, especially if you like to mess around the device a lot.
    • You won't be able to do this before you root, so by the time you do some partitions will not be stock anymore. Use XperiFirm instead to get the clean stock images.

    Special partitions:

    • The userdata partition holds all your personal files and system settings. It's huge (about 105 GB) and obviously you can't dump it into itself. You can dump it on an SD card if it's 128+ GB.
    • The super partition is a physical partition that contains several logical partitions (including system and vendor) That's why you won't find those in the partition list. This is done on Android 10+ devices to allow those logical partitions to be resized or rearranged as needed. You don't need to split out the internal logical partitions, you can flash back the entire super partition. The stock firmware also comes with a super image, not individual logical partitions.

    Using a helper script:

    There's a Magisk module called Backup (by Draco) which gives you a command line shell script you can use if you prefer. It mostly does the same things I described above. The script is here if anybody wants to just grab it directly.

    On the plus side, the script knows to dump only the active A/B image (which is the one that interests you most). On the flip side, it doesn't have a feature to skip userdata.

    So here is a shell command that will use the backup script to dump all partitions, but only those matching your device's active A/B slot, and skips userdata:
    Code:
    backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | sed 's/_[ab]$//')

    And here's one that also skips super:
    Code:
    backup $(ls /dev/block/bootdevice/by-name/ | grep -v userdata | grep -v super | sed 's/_[ab]$//')

    How to dump partitions manually:

    If you can't/won't use the helper script you can do it by hand. All the following commands need root:

    Find the names of all the partitions:
    Code:
    ls /dev/block/bootdevice/by-name/

    Dump one specific partition identified by NAME:
    Code:
    dd if=/dev/block/bootdevice/by-name/NAME of=NAME.img

    Dump all partitions except userdata:
    Code:
    ls /dev/block/bootdevice/by-name/ | grep -v userdata | while read NAME; do echo dd if=/dev/block/bootdevice/by-name/${NAME} of=${NAME}.img; done

    Find the active slot:
    Code:
    getprop ro.boot.slot_suffix

    Get checksums for all the images after the dump:
    Code:
    md5sum *.img

    Confused about _a and _b partitions?

    You should read about A/B Seamless Updates.

    Long story short, some partitions have two copies eg. boot_a and boot_b. When you boot up the device you use the partitions in one slot (eg. the _a partitions). When an OTA update is being downloaded, it writes into the partitions for the other slot (eg. the _b partitions). Your phone can stay in use while this happens. If the OTA fails nothing is broken, you just keep using the good slot partitions. After the OTA is successful you switch to the other slot and also have the previous version in the other slot in case you need to switch back.

    This means that some of the _a and _b images for the same partition can be different for you! So it's strongly recommended to do the checksums, and also to find out which is your active slot, so you know which partitions you're using right now.
    1
    I was looking into whether I could speed up the process of taking userdata snapshots by dumping the partition directly to the PC, but you need to be root to access the device block. The stock ROM doesn't allow the command adb root, but I found this blog post which made me realize you can run a su -c command that asks dd to write to stdout and just pipe the output to a file. The post author has also made this helpful Python script which lets you do pulls and pushes with root-only files.

    If you want to run the command directly (I've only tested on Linux, no idea if it works on PowerShell but it might):
    Code:
    # adb shell "su -c" "dd if=/dev/block/bootdevice/by-name/userdata" > userdata.img

    If you want to use the Python script:
    Code:
    # adb-root.py pull /dev/block/bootdevice/by-name/userdata userdata.img

    Using the same fast SSD on the PC side as above, I now get:

    Code:
    218967528+0 records in
    218967528+0 records out
    112111374336 bytes (104 G) copied, 1077.681097 s, 99 M/s
    real    17m57.910s

    So that's roughly 15 minutes compared to 1 hour total with the previous method and you don't need to have a 128 GB SD card anymore.
    1
    Hi, I'm used to TWRP backups, so I don't really understand this tool. I've backedup everything except the massive userdata partition. If needed, how would I restore this? Is the userdata partition required when I have all the others?

    Thanks!
    This is basically the same thing that TWRP does, dd is a command line Linux tool that makes a "raw" copy of a partition.

    Restoration is a bit more tricky. In theory you can simply dump the raw backup copy over the partition. The problem is that it's not ok to do it while the system is running. Typically it's done by booting into recovery (TWRP) and overwriting the partition from there.

    Another method for restore is to use fastboot, which is an alternative tool you can boot into that only does one thing, write partitions. But fastboot is typically locked by the vendor to only write signed images, so it can only be used to write official release ROMs.

    There are some limited uses for fastboot, such as overwriting the boot partition, which is not checked for signature anymore once you've unlocked the bootloader. So if you want to experiment with unofficial kernels and mess something up you can always restore a good boot partition with fastboot.

    TLDR: for the time being until we get a working TWRP recovery the most you can do is take backups, but not restore them. :(