Android 13 and SailfishOS on Xperia 10 III

Tint

Well, maybe I was roo quick to comment on «tint». My «tint» has always been what’s seen below:

It’s a weird paint blobbish thing generated by overlaying app switcher cards with launcher icons. That’s still here with A12 binaries flash.

But maybe it’s not at all what @wetab73 has been referring to as «tint»? EDIT and wow, just looked at this screenshot on laptop: no tint, blob, banding or whatever! Whereas it’s clearly visible on phone screen.

Regardless, end of day 2, everything is still working great otherwise. It probably makes sense to have A12 as your SFOS base.

PS did you see my App Support vs Location win from y-day (maybe OpenGApps-specific): GPS/Location not working for Android apps - #38 by lkraav

I don’t know if it’s the same but sometimes i do have some weird transparencies with previously opened apps, like i load a webpage on the browser, then close it and open fernschreiber, and i see the webpage all over sailfish elements, althought it’s hardly noticeable…

Wondering if it’s the same, especially since i’m on an xa2…

I see that it is still misunderstood. It is NOT the binaries what fixes the tint/banding and the echo issues. It is the UNDERLYING ANDROID 12 (or 13) OS, the one that you flash using EMMA, and then you flash SFOS on top of it. Binaries alone (i.e. what you flash to the oem_a partition) actually don’t seem to be doing anything regarding those specific issues.

So, once again, in order to get the display tint/banding and the echo issues fixed you need to flash Android OS using EMMA. You need either Android 12 (tested with 62.1.A.0.675, i.e. the last Android 12 update, I don’t know if earlier versions already had those fixes or not) or Android 13. But EMMA only offers Android 11 or Android 13, there is no Android 12 flashable image available via EMMA. So either you simply flash Android 13 via EMMA (tested by me and found fully working, actually I didn’t notice any differences vs. Android 12), or if you prefer Android 12 (as per Jolla recommendations) then the only way to get it is to flash Android 11 (version .109) via EMMA, then re-lock the bootloader in order to be able to get OTA updates inside Android, and then spend a few hours on installing one by one all consecutive (8 or so) Android 11 and then Android 12 OTA updates within Android itself, until you reach the 62.1.A.0.675 version. Then you need to unlock the bootloader again, and flash SFOS on top of it.

That’s the ONLY way to have the tint/banding and echo fixed, as those fixes are in the base Sony Android OS, not in the binaries.

P.S. You can’t illustrate the banding or tint issue on a screenshot. It is a technical issue of the display, it is not visible on a screenshot. You’d need to take a photo of the display.

But you DON’T have A12 as SFOS base. So far you only have A12 binaries, which don’t change anything regarding the display banding/tint and echo…

3 Likes

Sorry if this is already here somewhere, but i can backup my phones partitions, install android 13, install sfos and then restore my partitions?
thus no fresh sfos install?

1 Like

Yes, you can backup rootfs and home in recovery and then restore the same way. It gives a perfect 100% restore. The partition to backup (containing both rootfs and home) on the 10 III is /dev/sda79

6 Likes

But before restoring your backup, you need to start SFOS once. If you restore it directly after flashing, Sailfish will not boot.

4 Likes

That’s right. So the whole procedure is as follows:

  • backup SFOS (/dev/sda79 partition containing rootfs and home)
  • flash Android using EMMA
  • boot Android once
  • flash fresh SFOS and boot it once
  • restore SFOS from backup.
9 Likes

I am sure that it is also in this thread, but due to so much information here I am a little bit lost:
how do I backup and restore the partition correctly ( with a Linux box)?

1 Like

You do it in recovery. So the procedure for the 10 III is as follows:

  1. flash hybris-recovery.img to both boot_a and boot_b slots:
fastboot flash boot_a hybris-recovery.img
fastboot flash boot_b hybris-recovery.img
fastboot reboot
  1. go to recovery (by simply rebooting the device)

  2. telnet to the device from your computer:

telnet 10.42.66.66
  1. select option 3) (shell), then enter your security code

  2. mount your microSD card (at least 105 GB of free space is needed for an uncompressed backup):

mount /dev/mmcblk0p1 /mnt

  1. do the backup:

dd if=/dev/sda79 of=/mnt/backup.img bs=1M

It may take 40+ minutes (or even more than one hour with a slower memory card). No progress is shown. If you would like to see progress, open another telnet connection and type:

