Guides

Build Your Own Budget NAS – a n00b’s Guide Pt 1

Firstly, a clarification. This is a guide written by a n00b, not a guide for n00bs. I am in no way an expert in networking, storage or servers.

[mks_separator style=”blank” height=”2″]

With Small Form Factor Network’s foray into video media (Namely YouTube) this year, I have realised the importance of having large amounts of storage. Until now, I have been living my (digital) life on a single 240GB OCZ Trion SSD, with backups made to SD media and flash drives… because? why not. Overall, this made for a very mediocre storage strategy, so even the most basic of external storage will be a marked improvement. As the amount of content I have saved locally increases with each article, I have decided to offload some of this data into a NAS, or Network Attached Storage machine. In this iteration, this will be a very rough and ready device, built with parts I have lying around. In the future, I will rebuild this with newer, more efficient (energy and space) parts.

As this is my first NAS build, there will be some trial and error involved, and some decisions may not be the best in the situation. If you have yet to build a NAS, or are still relatively new to the field, join me in my journey!

In Brief

In brief, a NAS is a network attached machine of which the primary usage is for storage of files. With a NAS, files can be accessed from any device (with the appropriate permissions) on the network, or beyond if desired. For most home users, a low powered device can be satisfactory, with many companies, even hard drive manufacturers, offering their own take on the devices. Synology, Thecus, Western Digital, the list goes on – whatever solution you desire is most likely out there for you to purchase… at a cost. The alternative is building your own. This is a quite valid option for those of us who can cope with the more technical aspects of home networking and system building.

A roll-your-own device can be as simple as a RaspberryPi with a USB hard drive attached, to a full, rackmounted, multi core behemoth. The only defining factor is your budget and desire for storage. I’ve attended a LAN party in the past where file sharing was accepted, and at least two users arrived with NAS builds comprising of over 20TB of storage, each. This was in the times where a 1.5TB drive was considered to be a huge, expensive drive!

[mks_separator style=”blank” height=”2″]

Planning

So, what did I need to take into account with this build? Well, as above, budget is a major constraint. My finances are limited, so the less spent on this project the better! For best results, this build will cost me next to nothing. Thankfully, being the SFF geek that I am, I do have some hardware going spare, so this shouldn’t be a difficult goal to achieve. However, later in this article you will see that this may change.

Also to take into consideration is the required storage space. With 1080p footage taking up about a gigabyte every 3 minutes of recording, it wouldn’t take long to fill up my current 240GB drive – ignoring OS and programmes, I’d only have space for 12 hours of footage! This is not to mention the many, many ~25MB RAW image photos taken for review and guide articles, as well as their smaller, edited, counterparts.

[mks_separator style=”blank” height=”2″]

My Use Case – A Summary

In short, my use case for this build is as follows;

  • Low power consumption and size (of course!)
  • Ability to store large quantities of data for long periods
  • Acceptable network speed
  • Works with my workflow
    • Storing unedited images and video as soon as they have been downloaded from the camera (in duplicate of my scratch disk)
    • Storing edited images and video after editing
    • Retrieval of old data for use in new projects, this includes b-roll footage files
    • Backups of configuration files for the podcast streaming for retrieval in the event of a workstation failure
  • Easy to configure – this is my first NAS build

[mks_separator style=”blank” height=”2″]

Operating System

To spec out the build’s hardware, I first needed to know what I was running on it. There are many options here for the device’s operating system, from costly to free, from simple to mind-blowingly complex.

Windows is the costliest option, but would be considered by most to be the easiest to configure. Basic sharing and permissions can be set from within a GUI, with even a moderately skilled Windows user feeling comfortable setting up the more complex options. This does come at a (literal) cost though, with a regular Windows 10 licence costing around US$119, and the server variants costing far more.

On the other end of the spectrum is building your own OS from a *nix core. While some of our community members may feel comfortable with this, it is beyond my skillset without hundreds of Google searches during the install process.

Somewhere in the middle lies solutions like FreeNAS, Amahi, NAS4Free, OpenMediaVault, etc. These options are designed for NAS devices, and include many admin tools, including webmin access.

From these options, I decided to sit in the middle. After perusing the comparison charts, noting features and missing functionality, I have decided to use NAS4Free. Now, this suits my use case scenario, but it may not suit yours. I am no server/NAS expert, so it would pay to spend some time checking out the available options to suit your use case scenario instead of blindly following this ‘guide’!

[mks_separator style=”blank” height=”2″]

NAS4Free

