Building a home server turned out to be not so straightforward; here are my experiences, problems and solutions:
Central storage for my data with access from all devices.
Always available, without having to switch on a big computer or letting it run continuously.
One single backup, instead of having to care for each machine individually.
Wifi access point.
Other useful services, like music player for the music collection.
Quiet: A server in the living area should be completely quiet; not a 19" machine with fans like jet engines.
Energy efficient: A server that runs 24/7 must be very energy efficient, in order to keep the electricity bill low.
Large: several terabytes of storage, and can easily be extended
Failure proof: duplication (RAID 1)
exchangeable volumes
I don’t need much computing power, so even the smallest machine should be sufficient – like e.g. a Raspberry Pi (and that’s what I used in the beginning). However, the I/O turned out to be a bottleneck, because the Raspberry Pi 1 had only USB 2.0 interfaces, which are way too slow for serious disk I/O. I needed SATA, which was not available in devices like the Raspberry Pi.
So I finally found the UP Squared which seemed to fit my needs best. I chose the slowest version with Celeron N3350 processor (since it is more than sufficient) and 4 GB RAM. The eMMC has 32 GB; this is sufficient for the OS, and all data is stored on external hard disks.
SSDs may be convenient, but they are much more expensive than conventional hard disks. And their low latency is not really needed for a fileserver or backup medium.
2.5" HDDs consume less energy and are quieter than 3.5" HDDs, but also more expensive and not available in high capacities.
3.5" HDDs are the cheapest option; and their higher energy consumption is negligible, since the disks are not running permanently, but are only spun up when accessed. And slow models (5400 rpm) have both a low energy consumption and are quiet.
Thus I decided to use 3.5" HDD drives; the WD Red series seemed to be a good candidate, being quiet and having a low power consumption. They do use SMR recording – which is not a problem, since writing large batches of data is an exception and the network is usually the bottleneck. However, it seems necessary to increase the timeouts in /sys/block/sd*/device/ to prevent device resets (i.e. the disk is not frozen, just sometimes very slow).
A RAID should simply work; so the underlying technology should not matter. However, at first I had a simple USB RAID enclosure with two 2.5" HDDs; this had a few drawbacks: First, it was not possible to spin down the disks via software (as opposed to other USB disks), so they were running continuously; unsurprisingly, one of the disks failed after a few months. And second, rebuilding the RAID after replacing a disk seemed not to work, at least according to the blinking status LEDs. This was a big disappointment.
So I decided to use a software RAID; there, I have full control over the RAID and can also get S.M.A.R.T. information about the individual disks, and spin them down via hdparm. Thus, I needed a computer with multiple SATA ports.
Because none of the small and energy efficient mainboards have multiple SATA ports, I needed an additional SATA controller. I decided to use a two-port SATA III Mini PCIe controller with ASMedia chipset, which is supported by Linux.
Since a small computer does not have any hard disk bays, I needed an external enclosure with removable trays. However, only those for 2.5" disks have passive cooling; all enclosures for 3.5" disks have a noisy fan which is always running, even if the disks are spun down. But I found a disk rack from Thermaltek where the fan can be unplugged and the corresponding alarm be disabled. Since I am using only low power HDDs and since they are not running continuously, active cooling is not necessary.
Whereas highly integrated mainboards together with modern power management are very energy efficient, this is often not the case for power supply. Companies often sell high quality hardware together with cheap and inefficient mains adaptors; better quality exists mostly for powerful and thus expensive PCs, but not for embedded systems. But in order to keep the total power consumption low, an efficient mains adapter must be used.
Voltage: Up Squared needs 5 V, 3.5" HDDs need 12 V
Power: Up Squared needs up to 20 W, one HDD needs up to 5 W when running and up to 22 W when starting; i.e. with HDDs running around 30 W.
There are only few small power supplies that offer both 5 V and 12 V in this power range. Since the efficiency decreases with partial load, the maximum power should not be too high.
First attempt: Phobya 70 W power supply; but it turned out to be too weak with 5 V, the UP Squared didn’t boot.
After adding a 12 V to 5 V converter, everything worked; so only the 12 V output of the Phobya power adapter is used.
The most efficient power supplies seem to exist for LED systems; thus I bought the Meanwell NPF-40-12 power supply for 12 V, and kept the voltage converter to 5 V.
Additionally, I connected everything to a small UPS (Eaton 3S); although power outages are not that frequent and usually very short, I want to protect my equipment from sudden power loss or voltage surges. (Actually, I could have chosen a power supply with integrated battery, like the Meanwell SCP-35-12.)
This turned out to be a major headache. There is a daemon, hostapd, which can turn many USB adaptors into access points. However, stability and software support were often a problem:
Edimax EW-7811Un: At first, it worked only with a patched version of hostapd with driver rtl871x; later, also the built-in driver nl80211 worked. However, it did not work reliably; I assume a temperature problem.
TP-Link TL-WN321G: Like the Edimax stick, but worked more reliably (no temperature problem).
Gigablue USB WiFi 300 MBit/s: Since the Wifi signal was quite weak with the previous sticks, I bought one with an external antenna with 5 db gain. Much better! However, after an upgrade to Ubuntu 18.04 it stopped working with the new hostapd version.
Anadol Gold Line AWL150: All previous Wifi sticks hat Realtek chipsets, which are very popular, but not well supported by Linux. So I looked for a USB Wifi stick with Atheros chipset and external antenna, and found this one which has a Ralink RT5370 chipset. It works flawlessly.
Since the UP Squared does not have an integrated sound device, I bought a simple USB sound card, Kotion S1 Pro.
I use FLIRC, a USB IR receiver which acts as a HID device. It can be used together with the hotkey daemon triggerhappy. I use it mainly for controlling MPD, i.e. setting the music volume, start/stop playing and skip to the previous/next song.
I decided to use Linux, since it is my preferred operating system, is well suited for servers, and has good hardware support.
I wanted to have a copy-on-write file system:
Checksums: Although bit rot is not common, it does happen; and I want to be able to detect it.
Snapshots: I wanted the ability to keep older versions of files.
Backup via snapshot: Backup via rsync is very slow; it is much more convenient to create a snapshot and transfer only the difference to the common parent snapshot.
I decided to use Btrfs, since it is included in the Linux kernel and offers all these features. Some people claim that it is not stable; I didn’t experience any issues, it turned out to be very reliable, but the documentation and maintenance tools need a lot of improvement. It does work well – but finding out what’s going on and what to do in case of problems takes a lot of time. And in case there is a filesystem error, data corruption seems to be very rare; but without an intact copy, the filesystem cannot correct many errors (like checksum errors or journal errors) by itself, and fixing them by hand seems quite hard. Thus, always have multiple copies (raid1 or at least dup), and create a new filesystem instead of trying to fix a broken one.
At the beginning, I used mdadm as software RAID, since it works well and reliably. But because it operates on cluster instead of filesystem level, rebuilding the RAID is very slow, and damaged files cannot be corrected since the filesystem checksum operate on the whole RAID.
So I switched later to Btrfs RAID, where checksum errors can be corrected with the second copy, and where only clusters that are actually used are duplicated to the second medium. Furthermore, disks do not need to have the same capacity, so one can switch to larger disks without leaving the additional part empty, and since Linux 5.5 also three or four copies are possible instead of just two. (But using btrfs replace one could already before exchange one of the disks without having only one data copy during the replacement.)
OpenSSH
Samba: for using it as a Windows network drive
MPD: the music player daemon
Triggerhappy (together with FLIRC): execute commandy by IR remote control
hostapd: Wifi access point