watch -n5 'kill -USR1 $(pgrep ^dd$)'

This will show progress every 5 seconds.

  1. When backup is complete, unmount memory card:

umount /mnt

and then exit recovery mode.

Finally, flash the normal hybris-boot.img to both boot slots:

fastboot flash boot_a hybris-boot.img
fastboot flash boot_b hybris-boot.img
fastboot reboot

That’s all.

The backup can be restored the same way as you created it, i.e. by typing:

dd if=/mnt/backup.img of=/dev/sda79 bs=1M

15 Likes

Thanks for this comprehensive explanation!

2 Likes

Indeed, I never got “full Android flash required” from your previous posts, it always seemed like binaries only would do.

Well, couple of days ago I did end up discovering Android camera access is now broken with no clear way to revive it. Since binaries alone don’t change the game, I’m going to flash A12 binaries back to A11.

Are you sure about this? I.e. have you tried after reflashing the Sony software binaries recommended by Jolla?

Such effects are expected when using Sony software binaries which are incompatible to SailfishOS. But I cannot tell for sure, because I do not own an Xperia 10 III.

Up to now, the identified differences an Android 11 base versus an Android 12 / 13 base makes are “tint on screen”, “caller echo” and <IIRC there was a third thing>.

Hence please first reflash the Sony software binaries to the version Jolla recommend and check your camera issue (and report the outcome here), before flashing an Android 12 or 13 onto your Xperia 10 III.

One week later and everything runs great.
No issues at all (color - echo), battery is good and the camera lag was probably a random thing that day.
Latest Android 13 with latest Android 12 binaries works great!
I have no clue about anything related to app support since I didn’t get my license transferred yet, but I don’t think there will be an issue there.

4 Likes

I’m not sure if I follow. You’re saying that since binaries don’t change anything, you’re going to flash A12 binaries back to A11? Aren’t you still confusing binaries with the underlying OS?

Anyway, I’ve been using Android 12 binaries with underlying Android 12 OS (62.1.A.0.675) for weeks and both native and Android camera applications (e.g. Open Camera) have been working perfectly fine.

After weeks of tests, I dare to say that there are no apparent compatibility issues between Android 12 binaries SW_binaries_for_Xperia_Android_12_4.19_v2a_lena and SFOS, at least when running on top of Android 12 OS version 62.1.A.0.675.

2 Likes

Thank you @wetab73 for the excellently written guide how to backup the complete SailfishOS installation (on an Xperia 10 III).

May I suggest to use compression, and as nitpicks a block-size of 4 MBytes (i.e. the LVM extent size chosen by Jolla) and to avoid overwriting extant backups:

  • See if zstd is available (it compresses better and faster):
    Type zstd and hit the <Return>-key , which should output “Incorrect parameters, Usage : …
  • If zstd is there, backup with Zstandard compression (the whole statement comprises a single command-line):
    set -C; dd if=/dev/sda79 bs=4M | zstd -o /mnt/backup-sda79_$(date -I).img.zst
  • If not, use gzip (xz is way too slow; again, the whole statement comprises a single command-line):
    set -C; dd if=/dev/sda79 bs=4M | gzip >/mnt/backup-sda79_$(date -I).img.gz

Restore can be achieved by:

  • With zstd (the whole statement comprises a single command-line):
    zstd -dc /mnt/backup-sda79_<date>.img.zst | dd of=/dev/sda79 bs=4M
  • With gzip (the whole statement comprises a single command-line):
    gzip -dc /mnt/backup-sda79_<date>.img.gz | dd of=/dev/sda79 bs=4M

P.S.: As @thigg correctly pointed out, only the LVM meta-data and the content of the root volume are compressible, the whole home volume is not due to its encryption. Hence one might as well perform the backup as @wetab73 suggested, because there are only a few Gigabytes to be saved by compression, at most.

10 Likes

I took a backup via ssh to my pc (takes 40 minutes, will post about that soon) and flashed android 13 and restored sfos afterwards. Havent tested calling, but i got still color banding when using nightish and lowest settings in a dark room. That should have been fixed, right?

because I thought the sda* partitions might contain the relevant drivers that cause the issues, i took a md5sum of them before and after, it is a bit too much to say something useful:

I provide the old md5sums I had and the diff:
diff:

