Linux: ZFS analog of pvmove - how to move data off from vdev?

I need to expand disk capacity of the server. The pool was started with 1Tb disk, then it was expanded with 2Tb disk. There is more than 1Tb free space, i.e. all data will easily fit 2Tb part, but it is currently allocated on 1Tb disks.

In reality, these disks are hardware (PERC) RAID1 arrays over pair of 1Tb and pair of 2Tb resp.

I want to replace these 1Tb disks with 3Tb. The "one by one" replacement isn't really an option. In principle, this physical RAID can replace disks one by one, then grow the array to fill disks. However, I want to avoid this path, because it leaves some quite long time periods when disk redundancy is lost.

I want to literally move all data off from 1Tb, then remove it, and replace with 3Tb. All to be done on the fly, with running system, with zero downtime.

With LVM the operation has to be very straightforward and easy to understand:

1. pvmove all allocated data from 1Tb physical disk (VD in RAID terms)
2. vgreduce to remove that pv from vg and pvremove to remove pv metadata
3. remove a 1Tb array using megacli (PERC is rebranded LSI/Avago MegaRAID SAS)
4. physically replace disks
5. assemble another array again using megacli
6. make a new pv and add it into vg

This is the routine procedure I used to do. Each step is very well understood, on each step I have full control of what is going on, I always know how to proceed if something goes wrong and so on.

How to do the same procedure safely and knowingly with ZFS?

If that matters:

• the server is Dell PowerEdge R730
• the OS is Proxmox VE 6.0, which is based on Debian 10.1. It was installed from PVE ISO image, i.e. not converted from Debian installation.
• the system doesn't depend on this this pool, because it runs from set of SSDs assembled into another pool
• the pool hosts some VM virtual disks which don't require high performance. However, that data is valuable, I can't tolerate the if it's lost. Therefore the procedure should be clear and understandable
• system is constantly used by users, but they will tolerate the performance loss during data migration