Full dd backup of rootfs and /home as flashable images

General
#1

Hi guys, is there any up-to-date guide of how to make full dd backup of rootfs and home partitions (and what else it takes in order to then be able to restore the device to the same state - maybe the Android partition?) as images which then could be used to reflash the device using Jolla’s standard flashing script?

I did search but the latest guides I’ve managed to find were from 2018-2019, so I guess they don’t account for rootfs and home encryption…

It would be really great to be able to fully backup the device before OS update, especially in case of EA releases…

Thanks in advance.

5 Likes
#2

Disk raw image created with dd. Can be converted to Android sparse image with command img2simg
On Debian/Ubuntu package android-sdk-libsparse-utils needs to be installed.
I don’t know if LUKS partition encryption causes problems.

#3

Probably varies a bit from phone to phone, but I think once you know where your system and userdata files are, (mmcblk0p[something]), then a simple “dd if=mmcblk0p[whatever] of=system.img”, etc, should be fine. Then you can restore with fastboot flash.

The problem I’ve had to work around before is handling such large files, depending on your OS, etc. Sometimes they don’t copy paste too well, and need to find workaround, (e.g. Windows’ 4g copy/paste limit, I was able to get around using a Linux ext4 recovery program, [Linux Reader or something like that])…

#4

Can we really restore such a backup with fastboot flash?

I backup my phone into an image file like this in linux as root (but advised is to use sudo instead of being root):

Also keep in mind A WRONG MANIPULATION/COMMND CAN RUIN YOUR PHONE or at least YOUR OS !!!

  • Turn off the phone
  • Insert an ext3/4 formatted uSD >= 32GB
  • Hold upper Vol key while plugging to the computer
  • cd to the directory where you unpacked SFOS when you flashed it
  • fastboot boot ./hybris-recovery.img # boot your phone in recovery mode
  • Wait some seconds
  • telnet 10.42.66.66 # Connect to your phone
  • Choice #3
  • Agree you void the warranty
  • Enter your device lock
  • mount /dev/mmcblk1p1 /mnt #mount the uSD

Depending on your phone, the partition will be different.
Here, mmcblk0p76 is for XA2.

  • dd if=/dev/mmcblk0p76 of=/mnt/the_file_name_you_want.img bs=16M # takes 20-30 minutes
    In the case of the XA2, the output at the end of dd operation is:

1280+0 records in
1280+0 records out
21474836480 bytes (20.0GB) copied, 797.893119 seconds, 25.7MB/s

  • umount /mnt
  • Choose 6 to exit
  • Hold Vol Up + Power to reboot your phone

Now, you have the image containing the rootfs with encrypted home on your uSD.
Can really this image be flashed instead of doing all the above (but reversed) to restore?

5 Likes
Backup Strategies?
#5

[OT]
By the way, one can also clone the root partition + unencrypted home into the PC in a readable way (I don’t know how to open images)
Again, keep in mind A WRONG MANIPULATION/COMMND CAN RUIN YOUR PHONE or at least YOUR OS !!!

  • Turn off the phone
  • Hold upper Vol key while plugging to the computer
  • cd to the directory where you unpacked SFOS when you flashed it
  • fastboot boot ./hybris-recovery.img # boot your phone in recovery mode
  • Wait some seconds
  • telnet 10.42.66.66 # Connect to your phone
  • Choice #3
  • Agree you void the warranty
  • Enter your device lock
  • cryptsetup luksOpen /dev/sailfish/home myhome # myhome or any name you want
  • Input your lock code again
  • chroot /rootfs
  • mount /dev/mapper/myhome /home
  • 2 x CTRL-D # exit chroot, exit shell
  • Choice 5
  • accept, device lock
  • Open another terminal
  • mkdir /mnt/sfos # Create a dir tou mount your phone part in.
  • sshfs -o idmap=user,allow_other root@10.42.66.66:/ /mnt/sfos # mount the partition
  • rsync -vaHE --force --delete --recursive /mnt/sfos/rootfs/ /home/some_user/the_place_where_you_want_to_backup/ # Clone it (rsync options could be optimized)
  • fusermount -u /mnt/sfos # unmount yout partition, disconnect
  • Return to the previous terminal
  • Hit ENTER to quit sshd
  • chroot /rootfs
  • umount /home
  • CTRL-D
  • cryptsetup luksClose myhome
  • CTRL-D
  • Choose 6 to exit
  • Hold Vol Up + Power to reboot your phone
    [/OT]
2 Likes
Backup Strategies?
#6