diff --git a/tmp/old b/tmp/new
index 7bb0f29..93fcf37 100644
--- a/tmp/old
+++ b/tmp/new
@@ -1,2 +1,2 @@
-e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-007ec8391d63b93930f8449b863accc0  /dev/sda10
+2586918fc1ecdae354e2427a2edf6902  /dev/sda1
+4de894c4dadaa70aae3dcc5766ab78e0  /dev/sda10
@@ -4 +4 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-27fcc4fa141aaec55bfdde9fcf6c84d7  /dev/sda12
+102c4498928ac352a8e4f1be56c1d2c2  /dev/sda12
@@ -6 +6 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-42a6ce1c2d1747391f4743b2670acff1  /dev/sda14
+477597e459db3b5231ab42a2237f6c0f  /dev/sda14
@@ -8 +8 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-2347da6148ea049d2ad78690d5227f9f  /dev/sda16
+6f8d584dd16d6d0b8cec84b32ad41abc  /dev/sda16
@@ -10 +10 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-0a8b76dedc07210760dd44303cbea572  /dev/sda18
+48d7aa155820adbe62e4370a3502f1ac  /dev/sda18
@@ -12,2 +12,2 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-94b5534c612e3bf0563f3a6e1fc14a47  /dev/sda2
-5218bbf0e502ce84ba4dff6a2de871ba  /dev/sda20
+0432b2ab35d6d60a9f37753a08981791  /dev/sda2
+5f806eeaf66191dd71c36c9483fb0e89  /dev/sda20
@@ -15 +15 @@ e481e56d09ca07b2fa4448f271b99403  /dev/sda1
-c6190b191f2a2f55f9a5ba027c345092  /dev/sda22
+70d4975a0f9138a563f6492f5fcbca0a  /dev/sda22
@@ -18,3 +18,3 @@ c6190b191f2a2f55f9a5ba027c345092  /dev/sda23
-fd804f859d9f7102c6d68ea61707f138  /dev/sda25
-7bd2d7f05ad8dd57c9ce7f11c1523c9f  /dev/sda26
-5c814dee9289e976802dc891da80ce2d  /dev/sda27
+199f0bc90633c552ddb21995f993818e  /dev/sda25
+ded91389d631c60871a339901ec41508  /dev/sda26
+7a0f78f6112f9f814fd2783d00b5e722  /dev/sda27
@@ -23 +23 @@ fd804f859d9f7102c6d68ea61707f138  /dev/sda25
-f82fcab470a03c312025a8288eb79ce1  /dev/sda3
+e431450dbe927c9cd10f1dc6ef1df68e  /dev/sda3
@@ -25,3 +25,3 @@ b2d1236c286a3c0704224fe4105eca49  /dev/sda30
-1b8bfc261189599f37b6f89e6d2ec7d6  /dev/sda31
-f77348792c03568e4236b9d9490dd1bb  /dev/sda32
-86d880a15cf6e6ba3fa34e5ae431f94c  /dev/sda33
+23802113e8727533dc030b6b9ea3b6a3  /dev/sda31
+41d1145b70e8c3f0c7c3b37689230c9e  /dev/sda32
+d1d3c6de1a3d3fd0370f2c226100e96a  /dev/sda33
@@ -29 +29 @@ d38381ce2086c7a8e4c767f8f3caa9c4  /dev/sda34
-8c2bd0f42ef61377f4bf52772956786a  /dev/sda35
+f7fd0e91558accd935ed74c84ee08c8b  /dev/sda35
@@ -31 +31 @@ b2a2923c37a46c6be9e134835d282746  /dev/sda36
-af45a4d533b0c0e766078ab012c72b02  /dev/sda37
+a956763a3d3c966512ac6f1aff2967f3  /dev/sda37
@@ -33 +33 @@ af45a4d533b0c0e766078ab012c72b02  /dev/sda37
-061658910eccb973a4daf5f4292d0b55  /dev/sda39
+b0d3fd3adb3fb95d97327eb00b760f62  /dev/sda39
@@ -41 +41 @@ b6d81b360a5672d80c27430f39153e2c  /dev/sda45
-a9263ff8d9d5900da184cb5bd1a44632  /dev/sda46
+c08b512d66aa5aa05f9593a7db2746db  /dev/sda46
@@ -46 +46 @@ e17110ca5e335533aa21d0f1ea17aa43  /dev/sda48
-a02b4dc0be465b2c839b29e154898b3c  /dev/sda50
+d9f7f705c134690d91e98fd7daa1b8b2  /dev/sda50
@@ -48,3 +48,3 @@ a02b4dc0be465b2c839b29e154898b3c  /dev/sda50
-6446c5a40abcb47031f5ec31426926f4  /dev/sda52
-d51c8763b8e658a954b270ae809ad97c  /dev/sda53
-665750e6f8b5fc93e7f028c0514e2a85  /dev/sda54
+5a6cc56ca9f9f1050a9700eca8f7ffa5  /dev/sda52
+bfb6adc871cf4fc1c51ba6471ac03e70  /dev/sda53
+2391cddd5b04402ad83e37d0ad68bfa6  /dev/sda54
@@ -56 +56 @@ d51c8763b8e658a954b270ae809ad97c  /dev/sda53
-3403d386cb5fd3e7322283cb31532c63  /dev/sda6
+bcfe7be70f6eb695bffb4f75b6501271  /dev/sda6
@@ -59 +59 @@ bb7df04e1b0a2570657527a7e108ae23  /dev/sda61
-ce88c6b15abea1759623be492054cf66  /dev/sda62
+352bfc11216f28c624ec5771acd5069d  /dev/sda62
@@ -61 +61 @@ ce88c6b15abea1759623be492054cf66  /dev/sda62
-64500a0fd8bec3c68afd4ed1f53adc15  /dev/sda64
+fd982621bc410c2ed45953dd37a8498d  /dev/sda64
@@ -63 +63 @@ ce88c6b15abea1759623be492054cf66  /dev/sda62
-cbe88d7afe8e9fecfc77260739154b0f  /dev/sda66
+cf952b13aa4b2306811e9b175a6c1c12  /dev/sda66
@@ -74,4 +74,4 @@ bb7df04e1b0a2570657527a7e108ae23  /dev/sda75
-6c0be22b941d172176b4d4ff294e879d  /dev/sda76
-48938e0b52fb4c94b2fa5f0488289ca3  /dev/sda77
-d492fba22f216704c921bb5c6ac7bf46  /dev/sda78
-cde8bf40ec223a9f8ecdd551b9d16150  /dev/sda8
+deb1cee12c10af0683046d2f9dbca52a  /dev/sda76
+ca9a43b79d8c1148f4c86150072a6b9d  /dev/sda77
+f67e07f0863ea91efbb511870b02ecf6  /dev/sda78
+df84682a7db29a000e39366480a3ad28  /dev/sda8

