It should work, but be careful. The idea is you create the target file first on the USB backup drive; it needs to be the right size. Then you convert the ZFS instance into it using salvage etc. I highly recommend reading about those commands so you understand them a bit more.
Better would be to use mirrors. Then you don't need to recover in the first place when a disk fails and you get bit rot protection.
Because those virtual disks are zvols, so block devcies, and not files. there is no file to copy. You will have to read those zvols on block level and write that to a image file like a qcow2 or pipe the output of "zfs send" to a file. but with the latter one you can only restore that virtual disk to another ZFS pool.
The only way would be to ensure the VMs are stored on an entirely separate array, and that you can restore a backup of the settings to a new PVE install. My general method at the moment is to add a disk with a new installation, restore the configuration backups, and then proceed to work on the original arrays to get extra backups as needed. The ZFS arrays are the backups for the VMs, so if I have to nuke the original array, then I can restore the configuration backups, followed by restoring the VM backups from ZFS.
Basically everything with a power-loss protection should give you way higher fsync performance. But those are all U.2 or M.2 NVMe but 22110 in length. Have a look at the Samsung PM983/PM9A3 1.92TB or Micron 7300/7400/7450 PRO 1.92TB. But keep in mind that with a mirror your write performance will be defined by the slowest disk of that mirror, so your 970 EVO. And to mirror it, you need the exactly same or bigger size.
