The EFI System Partition (ESP; your first partition) holds EFI boot loaders, so you must back it up. If you fail to do so, you won't be able to boot when you restore your OS partitions. A file-level backup (using tar, cp, or the like) is adequate for this, and in fact that's likely to be more efficient than a dd backup. A file-level backup will also make it easier to restore to an ESP that's a different size from the original -- dd creates an incomplete filesystem when restoring to a smaller device than the original, and so should never be used for that case. OTOH, a dd backup will preserve the filesystem's serial number, which Linux generally uses in /etc/fstab. If you do a file-level backup, you'll need to adjust /etc/fstab when you create a fresh filesystem and restore the files.
I've never before heard of "ms-tree" as a partition or filesystem type. In a standard Windows EFI installation, though, there is a Microsoft Reserved Partition, which is basically just empty space that Windows partitioning software can use as "scratch space" in future operations. AFAIK, it doesn't contain any long-term data, and so can be omitted from backups; however, if you want to be extra safe, you could do a dd backup of it.
Your third partition (your Windows C: drive) is obviously critical. I recommend either using a Windows backup tool to handle it or use ntfsclone in Linux. I don't recall if it's possible to restore to a smaller partition than the original when using ntfsclone, but I'm pretty sure it is possible to restore to a larger partition. The ntfsclone documentation says that a restored partition won't be bootable, but this is true only on BIOS-based computers; on an EFI system, an ntfsclone-created image should boot fine, provided the boot loader on the ESP is restored properly. (There may be issues with the partition table, though; I've never tested with restoring to a new disk.) Check the documentation for the Windows software if you use that option for backing up Windows.
Broadly speaking, restoring to a partition won't cause partition table issues -- that is, if you restore to /dev/sda1 (or whatever), the partition table won't be affected. The partition table is stored outside of any given partition, so to damage the partition table you'd need to abuse partitioning software (gdisk, parted, GParted, etc.) or write to the whole-disk device (/dev/sda). As just alluded to, though, software may refer to partitions by their GUID values, which are stored in the partition table. You can identify and change your partitions' GUID values with gdisk or sgdisk, as in:
sudo sgdisk -i 1 /dev/sda
Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System)
Partition unique GUID: 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6
First sector: 2048 (at 1024.0 KiB)
Last sector: 390625 (at 190.7 MiB)
Partition size: 388578 sectors (189.7 MiB)
Attribute flags: 1000000000000000
Partition name: 'EFI System'
This example shows the partition is an ESP (on the Partition GUID code line) and that it has a GUID value of 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6 (on the Partition unique GUID line). If you needed to replicate this data on another disk, you'd use the -u option to sgdisk, as in:
sudo sgdisk -u 1:2C47C282-EE6E-45DE-A5AD-E8658CA67DE6 /dev/sda
This sets the unique GUID for partition 1 to 2C47C282-EE6E-45DE-A5AD-E8658CA67DE6. There are other ways to do this, too; consult the gdisk and sgdisk man pages for details. I'd like to emphasize that this might not be necessary, though. What's more, replicating GUIDs unnecessarily can cause problems, particularly if the original and new disks will be used together in the same computer. That's because these values are supposed to be unique, so if two partitions have the same GUID, some software's assumptions may be violated. The main reason you'd want to do this is if a boot loader or some other tool refers to partitions by their GUID values (also called the PARTUUID in some Linux tools). In that case, replicating the GUID values will let the software work without reconfiguration -- but adjusting the software's configuration will also work. The trouble is that how to reconfigure the software depends on the software.
