NAS Build Help for Home / Small Business


I am currently looking to build a dedicated NAS. I am thinking of going with either something like a 4 bay Synology. Or an HP Microserver (GEN10) with base specs and running something like FreeNAS.

This NAS would be used by at most 3 people at a time and would be used for storing files and managing backups.

I want 4 bays even though at the moment we will be only using 2 4tb drives. So, I want a nice way to upgrade in the future.

Is there a way to still stay protected by using something like or ZFS, and be able to add one drive at a time, do these drives still need to stay the same size?

Thanks in Advance!

You can’t add drives to ZFS VDEVs, you can add VDEVs (that consist of multiple drives if you want redundancy) to ZFS pools.

So if you have a pool that consists of one VDEV that consists of two drives, you have to add another VDEV aka two more drives to expand the pool. If you add a VDEV that consists of one drive, then if that drive fails you will lose data.

You can look into buying something like a Dell T110 II for FreeNAS. Very cheap used server, ECC RAM but no hot swapping of drives.

1 Like

Yeah thanks!

so if i set uo a VDEV with my 2 drives I have now, then add 2 more drives down the line I will be fine right?

Yes but be very cautious on the way you are going to set it up.

With two drives you basically have two options. “RAID0” (which in ZFS is called a stripe) and “RAID1” (which in ZFS is called a mirror). If you go RAID0 you get double the space (2x 4TB = 8TB) but if one drive fails, you lose all of your data. If you go RAID1 then you get the space of one drive (2x 4TB = 4TB) but basically you have two copies of everything. I strongly suggest going with a mirror setup, unless it contains data that you don’t care if you lose.

Later in the future you will have to make the same decision with your two new drives. If you configure both VDEVs as “RAID1s”, when you add the second VDEV to the pool, the pool effectively becomes a stripe of mirrors aka “RAID10”. This is ultimately what I would do. You can have one drive from each VDEV fail and still lose no data. You have the read speed of a four drive RAID0 and half the write speed of a four drive RAID0. You get the storage capacity of the sum of both VDEVs. For example, you can have a VDEV of 2x 4TB drives in a mirror configuration, which means 4TB of usable storage, and a second VDEV of 2x 8TB drives in a mirror and your total “RAID10” pool capacity would be 4TB + 8TB = 12 TB.

1 Like

Did I catch this right?

I have my 2 4tb drives now. do it as a mirror aka raid 1 (i have a missmatch of data) fine nice.

I can then make a VDEV later with 8tb drives, i.e. when they are much cheaper… and put them all in the pool ogether so I can have all the terabytes!



Your 2x 4TB mirror has 4TB of usable capacity.

You add 2x 8TB to the computer. You set those up as a mirror as well. That mirror has 8TB of usable capacity.

You add the second mirror to the first one as a stripe. You now have 4TB + 8TB = 12TB of usable capacity.

If you want to expand your capacity even more, you can fail one of the 4TB drives out of the pool and replace it with an 8TB drive. You wait for the resilvering to happen (copying all of the data from the other 4TB drive to the new 8TB drive), then fail the other 4TB drive out of the pool and replace that with an 8TB drive as well. After the second resilvering, you end up with a stripe of two mirrors, with each mirror consisting of 2x 8TB drives and with a total usable capacity of 8TB + 8TB = 16TB on the same pool. You can also add an unlimited amount of mirrors to the pool to expand its capacity later on.

Make sure you always have a backup, preferably on another server in another location. RAID and ZFS mirrors/raidz’s are meant to offer redundancy, aka no downtime in case of a failure, not to protect from data loss.

Nice so I can slowly upgrade and add more drives later. Then once my slots are full then swap one. Rebuild the vdev. And put a new drive In replacing the other 4tb.


Don’t worry. I have many backups of critical data… Would like to improve it though.

I understand you want to start off with only two drives and expand later down the line. But just be aware of this: If you get 4 drives from the beginning, instead of having two mirror vdevs you could have 1 raidz2 vdev. You would end up with the same usable storage capacity (half of your raw capacity), but in this configuration any two drives may fail without losing the pool. In the other configuration, when you lose two drives of the same mirror, you lose all your data since whenever one vdev fails, the whole pool is lost (because the data is striped across the vdevs).


I agree with Paolo - you might want to rethink how many drives you want to start with because you can’t add drives to a VDEV once its set up.

Read this:

I found it very helpful and has great examples.


Can I create a single vdev for each disk and then run mirror on the zpool or is this incorrect?

No, that’s not how it works. To answer your question directly, at the zpool level there is only striping. Mirroring or raid has to take place at the vdev level.

From the perspective of the zpool, a vedv is like a black box. The zpool doesn’t need to know how the vdev operates, it just relies on it to ensure data integrity. And because a zpool stripes data across all its vdevs, failure of one vdev will directly result in failure of the whole pool.

It’s the vdev’s responsibility, so to speak, to protect against data loss (i.e. drive failure) by means of mirroring or parity (raidz).

I don’t know if you’re familiar with the TCP/IP stack, but that might be another useful analogy. At the application layer (the zpool in zfs), the software is not concerned with how the data is transmitted, it relies on the transport layer for that. Here, TCP would be the equivalent of a vdev that implements redundancy because, abstractly speaking, if something “goes wrong” (packet loss for TCP, drive failure for a vdev), TCP can fix it. With UDP (representing a non-redundant vdev, i.e. striped vdev) however, lost packets will never be resent and will forever be lost.