NAS

Introduction

Everyone nowadays has a digital library that may include pictures, videos, and digital documents. Public cloud solutions are becoming increasingly popular and they do prove to be an accessible and flexible solution. But when you amass the type of digital library that I have, it gets egregiously expensive to host these files in Google Drive or iCloud. Clearly I needed a solution that was affordable and scalable in the long term, in addition to something I had more control over and could manipulate to fit my family's needs.

Failed attempts

Originally I had implemented a NAS solution on the Raspberry Pi featured in my VPN project. Unfortunately, it was far from elegant because I was utilizing multiple SATA docks via the USB 3 ports. The nail in the coffin was the fact that the Raspberry Pi struggled to handle the parity data required for the RAID setup and even the simple data streaming at 1Gbps was simply too much for the system.

My second attempt was to leverage the NAS as a virtual machine on my ESXi host. Unfortunately, the ESXi hypervisor likes to take control of SATA drives so it can create datastores, perform error correction, gracefully shut down VMs, and some other features that are generally helpful in a virtualization environment. But in a NAS, and particularly with ZFS, the operating system does not want an abstracted interpretation of the data drive. It wants direct access to the controller and to the disk so it can perform error correction, efficiently perform parity calculations, and protect data in the case of unexpected shutdowns. There is a way to pass drives through directly to virtual machine via PCIe, but that setup did not work with the hardware I had available. Although I did get it working in this manner, I knew that my data was prone to corruption and I did not have the proper precautions in the case of drive failure, so I had to abandon this method.

Settling on hardware and software configurations

Finally, I was left to choose between a commercial plug-and-play NAS solution or building my own NAS on bare metal in a system designed for it. the plug-and-play solutions were very appealing, but the cost meant that it made more sense to go with a public cloud solution. So I took the hard road and I built my own dedicated computer for this. I already had the 4x4TB HDDs as well as a few spare PC parts, so I just had to fill in the gaps and set everything up.

The 4 four Terabyte hard drives total up to 16TB but my configuration would result in 12TB effectively. RAID 5 seemed like a good balance of parity and data utilization. With this configuration I was able to have 3 drives worth of data, as well as 1 drive worth of parity. So I can utilize 75% of the data and still have one of the drives providing redundancy. I could recover from a single drive failure without any loss of data.

Aside from the drives used for the data pool, I also needed a drive to store the OS. Some people will use a cheap USB drive for this since the OS does not require too much space, but it is recommended to use a very reliable drive, such as an SSD.  

And for the OS itself, I chose TrueNAS core. I considered Open Media Vault, since it would make it very easy to host a media server. But after the mess that I got myself into with the virtual machines, I decided that I wanted to deploy a simple system whose only purpose was storage. No virtual machines, no containers, no nonsense. TrueNAS Core being an OS for data storage first and foremost, made it very compelling. Additionally, it is free and open source with heaps of community support, and it supports the ZFS file system that I wanted to use.

Configuration

After building the NAS and installing the OS on the SSD, I could finally make all the configurations. The most difficult part of this was user permission management. When you have multiple users, you want each user to be able to have separate folders for them to keep their files in. You'll also want communal folders for public files or files that need to be accessed by other services such as a media server. Although you want users to have a level of autonomy, you also need an admin or root account for making serious changes or for restoring access.

I also needed to configure routine checks to make sure the filesystem was healthy and make sure the drives themselves were healthy. After all, this system can only sustain a single drive failure. After which, the drive should be immediately replaced, otherwise you risk another drive failure making you lose all your data.

Testing and Monitoring

After the setup, we were ready to try it out. I started by backing up 50GB of pictures and videos and then accessed it from other devices. It worked great! The transfer speeds were a lot closer to what I expected, compared to the Raspberry Pi. I also simulated a drive failure by releasing the SATA connector. I received the alert as expected. The long, painful journey was over and I could finally rest easy knowing my data was backed up and I wasn't paying ridiculous subscriptions for the cloud storage.