NAS4Free was formed after FreeNAS was bought by iXsystems Inc in 2011. The community around the original FreeNAS decided to continue on with a free, open source, NAS OS and from this, NAS4Free was born. There is a disagreement as to whether or not NAS4Free is a FreeNAS fork, but that’s mostly a moot point here.

NAS4Free is a WebGUI orientated OS, with all config done via the browser. You do not need a screen connected to the system after the initial installation, reducing clutter. The operating system supports file sharing with most platforms, including UNIX-like systems, Apple systems, and Windows systems, and others that use compatible network protocols. The aforementioned protocols are numerous, ensuring support for pretty much any system connected to your network. CIFS/SMB (Samba), Active Directory Domain Controller (Samba), FTP, NFS v4, TFTP, AFP, RSYNC, Unison, iSCSI (initiator and target), UPnP, Bittorent and Bridge, CARP and HAST protocols make the list of these protocols.

On the file system side, NAS4Free supports ZFS, Software RAID (0,1,5), JBOD, UFS, Disk Encryption, and S.M.A.R.T with notifications. For my build, I will be using SoftRAID. I chose this over ZFS due to hardware limitations, however, ZFS is a valid option for those who have more RAM!

From the NAS4Free wiki:

“ZFS is a fundamentally different file system because it is more than just a file system. ZFS combines the roles of file system and volume manager, enabling additional storage devices to be added to a live system and having the new space available on all of the existing file systems in that pool immediately. By combining the traditionally separate roles, ZFS is able to overcome previous limitations that prevented RAID groups being able to grow. Each top level device in a zpool is called a vdev, which can be a simple disk or a RAID transformation such as a mirror or RAID-Z array. ZFS file systems (called datasets) each have access to the combined free space of the entire pool. As blocks are allocated from the pool, the space available to each file system decreases. This approach avoids the common pitfall with extensive partitioning where free space becomes fragmented across the partitions.”

Using ZFS enables one to configure a RAID of sorts on hardware that doesn’t support disk mirroring or striping. Data redundancy is critical for me, especially with video recordings that could be corrupted with a single flipped bit! Not ideal when I need that perfect b-roll or snippet of video to emphasise a point on a new video. The main pitfall of ZFS is it’s thirst, and I do mean thirst, for RAM. NAS4Free recommends a minimum of 4Gb of RAM, with 8 or above being ideal. General consensus on the web is that you need 1GB of RAM per TB of storage. While this is a guideline, there is usually some truth behind such suggestions. It’s a shame the hardware I have won’t allow me to use such dark magic!

Installation of NAS4Free takes place from one USB drive to another in normal setups. Thus, the OS drive will be a USB drive left in the system – so I will have to budget a second USB stick in my build!

[mks_separator style=”blank” height=”2″]

Hardware

Motherboard

Model Name Intel DQ45EK
CPU Core2Duo E8400 3.0GHz Dual Core
Chipset Q45
Form Factor M-ITX
Expansion Slots 1x PCIe x1
RAM Slots 2
Storage 4x SATA 2.0 connectors
Network Intel 10/100/1000 Mb/s
Other E-SATA
Useful Ports 6x USB2.0 ports on back panel, 4 internal USB2.0 ports on headers

[mks_separator style=”blank” height=”2″]

Memory

4GB DDR2. Unfortunately, thanks to a quirk of the platform, this is the maximum this board supports.

[mks_separator style=”blank” height=”2″]

Storage

4x 500GB 3.5″ Seagate HDDs. These have been pulled from an existing 1U server I picked up for $10!

[mks_separator style=”blank” height=”2″]

Case

Jonsbo C2S.. Again..

[mks_separator style=”blank” height=”2″]

The above hardware was selected because I had it all on hand, thus costing me nothing!

Unfortunately this is where it all went wrong. The motherboard’s SATA controller is bad under sustained writes or reads. The board only has a PCIe x1 slot, which is closed ended, so my x4 RAID card won’t fit either. Another flaw is that the board refuses to boot from USB without user interaction, so in the case of a power outage, bringing the system back up is a hands on job. So what do? Time for a rethink. And a second article in the series.

[mks_separator style=”blank” height=”2″]

Conclusion

So far I have learnt that testing hardware before building it into a confined case that wasn’t designed for such a use is a great idea. After further testing of the system, I have determined that the failure is indeed chipset, rather than heat related. So, this is where I leave it to our readers – what motherboards have you had luck with when building a DIY NAS? Let me know in the forum.