Ah. I agree that your case is unusual and hints at mistaken impressions of zfs that you may come to regret. BUT if you’re trying to replace a single-drive pool in place with another single-drive pool of equal or greater size, then — if only to reduce downtime — you would indeed have had a remaining trick to play.
The idea would have been to join the second drive into the pool’s single mirror vdev, and wait for the pool to resilver and stabilize. Then remove the initial drive from the mirror. Then if necessary, tell the pool to expand to take up any additional space made available beyond the size of the former drive.
Replication or straight file copies can work too, and might fit better with your current understanding of zfs. Replication is preferred over a straight userland copy, due to the possibility of a flipped bit in transit which could evade detection.
A mirror rebuild and decoupling would have kept the pool's contents live and in service throughout the entire operation. But that's not a reason to start over if you've got a plan in motion that you trust.
