Is it possible to clone a device and make a backup with all apps and settings

General
1

I know it is possible to back up my home partition via ssh. And I know how to restore this backup.
But I want to do that as well with the root directory. Is that possible?
I want to avoid to install every program manually again.

I have two JP2026 and my main phone starts to collect dust under the front camera, so now I want to clone the whole device (if possible), to see, if both devices are faulty, before I contact Jolla.

6 Likes
2

I was wondering the same thing.
As before with dd and an image.
The first who dares will know what fails and what works;-]

Factory reset process

ALL DATA WILL BE ERASED! Clears everything from the device and reverts the
software back to factory state. This means LOSING EVERYTHING you have added to
the device (e.g. updates, apps, accounts, contacts, photos and other media).
Are you really SURE? [y/N] [y/N] y
2 logical volume(s) in volume group “sailfish” now active
[OK] No lockcode has been set. Proceeding…
0 logical volume(s) in volume group “sailfish” now active
0 logical volume(s) in volume group “sailfish” now active
Logical volume “root” successfully removed.
Logical volume “home” successfully removed.
Volume group “sailfish” successfully removed
Labels on physical volume “/dev/sdc71” successfully wiped.
Physical volume “/dev/sdc71” successfully created.
Volume group “sailfish” successfully created
Logical volume “root” created.
Wiping LUKS signature on /dev/sailfish/home.
Logical volume “home” created.
resize2fs 1.47.2 (1-Jan-2025)
Resizing the filesystem on /dev/sailfish/root to 2560000 (4k) blocks.
The filesystem on /dev/sailfish/root is now 2560000 (4k) blocks long.

resize2fs 1.47.2 (1-Jan-2025)
Resizing the filesystem on /dev/sailfish/home to 58350592 (4k) blocks.
The filesystem on /dev/sailfish/home is now 58350592 (4k) blocks long.