old md5sums:

e481e56d09ca07b2fa4448f271b99403  /dev/sda1
007ec8391d63b93930f8449b863accc0  /dev/sda10
007ec8391d63b93930f8449b863accc0  /dev/sda11
27fcc4fa141aaec55bfdde9fcf6c84d7  /dev/sda12
27fcc4fa141aaec55bfdde9fcf6c84d7  /dev/sda13
42a6ce1c2d1747391f4743b2670acff1  /dev/sda14
42a6ce1c2d1747391f4743b2670acff1  /dev/sda15
2347da6148ea049d2ad78690d5227f9f  /dev/sda16
2347da6148ea049d2ad78690d5227f9f  /dev/sda17
0a8b76dedc07210760dd44303cbea572  /dev/sda18
0a8b76dedc07210760dd44303cbea572  /dev/sda19
94b5534c612e3bf0563f3a6e1fc14a47  /dev/sda2
5218bbf0e502ce84ba4dff6a2de871ba  /dev/sda20
5218bbf0e502ce84ba4dff6a2de871ba  /dev/sda21
c6190b191f2a2f55f9a5ba027c345092  /dev/sda22
c6190b191f2a2f55f9a5ba027c345092  /dev/sda23
0dfbe8aa4c20b52e1b8bf3cb6cbdf193  /dev/sda24
fd804f859d9f7102c6d68ea61707f138  /dev/sda25
7bd2d7f05ad8dd57c9ce7f11c1523c9f  /dev/sda26
5c814dee9289e976802dc891da80ce2d  /dev/sda27
5c814dee9289e976802dc891da80ce2d  /dev/sda28
567954c1d8697ecee75b42015ad05513  /dev/sda29
f82fcab470a03c312025a8288eb79ce1  /dev/sda3
b2d1236c286a3c0704224fe4105eca49  /dev/sda30
1b8bfc261189599f37b6f89e6d2ec7d6  /dev/sda31
f77348792c03568e4236b9d9490dd1bb  /dev/sda32
86d880a15cf6e6ba3fa34e5ae431f94c  /dev/sda33
d38381ce2086c7a8e4c767f8f3caa9c4  /dev/sda34
8c2bd0f42ef61377f4bf52772956786a  /dev/sda35
b2a2923c37a46c6be9e134835d282746  /dev/sda36
af45a4d533b0c0e766078ab012c72b02  /dev/sda37
006ca871d0a903acae485cb715e036ef  /dev/sda38
061658910eccb973a4daf5f4292d0b55  /dev/sda39
71bcc0aff65ee22d74d0e7f00843b439  /dev/sda4
061658910eccb973a4daf5f4292d0b55  /dev/sda40
620f0b67a91f7f74151bc5be745b7110  /dev/sda41
ec87a838931d4d5d2e94a04644788a55  /dev/sda42
9be23059b49ace87900d3acb118ab25e  /dev/sda43
fa310ff1fa5d3ceb967fec98e5c60ea8  /dev/sda44
b6d81b360a5672d80c27430f39153e2c  /dev/sda45
a9263ff8d9d5900da184cb5bd1a44632  /dev/sda46
0dfbe8aa4c20b52e1b8bf3cb6cbdf193  /dev/sda47
e17110ca5e335533aa21d0f1ea17aa43  /dev/sda48
0829f71740aab1ab98b33eae21dee122  /dev/sda49
71bcc0aff65ee22d74d0e7f00843b439  /dev/sda5
a02b4dc0be465b2c839b29e154898b3c  /dev/sda50
59071590099d21dd439896592338bf95  /dev/sda51
6446c5a40abcb47031f5ec31426926f4  /dev/sda52
d51c8763b8e658a954b270ae809ad97c  /dev/sda53
665750e6f8b5fc93e7f028c0514e2a85  /dev/sda54
96995b58d4cbf6aaa9041b4f00c7f6ae  /dev/sda55
31bdd65bf6182481f8265a851b9a5b7f  /dev/sda56
59071590099d21dd439896592338bf95  /dev/sda57
2c7ab85a893283e98c931e9511add182  /dev/sda58
620f0b67a91f7f74151bc5be745b7110  /dev/sda59
3403d386cb5fd3e7322283cb31532c63  /dev/sda6
bb7df04e1b0a2570657527a7e108ae23  /dev/sda60
bb7df04e1b0a2570657527a7e108ae23  /dev/sda61
ce88c6b15abea1759623be492054cf66  /dev/sda62
94cf525afed5753989b743bfc7308f9d  /dev/sda63
64500a0fd8bec3c68afd4ed1f53adc15  /dev/sda64
814aae80b92fe70d0cc0dfca31ebd35a  /dev/sda65
cbe88d7afe8e9fecfc77260739154b0f  /dev/sda66
cbe88d7afe8e9fecfc77260739154b0f  /dev/sda67
3631000c94b0ce94aa979208503508b3  /dev/sda68
3631000c94b0ce94aa979208503508b3  /dev/sda69
c6974e568ec7fa19cc53efc19ebb50b1  /dev/sda7
b6d81b360a5672d80c27430f39153e2c  /dev/sda70
59071590099d21dd439896592338bf95  /dev/sda71
b2d1236c286a3c0704224fe4105eca49  /dev/sda72
0dfbe8aa4c20b52e1b8bf3cb6cbdf193  /dev/sda73
bb7df04e1b0a2570657527a7e108ae23  /dev/sda74
bb7df04e1b0a2570657527a7e108ae23  /dev/sda75
6c0be22b941d172176b4d4ff294e879d  /dev/sda76
48938e0b52fb4c94b2fa5f0488289ca3  /dev/sda77
d492fba22f216704c921bb5c6ac7bf46  /dev/sda78
cde8bf40ec223a9f8ecdd551b9d16150  /dev/sda8
8f4e33f3dc3e414ff94e5fb6905cba8c  /dev/sda80
cde8bf40ec223a9f8ecdd551b9d16150  /dev/sda9

