Administrative risk, mostly. If you accidentally wipefs the wrong disk when moving it to the RAIDZ2 pool or offline a real disk instead of a tmp disk or make s

Administrative risk, mostly. If you accidentally wipefs the wrong disk when moving it to the RAIDZ2 pool or offline a real disk instead of a tmp disk or make some other simple mistake then a zpool might be unrecoverable. An alternative would have been to build a RAIDZ2 out of three new disks and two tmp files and then copy the data over and finally offline a RAIDZ1 disk and online it on the RAIDZ2 zpool. Two copies of the data in each pool would require an actual disk failure in both zpools to lose data during the resilvering (even though both were degraded), and when breaking the original zpool to add a replacement disk for the 5th device in the RAIDZ2 pool you'd have to lose two existing disks in that pool to lose data. No criticism; it's cool to be able to do moves with minimal resources and I've also thought about potential ways to upgrade zpools under weird constraints; especially no free SATA ports for example. I had thought about using the four SATA ports to copy data from half the source disks in a RAIDZ2 to half the destination disks of a new RAIDZ2 while the removed disks would still be a functional zpool on their own as a backup. But ultimately I found a cheap extra box and went for a complete upgrade to larger disks with the benefit of keeping the old box as a local mirror. My upgrade was from a single RAIDZ2 of 4x 4TB disks (8 usable) to a RAIDZ1 of 4x 14TB disks (42 usable) because once both pools existed I was comfortable running the old disks in a 12TB RAIDZ1 to receive snapshots from the primary zpool while I had <12TB used. Still requires 2 disks to fail to lose data, and now I do some offsite backups as well (rsync and s3backer) and have a test system to perform upgrades on before the main system.