/var/lib/platform-updates/flash-bootimg.sh …
Using blkid to lookup device
Flashing to /dev/sdc33
5266+0 records in
5266+0 records out
21569536 bytes (20.6MB) copied, 0.045062 seconds, 456.5MB/s
Using blkid to lookup device
Flashing to /dev/sdc60
5266+0 records in
5266+0 records out
21569536 bytes (20.6MB) copied, 0.071683 seconds, 287.0MB/s
OK
/var/lib/platform-updates/flash-connsys_bt.sh …
Using blkid to lookup device
Flashing to /dev/sdc38
Uncompressing ‘/boot/connsys_bt.img.gz’ to ‘/tmp/tmp.ut0tJc’..
188+1 records in
188+1 records out
771616 bytes (753.5KB) copied, 0.002770 seconds, 265.7MB/s
Using blkid to lookup device
Flashing to /dev/sdc63
Uncompressing ‘/boot/connsys_bt.img.gz’ to ‘/tmp/tmp.C4E300’..
188+1 records in
188+1 records out
771616 bytes (753.5KB) copied, 0.003502 seconds, 210.1MB/s
OK
/var/lib/platform-updates/flash-connsys_gnss.sh …
Using blkid to lookup device
Flashing to /dev/sdc40
Uncompressing ‘/boot/connsys_gnss.img.gz’ to ‘/tmp/tmp.opZuVv’..
128+1 records in
128+1 records out
527680 bytes (515.3KB) copied, 0.002845 seconds, 176.9MB/s
Using blkid to lookup device
Flashing to /dev/sdc65
Uncompressing ‘/boot/connsys_gnss.img.gz’ to ‘/tmp/tmp.ksrLVE’..
128+1 records in
128+1 records out
527680 bytes (515.3KB) copied, 0.003998 seconds, 125.9MB/s
OK
/var/lib/platform-updates/flash-connsys_wifi.sh …
Using blkid to lookup device
Flashing to /dev/sdc39
Uncompressing ‘/boot/connsys_wifi.img.gz’ to ‘/tmp/tmp.q4KqVe’..
375+1 records in
375+1 records out
1536224 bytes (1.5MB) copied, 0.010732 seconds, 136.5MB/s
Using blkid to lookup device
Flashing to /dev/sdc64
Uncompressing ‘/boot/connsys_wifi.img.gz’ to ‘/tmp/tmp.JnQTLv’..
375+1 records in
375+1 records out
1536224 bytes (1.5MB) copied, 0.012198 seconds, 120.1MB/s
OK
/var/lib/platform-updates/flash-dpm.sh …
Using blkid to lookup device
Flashing to /dev/sdc25
Uncompressing ‘/boot/dpm.img.gz’ to ‘/tmp/tmp.EzTZ6F’..
332+1 records in
332+1 records out
1360256 bytes (1.3MB) copied, 0.008754 seconds, 148.2MB/s
Using blkid to lookup device
Flashing to /dev/sdc52
Uncompressing ‘/boot/dpm.img.gz’ to ‘/tmp/tmp.plTfVc’..
332+1 records in
332+1 records out
1360256 bytes (1.3MB) copied, 0.009293 seconds, 139.6MB/s
OK
/var/lib/platform-updates/flash-dtbo.sh …
Using blkid to lookup device
Flashing to /dev/sdc36
11+1 records in
11+1 records out
46080 bytes (45.0KB) copied, 0.000732 seconds, 60.0MB/s
Using blkid to lookup device
Flashing to /dev/sdc66
11+1 records in
11+1 records out
46080 bytes (45.0KB) copied, 0.002918 seconds, 15.1MB/s
OK
/var/lib/platform-updates/flash-gpueb.sh …
Using blkid to lookup device
Flashing to /dev/sdc30
Uncompressing ‘/boot/gpueb.img.gz’ to ‘/tmp/tmp.qOE9TU’..
127+1 records in
127+1 records out
520960 bytes (508.8KB) copied, 0.003721 seconds, 133.5MB/s
Using blkid to lookup device
Flashing to /dev/sdc57
Uncompressing ‘/boot/gpueb.img.gz’ to ‘/tmp/tmp.CoNwKX’..
127+1 records in
127+1 records out
520960 bytes (508.8KB) copied, 0.003206 seconds, 155.0MB/s
OK
/var/lib/platform-updates/flash-gz.sh …
Using blkid to lookup device
Flashing to /dev/sdc31
Uncompressing ‘/boot/gz.img.gz’ to ‘/tmp/tmp.aTviqb’..
498+1 records in
498+1 records out
2043088 bytes (1.9MB) copied, 0.008313 seconds, 234.4MB/s
Using blkid to lookup device
Flashing to /dev/sdc58
Uncompressing ‘/boot/gz.img.gz’ to ‘/tmp/tmp.oorklD’..
498+1 records in
498+1 records out
2043088 bytes (1.9MB) copied, 0.004455 seconds, 437.4MB/s
OK
/var/lib/platform-updates/flash-init_boot.sh …
Using blkid to lookup device
Flashing to /dev/sdc35
2+0 records in
2+0 records out
8192 bytes (8.0KB) copied, 0.000555 seconds, 14.1MB/s
Using blkid to lookup device
Flashing to /dev/sdc62
2+0 records in
2+0 records out
8192 bytes (8.0KB) copied

3

If a factory reset is the only danger, I would try to jump into cold water, but I fear a boot loop.
So I hope to get a qualified answer of some people with deeper knowledge.

4

Of course there is. Search for “full dd backup”.

5

I did this successfully in 2019 with an Xperia 10. It was a backup of that phone that went back onto the same device, though, not a clone onto a second one. That difference matters but i think it will work similiar.

How I did it back then (Xperia 10, 2019)

  1. Extract hybris-recovery.img from the official Sailfish X image and boot it without flashing it: fastboot boot hybris-recovery.img

  2. telnet 10.42.66.66, enter the security code, open the shell and start sshd.

  3. Stream the entire eMMC to the PC:

    ssh 10.42.66.66 "dd if=/dev/mmcblk0 bs=1M | gzip -1 -" | dd of=backup.img.gz

    (gzip only because xz/lzma didn’t work in the recovery’s busybox.) 29 GB took about 50 minutes at ~10 MB/s.

  4. To restore, write it back the same way: gunzip -c backup.img.gz | dd of=/dev/mmcblk0 bs=1M

