I don't understand. If the data exist at least at one place then you can (and should) backup it.
Oh definitely. The language I used is unclear. "The data can't be backed up" can mean the data itself can't be backed up or the data doesn't have the property of being backed up. I meant the latter, since the data doesn't exist on another drive (not redundant, ideally not in the same machine), it isn't backed up.
RAID not being a backup is always one of those things that makes me double take on some level though I know the reasons why. At surface level it makes sense to consider it a backup. Though really its only a way to minimize downtimes, not backup data.
It's a complex question. First the drives with the most TB/$ are the 4 TB ones so I'd chose those ones. Then it depends on your current needs and your future needs.
4TB drives are what I'm rocking, I made at least one good decision as far as my NAS goes. Question is quantity as expansion is frightfully costly to convert from 4TB to 5, 6 or 8. A new vdev will likely be the next course of action, though I'll have to wait on that front as it necessitates a new machine or at the very least a larger case. Future problems.
ZFS is a very complex file system. It's not impossible (everything is possible... well, more or less...) but it's probably very complex to implement this so the ZFS devs haven't implemented it because the complexity outweighs the utility.
Hmm...
Contraction would be incredibly difficult (it makes a number of assumptions) but I wonder about expansion. At a (very) high level it seems easily possible. But, like many things in computer science, that doesn't translate well to reality. I'd need a low level understanding of how ZFS operates including what is stored on each drive, how the drives are managed, and how differing drive counts affect RAIDZ# to even hazard a high level guess to how one would implement such a feature.
It would be a really interesting problem to try and tackle though I agree, it probably isn't an efficient problem to solve given the dev cost and added maintenance complexity along with it being a feature most (larger) companies wouldn't likely care for. Opportunity cost says doing what FreeNAS already does better and with less bugs is more important given what FreeNAS is for.
The current implementation of ZFS does not allow modification of any type of vdev other than a mirror. My comment about a 4-drive vdev being easy to upgrade was based on the idea that replacing 4 drives is easier and cheaper than replacing more than 4 drives.
Thank you for clarifying. I think even 4 drives is way too pricey to upgrade.
For a while there has been talk of the underlying ZFS implementation being enhanced to enable vdev modification, but you shouldn't plan your storage based on that expectation. If you want to be able to expand your storage ad-hoc, ZFS is not for you. The closest you can get with ZFS is to build your storage entirely with mirrors.
Mirrors was how I originally thought I would do things, but I think investing now into RAUDZ2 is a more efficient solution and can see why its preferred. It seems a direct upgrade from mirroring with one small cost.
I'm not going to bet on ZFS having such an enhancement, cool at is it would be. With not going ECC and taking the advice of the professionals (i'm not normally one for such arrogance) I have learned that ZFS and FreeNAS are what they are. Really effective storage and backup solutions albeit VERY much not for Joe Average. It's professional stuff for professional usage and I have to bend to it, not vice versa. Planning, learning, and a large learning curve are the price paid for what ZFS excels at.
At the very least, this gives me something to say I learned as an engineer by messing up. I'm just thankful it hasn't been an irrecoverable mess up costing me data and instead a financial one.