I am currently using community port Xperia XZ2c, and haven’t tried it on this phone, but on my Xperia X Compact, it worked fine. Dd command to dump partitions to whatever.img, and then later fastboot flash system xxx.img, and fastboot flash userdata xxx.img, and phone was restored back to same state.

Fs structure on XZ2c is different, so same exact commands wouldn’t work, (I don’t think there’s any system.img), but it seems like the concept should be the same, if you know which partition is which…

#7

Great to know. Will be faster to restore than going through recovery.
Just as we are on it, for memory, do you remember the partition number for the Xperia X?

#8

Userdata 51
System 52

1 Like
#9

Fantastic! Tonight I’ll create images using both methods, just in case of any potential problems with restoring either encrypted or unencrypted home…

That’s what’s been puzzling me - whether one should restore it encrypted or unencrypted…

I won’t try restoring it at this point, as I have a perfecly working OS 4.4 since yesterday’s update and I don’t want to risk damaging it so soon. So testing how it restores will have to wait until something happens to my OS :grinning:

Thank you very much for such a step-by-step guide! If in the meantime someone uses it to both backup and restore, please report!

#10

https://together.jolla.com/question/176959/complete-flashable-image-of-the-os-as-backup/?answer=189770#post-id-189770

See the post before mine for in-depth info…

1 Like
#11

Just one more question to really make sure:

is the /dev/mmcblk0p76 partition on Xperia XA2 (Ultra) really the only one to image to have both rootfs and home included in it?

#12

Happy if it helps.
@Levone1 link is much more complete though.

I don’t know if XA2 Ultra works the same as XA2.

I use it all the time on 2 XA2, from one to another.
So I always have a stable one for daily use while I make experiments on the second one.
When/if the second one seems to be stable, it becomes the daily one.
If not, I clone the daily one on it and restart from a good base.

But again, I do it on XA2. No idea if Ultra partitions are organized the same.
@Levone1 link could help determining what is/are the good partition(s) by looking at the size, perhaps.

I do it too, as it is more convenient if all files are on the PC for greping files through the (phone) filesystem or search something.

#13

“ls -al /dev/block/platform/(something)/(something)/by-name”
(It’s different path/directory names depending on the phone/version, etc.)
Once you find the right path, ls -al command will output partition info with mmcblk number, size, and partition name…

The Android phone I’m using at the moment is
/dev/block/platform/soc/1d84000.ufshc/by-name

Output of ls -al is:

total 0
drwxr-xr-x 2 root root 1600 1971-01-26 10:57 .
drwxr-xr-x 3 root root 1680 1971-01-26 10:57 …
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 LTALabel → /dev/block/sda2
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 Qnovo → /dev/block/sda70
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 TA → /dev/block/sda1
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 abl_a → /dev/block/sda12
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 abl_b → /dev/block/sda24
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 aop_a → /dev/block/sda9
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 aop_b → /dev/block/sda21
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 apdp → /dev/block/sda54
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 appslog → /dev/block/sda68
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 bluetooth_a → /dev/block/sda34
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 bluetooth_b → /dev/block/sda44
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 boot_a → /dev/block/sda36
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 boot_b → /dev/block/sda46
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 cdt → /dev/block/sda64
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 cmnlib64_a → /dev/block/sda15
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 cmnlib64_b → /dev/block/sda27
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 cmnlib_a → /dev/block/sda14
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 cmnlib_b → /dev/block/sda26
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 ddr → /dev/block/sda8
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 devcfg_a → /dev/block/sda16
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 devcfg_b → /dev/block/sda28
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 devinfo → /dev/block/sda7
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 diag → /dev/block/sda69
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 dsp_a → /dev/block/sda35
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 dsp_b → /dev/block/sda45
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 dtbo_a → /dev/block/sda39
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 dtbo_b → /dev/block/sda49
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 frp → /dev/block/sda67
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 fsc → /dev/block/sda72
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 fsg → /dev/block/sda63
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 fsmetadata → /dev/block/sda71
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 hyp_a → /dev/block/sda11
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 hyp_b → /dev/block/sda23
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 keymaster_a → /dev/block/sda13
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 keymaster_b → /dev/block/sda25
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 keystore → /dev/block/sda66
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 limits → /dev/block/sda57
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 logdump → /dev/block/sda60
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 logfs → /dev/block/sda59
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 misc → /dev/block/sda65
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 modem_a → /dev/block/sda33
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 modem_b → /dev/block/sda43
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 modemst1 → /dev/block/sda61
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 modemst2 → /dev/block/sda62
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 msadp → /dev/block/sda55
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 oem_a → /dev/block/sda40
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 oem_b → /dev/block/sda50
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 persist → /dev/block/sda5
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 qupfw_a → /dev/block/sda17
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 qupfw_b → /dev/block/sda29
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 rddata → /dev/block/sda74
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 rdimage_a → /dev/block/sda37
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 rdimage_b → /dev/block/sda47
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 sec → /dev/block/sda53
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 spunvm → /dev/block/sda56
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 ssd → /dev/block/sda6
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 system_a → /dev/block/sda42
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 system_b → /dev/block/sda52
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 toolsfv → /dev/block/sda58
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tz_a → /dev/block/sda10
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tz_b → /dev/block/sda22
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tzxfl_a → /dev/block/sda20
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tzxfl_b → /dev/block/sda32
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tzxflattest_a → /dev/block/sda19
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 tzxflattest_b → /dev/block/sda31
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 userdata → /dev/block/sda73
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 vbmeta_a → /dev/block/sda38
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 vbmeta_b → /dev/block/sda48
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 vendor_a → /dev/block/sda41
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 vendor_b → /dev/block/sda51
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xbl_a → /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xbl_b → /dev/block/sdc1
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xbl_config_a → /dev/block/sdb2
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xbl_config_b → /dev/block/sdc2
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 xfl_a → /dev/block/sda18
lrwxrwxrwx 1 root root 16 1971-01-26 10:57 xfl_b → /dev/block/sda30
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xflkeystore → /dev/block/sda3
lrwxrwxrwx 1 root root 15 1971-01-26 10:57 xflkeystorebak → /dev/block/sda4