How it would work on the Jolla Phone today, in theory (not recommended)

  • Root and home both live in one partition, userdata. The LVM group sailfish on it contains root (~10 GB) and home (~220 GB, LUKS-encrypted with the security code). The factory reset log posted above shows exactly this group being recreated.

  • The phone has the familiar Jolla recovery, just packaged differently. There’s no separate recovery partition. It’s a small “recovery” fragment inside the vendor_boot ramdisk. Same as on the Xperias: telnet to 10.42.66.66 over USB, a menu with Shell and Run sshd (login root / recovery), both protected by the security code. Busybox dd, xz, pigz, lvm and cryptsetup are all there.

  • So you would copy only userdata, never the whole flash. With both phones in recovery and connected to one PC:

    ssh <A> "dd if=/dev/block/by-name/userdata bs=4M" | ssh <B> "dd of=/dev/block/by-name/userdata bs=4M"

    Both recoveries use the same IP, so either readdress one of them or go via an image file on the PC.

Why I wouldn’t do it

  • Never copy the whole flash to another device. Partitions like nvdata, nvcfg, nvram and protect1/2 hold the IMEI and the RF calibration for that specific unit. Copy them and phone B ends up with A’s IMEI and wrong calibration, and in the worst case a dead modem. “Full dd backup” is right for restoring the same phone and wrong for cloning to another.
  • It’s huge and slow. The 220 GB encrypted home looks like random data and doesn’t compress. I guess it will take ages.
  • Every device identity gets duplicated: machine-id, SSH host keys, Bluetooth pairings, the Android ID in App Support. Device-bound apps such as messengers and banking apps get confused, and the Jolla account might see the same device twice.

What I’d do instead (much simpler)

  1. Settings → Backup on the old phone, restore it on the new one. One known catch: restored email accounts can receive but not send. Mails stay in the outbox and the account switches to “needs to be updated”, and re-entering the passwords doesn’t help. The reason is that the outgoing (SMTP) credentials don’t survive the restore. Fix, if outgoing and incoming use the same user name and password (most providers do):

    devel-su -p ag-tool list-accounts
devel-su -p ag-tool list-settings <id> | grep -i credentials
# note CredentialsId (incoming) and smtp/CredentialsId (outgoing)
devel-su -p ag-tool update-service <id> email int:smtp/CredentialsId=<incoming CredentialsId>
devel-su -p ag-tool update-account <id> bool:CredentialsNeedUpdate=false
systemctl --user restart messageserver5

    Details and background: [5.2.0.16][JP26] IMAP Mail Account from SFOS Backup can't send Mails . The alternative is to delete the account and add it again with “Manual settings”.

  2. Export the list of native apps on the old phone:

    rpm -qa --qf '%{NAME}\n' | grep -E '^harbour-|^openrepos-' > apps.txt

    Then reinstall them on the new phone with pkcon install $(cat apps.txt) (as root/devel-su). Add the Chum and OpenRepos repositories first if you used them.

  3. Copy /home via SSH/rsync, minus anything device-specific if you prefer a clean start. Android apps: reinstall them from your store, and their data comes back with /home/.appsupport or via the apps’ own backups.

That takes about an hour, nothing on the new phone is tied to the old phone’s identity, and you can do it again any time.

7 Likes
6

Wait for my backupapp and it will be easy

11 Likes
7

Yes, backup is nice but dd to an image is so straightforward.
You have a clone and that’s it.

Sure, we could do the same as we did before, with Xperias.
The first one just has to dare.

But as @Fellfrosch said, bootloop is perhaps lying in wait…
(btw, by pasting the reset process, it was for the partitions numbers. I haven’t been explicit)

2 Likes
8

Very good and detailed write down.

dd on different devices is not a very good idea, indeed. Maybe only the home partition may work. But as @ric9k said, one has to jump first :wink:.

I do prefer your other approach! :+1: with some aannotatios:

Install @slava ‘s MyBackup, mark everything you like. (You may also mark directory .config or even ~, but I like to start fresh)

move all images, videos, documents manually (via SD/computer/rsync to new device)

Make a backup on old device

Get list of apps, install chum (and openrepos) on new device.

Restore the backup on new device.

Install all listed apps

–

You listed problem with accounts, furthermore WiFi and BT connections are not transferred…

–

And, if someone is brave enough (for JP2 I would wait until flashable image is out) this should be done only on same device model. And both devices should be updated to same firmware (android blobs) and as well SFOS versions.

