The “rsync” command syncs two different folders/devices/drives/locations. Every system admin knows this command; theoretically. Imaging is a different animal… You can easy mount a EFI partition, copy the UEFI Windows boot files to a new EFI partition, and clone the NTFS partition moving the OS to a new drive. The extra Microsoft and OEM partitions are not so easily cloned without hardware cloning.
That’s why I started with qemu-img convert for the “whole” disk. If qemu-img can skip those 900G space that is not belonging to any partitions, it will be great.
My personally need is to preserve data - as in Linux / Fedora it is easy to fix boot loader problems (I never tried secure boot anyway) interactively. So changing UUID, rebuild /boot from scratch is relatively use to do inactively.
But for Windows boot, my confidence is not as high as for Linux boot.
It is a healthy fear, you have to preserve the Windows NTFS UUID for the boot loader to load the OS or use terminal commands to rebuild the EFI boot for the new UUID.
sudo -i
cd /
tar -acf bootefi.tar boot/
mount /dev/sda5 /mnt/ssd
mount /dev/sdb1 /mnt/backup
cd /mnt/ssd
btrfs sub snap -r root root.20210127
btrfs send root.20210127 | btrfs receive /mnt/backup
This way boot and ESP are backed up and in the snapshot that you send/receive. If sdb1 (HDD) isn’t Btrfs then you can use send -f option instead of receive.
sda3 is not backed up with this method so you’ll need a Windows specific backup for that; or maybe you could use guestfish to mount it and turn it into a sparse qcow2 image if you prefer. But such block copies aren’t exactly backups, they’re clones - bit unwieldy and aren’t easy to keep up to date.