2 Likes
#14

OK, great, thank you!

And what about the Android stuff? Android app data is stored in /home so I guess nothing else is needed, but what about Android system files? It might be a good idea to image it too, both as a backup and also if I wanted to e.g. move it to another XA2.

#15

Last time I used a Sailfish phone with official Android support was a few years ago. I’m really not up on how that’s all set up … Seems like it would be included in wherever the Sailfish system files are (?)

#16

Oh, I didn’t say that: the image can of course only be flashed to a device which had the same OS/version.
I believe (believe), that the modified files during normal usage are only in this partition(s).
So the rest will be unchanged during usage. (so, no need to restore the rest).

I also believe all android user things are on the saved partition(s) but I don’t use android (yet).

1 Like
#17

Sorry, you mean android phone or SFos with android?

#18

I made an error in my second post about clone the root partition. Noww corrected. See edit history.
In rsync, it is

/mnt/sfos/rootfs/

instead of

/mnt/sfos/

#19

Some 1.5 years later, has someone succeeded in making full dd backup (and then restore) of rootfs and encrypted home of the 10 III and could share some details / experiences?

3 Likes
#20

OK, so I’ve finally tested it with XA2 Ultra. The partition to backup in this device is mmcblk0p76 and the resulting .img file is slightly above 20 GB. It contains both rootfs and home. Restoring it took about 10 minutes.

Restore went flawlessly, except for that the Android support itself did not restore. The App Support page in Settings wasn’t showing any information - all fields were empty, API level was shown as 0 and App Support couldn’t be started. But it only took uninstalling and reinstalling App Support from the Jolla store to make it work again like it was prior to backup.

So the question is: where does Android App Support get installed? Is it some other partition than rootfs and home? Clearly so. In such case, it would take making a backup of that other partition, too, in order to be able to restore the OS in an identical state, including a fully working App Support…

========

Now, the next thing to test is the 10 III. I already made a backup of it. The userdata partition on the 10 III is sda79.

Unlike in case of the XA2 Ultra where it is 20 GB, on the 10 III it is 128 GB, which is quite troublesome. In order to fit it on a 128 GB memory card, I had to gzip the backup on the fly, i.e.

dd if=/dev/sda79 | gzip > /mnt/userdata.img.gz

which compressed the image from over 100 GB to 19 GB. It took more than 1 hour to do it.

But I’m yet to take the risk to try to restore it, as the 10 III is my daily driver and I currently cannot afford to possibly screw it and have to reinstall everything from scratch. But I guess that I won’t resist it for too long and I’ll try it soon.

BTW. Is there some other way than dd to backup a partition to an image file, but only the “used” part rather than the entire partition, bit by bit, including all the unused space? It is extremely time and space consuming on the 10 III to have to backup (and then restore) the entire 128 GB…

5 Likes