script to generate them:

for device in /dev/sda*; do
     if [[ "$device" != "/dev/sda" && "$device" != "/dev/sda79" ]]; then
         md5sum "$device"
     fi
 done
3 Likes

I took the backup via ssh to my laptop. Maybe this is interesting for some:
Backup and restore both take about 1 hour each, most of it without interaction.
Flashing android and reinstalling sfos took about 1h for me as well (most of the trouble was reviving a windows pc).
If you want to be really failsafe,mount your homepartition wiht cryptsetup after backup to make sure everything worked (either ungzip before cryptsetup or use avfs

  1. connect device in fastboot mode (volume up and plugin usb cable on a powerd off phone)
  2. flash recovery from the sailfishos distribution you use for flashing:
fastboot flash boot_a hybris-recovery.img
fastboot flash boot_b hybris-recovery.img
fastboot reboot
  1. telnet to the device from your computer:
telnet 10.42.66.66
  1. enter shell and prepare a public ssh key from your pc
mkdir /root/.ssh
chmod 600 /root/.ssh
echo "<your ssh key>">/root/.ssh/authorized_keys
exit
  1. launch sshd from the menu and connect to it by following the instructions (no password needed). You can exit again, if it works. I assume the ip 10.42.66.66 for the commands below.
  2. save backup: (pv shows the progress)
ssh root@10.42.66.66 "/usr/bin/pigz --stdout /dev/sailfish/root" | pv > 10IIIbackup-root.gzip
ssh root@10.42.66.66 "/usr/bin/pigz --stdout /dev/sailfish/home" | pv > 10IIIbackup-home.gzip
  • do your things (flash android via emma)
  • reinstall sfos
  • boot sfos
  • shutdown, enter fastboot flash recovery, reboot into recovery enter ssh (step 1-5)
  • restore your partitions
ssh root@10.42.66.66 -T "/usr/bin/pigz -d > /dev/sailfish/root" < 10IIIbackup-root.gz
ssh root@10.42.66.66 -T "/usr/bin/pigz -d > /dev/sailfish/home" < 10IIIbackup-home.gz

Comments:
using pigz (parallel gzip) is actually completly pointless on the home partition. This device is still encrypted (not what i was expecting) thus compression wont help anything.
Root partition should compress relativley good because this seems to be plain.
root partition backup and restore took about 1min, home partition backup 40min and restore 51min. The gzip command for the homepartition can be replaced by cat but shouldnt be a bottleneck with default parameters

7 Likes

I’m not confusing binaries and OS, but I never flashed full A12 OS here, just A12 binaries. So this last experiment was “A12 binaries on top of A11 OS”.

“Binaries don’t change anything” I should’ve worded better: A12 binaries on top of A11 OS caused a camera functionality regression. Everything else seemed to have stayed equal to my A11 binaries experience, hence no reason to try fix the camera regression in some other way.

I flashed A11 binaries back: Android camera functionality was immediately restored.

Thanks for SFOS partitions backup/restore guide: I will do a full A12 base flash after I’m back from US road trip, avoiding large risks during travel.

(US: where X10III lack of band 12 is definitely sub-optimal, see Sailfish in the USA - #244 by lkraav)

You introduced the necessity to reinstall SailfishOS only to restore the LVM volume layout by backing up on LVM volume level. IMO this is pretty senseless, either backup on block device level (/dev/sda79 for the Xperia 10 III) or on filesystem level for regular backups using tar (but the latter is unsuitable for the purpose here, i.e. backing up the complete SailfishOS installation).

If one wants to backup to another device (instead of on SD-card), the easiest way is to pipe into or from scp (in order not to resort to ancient tools as rcp or netcat).
I.e. for backing up
dd if=/dev/sda79 bs=4M | scp <user>@<host>:<directory>/backup-sda79_$(date -I).img
and for restoring
scp <user>@<host>:<directory>/backup-sda79_$(date -I).img | dd of=/dev/sda79 bs=4M

P.S. / Edit: Oops, scp does not seem to be able to read from or write to a pipe.

So one may try this (also untested):

  • Backup on your PC by
    ssh root@10.42.66.66 "/usr/bin/cat /dev/sda79" > backup-sda79_$(date -I).img
  • and restore from your PC by
    ssh root@10.42.66.66 -T "/usr/bin/cat > /dev/sda79" < backup-sda79_<hit-tab-to-autocomplete>.img

P.P.S.: @niquest did it by using netcat (nc).

1 Like