3 Likes
9

Furthermore, regarding:

This is again some internal configuration, cache and runtime data.

Some user data (like WhatsApp chat and media data) is under:
~/android_storage/Android

10

Won’t resist much longer… I feel it. biggrin

Not sure I have a big enough uSD, though…

11

Sooo, yes, it seems to work! :partying_face:
I cloned one JP2 on another.
The second JP2 survived!

So far, the phone boots, my home is there, fingerprints are all there and wifi connections work.
Camera, Mail, Fernie, Phone, SMS, BT music on my speaker, all work.
Wifi mac addresse is ok and IMEI too.
I didn’t test it extensively yet, but it seems to work normally.

Hickup: both BT mac addresses are now the same.

Disclaimer:
Use these commands at your own risk and only if you understand them and know exactly what they do.
An error can result in a data loss and/or unbootable system.
The recovery might not work anymore.
Your phone can become a brick.

To clone an XA2, there is a similar method here.

Unlike the XA2 method, which uses a microSD, here, the image file is made on the PC.
Netcat is used to transport the image from/to the phones/PC.
The image size is 233GB, which could perhaps, perhaps fit on a 256GB uSD.

JP2/JP2026 only.
Here is the method I used, probably not the cleanest/shortest.
Read to the end before starting, PC and disk space are needed.

Assuming you already are in the recovery shell, option 3.

Create the image file from phone 1:

On the Source Phone:

  • cd /
  • umount /rootfs/proc
  • umount /rootfs/dev
  • umount /rootfs
  • Deactivate the LVM volumes
    lvm vgchange -an sailfish
  • Prepare to transmit to the PC
    dd if=/dev/sdc71 bs=16M | nc -l -p 1234

On the PC:
Prepare to receive the data, and store it into an img file.

  • nc -d 10.42.66.66 1234 | pv -s 249493946368 > /the_path_ and_file_name_you_like.img
    pv is used to show the progression (with the partition size) but you can use the command without it. Just remove the | pv -s 249493946368 part
  • Once finished, you can verify the image size with
    stat -c %s /the_path_ and_file_name_you_like.img (should be 249493946368)
  • You also can verify if the partition and image file have the same sum. Too long, I didn’t, but it should be done for a serious work.
    md5sum /the_path_ and_file_name_you_like.img
    And on the phone: md5sum /dev/sdc71

Exit the shell on the phone with exit
dd took approx 1h48.

Apply the image file to the phone 2

First, create a backup of the second phone with the method above.

On the second phone:
Then, assuming you already are in the recovery shell, option 3:

  • cd /
  • umount /rootfs/proc
  • umount /rootfs/dev
  • umount /rootfs
  • Deactivate the LVM volumes
    lvm vgchange -an sailfish
  • verify that the size is the same as on the first phone (should be 487292864)
    cat /sys/class/block/sdc71/size
  • Prepare to receive the image from the PC
    nc -l -p 1234 | dd of=/dev/sdc71 bs=16M

On the PC:

  • Send the image to the phone
    pv /the_path_ and_file_name_you_like.img | nc -N 10.42.66.66 1234

When it is finished, back on the second phone:

  • Write everything that is in memeory
    sync (not sure if really needed, as we wrote on the partition but well…)
  • Calculate the partition md5sum Too long, I didn’t, but it should be done for a serious work.
    Must be the same as on the PC
    md5sum /dev/sdc71
  • Exit, reboot
    exit

dd took approx 2h02.

One question stays open:
How to get an unique BT MAC address back for the cloned phone?

edit:
To get the original BT MAC address back:
In terminal, devel-su:
Seee the wrong MAC:

cat /var/lib/bluetooth/board-address

Refresh the installer packages list

pkcon refresh

Install the BT tools package

pkcon install bluez5-tools

See the correct MAC:

bluetoothctl list

Copy the correct MAC from the above command answer and paste it
echo “EX:AM:PL:E0:ON:LY” > /var/lib/bluetooth/board-address

Reboot
Verify it holds.

3 Likes
12

@Fellfrosch what do you think:
This serves to clone a JP2 but also to make a full backup, with the whole installed/adjusted system.
Should the thread be renamed accordingly to help finding it?

2 Likes