Meaningful storage configuration for new NAS build

  • Hello,

    I'm planning on rebuilding my currently running NAS system, but struggle to decide which way to choose with storage and possibilities.


    My running NAS includes 2x 4 TB and 1x 6 TB harddrives independently to each other. For backups I use two external HDDs and rsync. The really important stuff (about 500 GB) is saved on another machine, too.


    For my new build I decided to get a useable capacity of about 20 TB.

    My first thought to achieve that was a 3x 12 TB combination running in an RAID 5 array. After some further thoughts on that I don't think that this config really would be reasonable, due to the large disk capacities and high stress a rebuild on RAID 5 would come with to the other drives... It seemed that RAID 6 or 10 could be an alternative, but require 4x 12 TB drives.


    Summarizing the pure disk prices and the fact that I would still need a backup (at least for the important data) I started to completely discard the thought of RAID usage.


    An alternative I see would be the use of 2x 20 TB HDDs, so that I could possibly use RAID 1 to create two redundant drives (as a kind of "first level backup"). Important files would be backed up to external HDDs stored offsite.


    My question here is, if this would be a meaningful config or if there is a better alternative. I was thinking of the possiblity to add disks in the future, so the RAID 1 would be bad for this use case. Could a MergerFS pool on a single drive, which is used in RAID 1, later be expanded with another single drive and its RAID 1 redundant copy?


    The only usage I had for RAID in the past was for small business operation, so I don't know, if I may be overthinking this whole topic for my home NAS... :saint:

    MergerFS and SnapRAID, that seem to be quite popular in combination, I did not use yet, so I cannot classify them fully.


    Thank you for your help!

  • crashtest

    Approved the thread.
  • There many forum threads on the subject of RAID that include discussions of whether to use it or not, which method to use to pool disk and their pros and cons, the benefits of modern copy-on-write filesystems like BTRFS, etc, etc.


    I'll summarise some major points.


    Reasons not to use RAID:


    1. System "down time" can be tolerated when disks fail. Reliable & frequent backups available for restore.

    2. 100% of storage available.

    3. Simple to use, maintain, and migrate disks for access on another system.


    Backups could exits on an external disk, another computer (co-located or remote), or on the cloud. With just two data disk you could make one a copy of the other by scheduling a regular rsync job from one to the other.


    Before considering RAID, never forget RAID in itself is not a substitute for a proper, and fully tested, backup and restore procedure.


    Reasons to use RAID:


    1. System "UP time". All data remains accessible in the case of one (or more) disk failures.

    2. Combinations of disks form a "pool" of available storage space.


    While "Up time" may be crucial for business, it can be viewed as inessential by home users who can tolerate the time taken to replace failed drives and restore data from backups.


    Combining disks to provide sufficient redundancy for disk failures implies some form of data duplication and so pool storage is less than sum of individual disk storage. The percentage storage "space efficiency" varies with RAID level, e.g 50% for RAID1, 66% or better for RAID5.


    Mergerfs is an alternative to traditional software raid which combines individual disk storage into a "pool". There is no redundancy unless combined with SnapRaid where at least one disk is dedicated to "parity data". It's not real-time RAID as the "parity data" is created on an ad-hoc or time scheduled basis. It's popular as it is well suited to unchanging and/or slowly changing data such as large media libraries.


    You cannot mix RAID and mergerfs. You could start with one data disk and one parity disk, but future expansion from more than one data disk needs to ensure the parity disk is always big enough. I recommend you read [a] & [b] whihc are still relevant fro OMV7 and look at various forum threads that point out some the cons of using mergerfs with or without SnapRaid.


    Another alternative is use BTRFS, a filesystem that may span one or more disks and provides raid-like behaviour. You can start with one disk, then add another and turn it into a two disk raid1 device and keep adding additional disk as needed. Disks do not have to be of the same size. But space efficiency remains at 50% and the actual avail space may be less. See for example: https://carfax.org.uk/btrfs-us…dg=1&d=6000&d=4000&d=4000



    a. https://wiki.omv-extras.org/do…mv6:omv6_plugins:mergerfs


    b. https://wiki.omv-extras.org/do…mv6:omv6_plugins:snapraid

  • Thank you very much for your detailed answer!

    For me I came to the point while comparing possible solutions, that a RAID for me is not as important as thought initially, but mirroring could be kind of early warning if something starts to go wrong with a drive in the array. So the availibility isn't the most important.


    The throwback of an RAID 1 array would come to sight if I might expand the NAS with further drives, so as you stated the ability to expand storage pool with more disks might be interessting in the future.


    BTRFS wasn't on my radar until now. It seemed to have become very well integrated into OMV lately with OMV7 and may be set up quite easy compared to other solutions.
    After reading some information about it for me it shows similarity to ZFS. Should I go with BTRFS for better integration or may the ZFS plugin be another possible solution to get an eye on?

  • BTRFS and ZFS are both copy-on-write filesystems whose feature sets are similar on paper. But the difference in design and implementation has major consequences in practice. I think of BRTFS as a filesystem first and a volume manager second, where as ZFS is a volume manager first and a filesystem second. With ZFS everything starts by creating a pool first.


    Certainly BTRFS is the easier to set up and use in OMV7, but there are quirks and gotchas to beware of when using BRTFS and it requires some maintenance. In the case of simple mirror, the failure of one disk can result in BTRFS RAID1 filesystem refusing to mount. Manual intervention is needed to mount the filesystem in degraded mode in order to make the replacement. By contrast, with a zfs pool consisting of a single mirror, the pool remains rw online in degraded mode on the loss of one disk until a replacement is made.

  • As I am planning to use the mirror on the data storage only (system disk will be M2 SSD) I think that should not be a problem.


    Comparing ZFS and BTRFS it seems that for smaller systems with few disks, BTRFS may be the proper way to go.


    I think I will give it a try! If I use two disks with same size , I should be able to just create a new filesystem choosing BTRFS, RAID 1 and both of the disks and thats it? Or is there any other need config to do?

  • I think I will give it a try! If I use two disks with same size , I should be able to just create a new filesystem choosing BTRFS, RAID 1 and both of the disks and thats it? Or is there any other need config to do?

    That's it. All shared folders will be created as BTRFS subvolumes which you can snapshot. It's worth tagging the file system as a reminder it has BRTFS RAID1 profile, e.g:



  • Perfect! Just for the sake of completeness, is ECC RAM a must have for the usage of file systems like BTRFS/ZFS, where bitrot detection through checksums is an important feature or is this "only" recommended?


    Currently I'm planning my build on an ITX board with no ECC support and there don't appear to be any boards available that even support ECC.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!