tschlichter wrote:Actually its not a mirror its five 3tb disk, creating a pool w/o a spare. Thats why I would like to add a spare now, and replace the failing drive.
You have a pool with five top level vdevs; none of the vdevs has any redundancy; a failure of any of the vdevs faults the pool and also risks the pool becoming unimportable and its datable unretrievable in the future. Additionally, you are unlikely to realize any on-line repairing should there be a sudden error burst affecting one of the drives.
If you have to rely on the data in the pool you are already in deep trouble !
I hope you have backups. (1 April was international backup day).
You can add redundancy to each of the vdevs, and have a reasonably fault-tolerant pool by adding five more similar drives, each as a mirror of one of the five existing vdevs.
You would "zpool attach poolname GPTE_vdev1 /dev/newdrive1"
"zpool attach poolname GPTE_vdev2 /dev/newdrive2"
...
"zpool attach poolname GPTE_vdev5 /dev/newdrive5"
at which point no small set of disk errors will fault your pool (many errors will also be in-line repaired), and your data remains online and avaialable as long as one disk in each now-mirrored vdev is working.
If you really don't care about the data, then scsady's advice still applies: attach a drive to the single-drive vdev whose drive you want to replace, wait for the resilvering to happen, then detach the old drive.
Finally, if you can't add new disks for some reason and you want a reasonable pool, you should destroy the existing one and rebuild it with some redudancy. If your workload is anything other than dominated by enormous numbers of random write IOPS, then the five drives would make a fine raidz2.
(I would not make a raidz1 out of them; resilvering 3TB drives in raidzn takes a long long long time, and you will not like it if errors appear on any of the surviving drives during a raidz1 resilver. I would however make a two mirror vdev pool from four of them, and keep the fifth around as a spare.)