> it's ZFS backed, screwing up the RAID is going to be pretty close to impossible
Even if it's ZFS it can get quite messed up if you set it up based on sda, sdb, etc like naming conventions. In that case entire zpools can fail to import in case of failure.
Therefore the best practice is to use device-by-id, so that if a device like sda falls out, the rest of your array should still resolve correctly.
And how the array is created is entirely a FreeNAS thing. Hopefully one which have, like OP says, improved.
As soon as I get home, I'm going to swap some of my HDD cables and see what happens... I've basically been assuming that NAS4Free uses device-by-id like any sane OS should.
NAS4Free and FreeNAS are just relabeled FreeBSD with GUI stuff pasted on. FreeBSD doesn't have /dev/disk/by_{id,label,partuuid,path,uuid}. It's its biggest failing IMO. Their /dev/diskid is NOT what it sounds like.
That said, ZFS pools under FreeBSD and derivatives, just as under linux, are imported from info stored on the drives themselves. They should be able to reboot after scrambling the cables. It would take more nerve, or craziness, than I've got to PROVE that using any pools I care about.
However, I have completely screwed a ZFS replace command in FreeBSD following a bad drive in a RAID-Z3 pool. It dutifully replaced a perfectly good drive with my new drive. But no harm was done to the pool. After it finished, I ran another zfs replace, replacing the bad drive with the "mistake" old drive. It all worked!
ZFS is so brilliant, be careful or it will put your eyes out :-)
Even if it's ZFS it can get quite messed up if you set it up based on sda, sdb, etc like naming conventions. In that case entire zpools can fail to import in case of failure.
Therefore the best practice is to use device-by-id, so that if a device like sda falls out, the rest of your array should still resolve correctly.
And how the array is created is entirely a FreeNAS thing. Hopefully one which have, like OP says, improved.