Wow, this beyond unacceptable and borderline illegal. Even tho I’m very happy owner of Synology, my next NAS won’t be it for sure. What are good alternatives for home usage? QNAP?
For the OS, I put openSUSE on it, set up a btrfs pool and configured SMB, NFS, FTP and SSH/SCP manually. It also functions as my HTPC, with Kodi as the frontend.
The Celeron J4105 is passively cooled and rarely sees 50C even under full load, plus it has hardware video decoding, so it can play back 4K video all day with no strain.
It's not a turnkey solution like a Synology or QNAP box, but it's a lot more flexible.
I think that if form factor is not an issue, one of the i3's that support ECC ram are low enough TDP to be cooled passively. Especially if it is not expected to run at full load for long periods. However I simply switched to using a big case with low RPM, good quality FDB fans. It hasn't been a problem since, and is much less cramped when I do want to tinker with it.
My goal was to build something not too much larger than a 4-6 disk NAS, that would also function as a HTPC, sitting under my TV. That meant small size and quiet operation were the main priorities. As none of the popular consumer NAS devices use ECC RAM, I reasoned that I would do without it in my build, too.
The fans are running on the lowest variable setting controlled by the BIOS, it's whisper-quiet even with your ear next to it, but I've got some even quieter fans from be quiet, that I'm planning to swap in. The PSU is also from be quiet!, and with the placement deep in the case, with the 120mm fan oriented downwards, it's completely inaudible.
Had I not been constrained by space and noise concerns in my small apartment, I would have build a larger, more powerful and ECC-equipped machine to be hidden away in an equipment rack in the basement.
That is not even the biggest advantage. The biggest advantage, in my opinion, is that you will always get updates and can run that for an unlimited time, without breaking your setup.
In the interest of full disclosure, I have had one issue with my build. The motherboard has four SATA connectors; Two from the Intel chipset, which work flawlessly, and two from an additional ASM1061 chipset, which don't. They seem to work initially, but when you start pushing larger amounts of data through them, errors start to pop up.
As far as I can tell, it's a either a driver issue or a BIOS issue, I can't remember whether I got those same errors on an ASM1061-based 2-port SATA PCIe expansion card or not. Either way, I replaced it with Marvell-based 4-port card instead, and just avoid using the ASM1061 ports for now.
Next time I add a disk to the system, I'll connect it to the potentially troublesome ports and run some tests, to see whether it was a driver issue that has been cleared up.
So yeah, not perfect, but good enough for me :-)
That seems like FUD to me. I am running Linux since over 20 years. A NAS's hardware interfaces are mostly HDD and network drivers, and I have not seen them breaking in many years.
And especially for PC-platform hardware, or ARM SoC in which Linux is the dominant OS. I could understand if NAS vendors would say that in their advertisement, but what is the substance of claims like this? Especially since these things runs Linux as well.
I've run a ThinkServe machine with CentOS and ZFS for several years. Kernel and ZFS updates would break it regularly, requiring tinkering to make it work again (my favorite: zfs#8885).
Nowadays I prefer when somebody else did the integration work.
However, ZEF is not part of the standard kernel, IIRC there are still license issues and it needs to be built separately, which is not necessary with any normal file system. I enjoy some amount of tinkering, too, but I believe it is expecting too much that everything works out of the box with non-standard kernel modules.
In the same vein, I also do not understand entirely why people want to have something still experimental like btrfs precisely on their NAS, and apparently use that without an extra load of backups. btrfs has many qualities, but it is still not considered as robust as ext4 (the current standard Linux file system), and for a long time it had practically no recovery option if file system data became corrupt. For me, it is very clearly not the first choice for a NAS or server which should run completely hassle-free. IMO, everything one needs for that is on Debian stable, so why not use that? And why in heaven should one make oneself dependent on what a specific hardware vendor does?
Another nice thing about CentOS is, that it was supported for 10 years. Debian is supported only for 3. It tkaes 5 years for Synology to get a new release done, so they also do have kinda-long term support.
Btrfs brings snapshots, rollback, deduplication, storage pools, checksumming, send/receive and a whole host of other features. It's a completely different type of filesystem to ext4.
Calling btrfs "experimental" at this point is like calling electric cars "experimental".
Or you could go for the DS1612+ to have room for 6 disks like in my build, which will set you back DKK 6,900 or $1,100. And that uses an AMD Ryzen CPU, not ARM. On the upside, it also has transcoding and media playback functionality like my build, and some features my build doesn't have, like an upgrade to 10gbit ethernet.
I'm not counting disks in these prices, since I used disks I already had, which I would also have done if I had bought a prebuilt NAS.
The TDP for the Celeron J4105 in my build is 10W, representing "the average power, in watts, the processor dissipates when operating at Base Frequency with all cores active under an Intel-defined, high-complexity workload". It very rarely runs at anything approaching a high-complexity load, even when transferring files over gigabit ethernet. It idles at around 30-35C passively cooled aside from the case fans, which run inaudibly at 500rpm.
Obviously the chipset and RAM also draw some power, as do the disks and fans and so on, but it compares very favorably to the quoted 51W under load/25W idle for the DS1612+. That is why I specifically chose a motherboard with that class of CPU.
Let's say the 51W figure is the same for my build and assume a worst-case load, running at full power 24/7. With the current electricity prices here, that's DKK 773 or $125/year.
Compare to the DS420j, which is quoted at 22W, DKK 335 or $54/year, for a device that is significantly less capable.
And my build is not just a NAS. It also serves as my HTPC and couch gaming machine for retro and emulated games, among other things. Plus it's 100% under my control, I get to decide what's installed and which features are enabled/disabled. For me, the choice is obvious.
Two lessons learned: 1) Don't use proprietary raid, 2) Don't ever use Synology devices.
QNAP has been great though, I've been very happy so far and zero issues.
Thinking back on this situation made me remember the terrible thermals in that old NAS. I had to replace the (fanless) PSU 2 times because it was always blowing up and creating sparks/smoke. Lol good times.
I never had any problem with thermals or psu, but I've heard other people had psu problems.
edit: my memory _is_ rusty; it was a QNAP box we had to do that with not Synology.
It can be cheaper than off the shelf NAS units too.
Same Mini-ITX form factor, 8 hot-swappable drives, pretty solid build qualtiy in my experience.
Their cloud sync and UPS functionality have been great (flaky power around here). Haven't dug into the TrueNAS' ZFS pool/snapshot management and jails management (FreeBSD's containers) functionality, but both are compelling once I get time and a good project for them. The NAS performing so well has me itching to upgrade to 10 gigabit ethernet around the house once prices come down a bit.
Also I ran the OS off mirrored thumb drives until recently. That was pretty nifty.
On page 5 they tally it up as a $400 difference vs building your own.
Also, for RAID1 you need an extra powered USB hub. The normal power supply of the Pi 400 is not sufficient for more than one disk.
Then just install a software RAID, NFS and possibly rsync and Samba. A simple NAS built in this way will come at about 240€, depending on disk size and will be mostly equivalent to a commercial one for twice the price. As an advantage, you can run well-known, standard software which is completely under your control. And since it is Debian-based Raspbian, it can be upgraded easily without breaking stuff.
The Pi400 is a brilliant machine, but this is not a way to make networked storage for data you want to keep.
if you want to use a raspberry pi for network storage, and you want to keep your data, make sure you have n+1 pi & disk machine.
Raid isn't going to help you here, you need redundant nodes. for the same €240 you could get two minimum spec pi4s PSU and usb HDDs
Why? The thing that could fail are the disks. So, one can use a RAID1 with two disks and this should, for normal applications be enough. I had a DNS-232 before as a NAS, it had 32 MB RAM, a tiny ARM CPU, and two large disks. It was working nicely over about ten years, and one could even run a web server plus a (slow) wiki on it (I had to replace the casing once, for a botched firmware update). The main problem I had with it that it was that it was impossible to update (I was running Alt-F firmware, which was developed by the community after the original firmware had constant problems with unneeded RAID synchronization, and the vendor had to release its code due to being bound to the GPL).
The Pi400 is wildly more powerful, has a much faster CPU which only draws a few Watt, and can easily be connected to several USB disks.
> Raid isn't going to help you here, you need redundant nodes.
Why exactly? My set-up is working well.... did I miss it needs to be somehow lighter than air (because heavier-than air flying machines are not possible, y'know)?
congratulations I am very happy for you!
The issue is not speed, its the USB disks. firstly you are reliant on the disks presenting themselves in the same order at the same time. (historically that was challenging) ZFS can cope with this quite well, MDADM, not so much.
You can use device IDs, which gives better results. Another issue I've bumped into is that mdadm has come up before the USB disk is initialised, causing all sorts of issues. in short raid over USB is just plain fragile.
> Raid isn't going to help you here, you need redundant nodes.
This setup will have four common failure modes:
o power issue leading to corrupt "/" or any other SD card failure
o usb disk breaking
o OS crash borking everything
o Accidental deletion
Raid might protect against a usbdisk breaking, assuming you spot it in time (most people don't have monitoring.) its not even going to give you a performance boost either, its USB3.
This is why n+1 is better. assuming you're not keeping each node next to each other then you are much less likely to experience a simultaneous outage.
In Linux, which is what Raspbian is, it is standard nowadays to use UUID disk labels.
> Another issue I've bumped into is that mdadm has come up before the USB disk is initialised, causing all sorts of issues. in short raid over USB is just plain fragile.
No issue with that. I guess systemd handles this. Only thing I found is that the hub needs to provide enough power on booting up.
> power issue leading to corrupt "/" or any other SD card failure
For that, I have a backup of the sd card. I am using an "industrial" SD card by the way which costs a few bucks more. Also, the card is running in read-only mode, using unionfs. Logs are written to a partition of the RAID disks.
> usb disk breaking
That's handled by RAID1 and backups.
> OS crash borking everything
I've never seen that on Linux, in 22 years using it. The closest I came to was botched EFI parameters from an Ubuntu install gone wrong, on a Desktop PC. Wait, I also had a problem in about 2003 with a broken ISA disk controller. Ah, and I am using EXT3 which is a journaling file system.
> Raid might protect against a usbdisk breaking
Yeah, that is what it is for. It is not a substitute for backups (but nobody said something like that, I think). In fact, it is easier to make backups from a Pi, using the standard Linux tools like tar, ssh and rsync.
> its not even going to give you a performance boost either, its USB3
For my purposes, it does not need to be faster (and it is much, much faster than the old DNS-232). The Pi 400 has Gigabit Ethernet and plenty of RAM. I am running a MoinMoin wiki instance on it, and it is more than fast enough for personal information management.
It can well be that a small thing like that is not fast enough for a medium-scale business with, say, a dozen clients. But this was not what my requirements were. I wanted to have a solution which is very low-power. And the Pi 400 is probably one or two Watt if idle, and the disks are spun down:
https://en.wikipedia.org/wiki/Raspberry_Pi#Specifications
https://www.raspberrypi-spy.co.uk/2018/11/raspberry-pi-power...
> This is why n+1 is better
So, what kind of set-up are you exactly talking about, a distributed system of some kind? A storage cluster? Ceph? DynamoDB?
As said, it is not a good idea to leave the root file system of the Raspberry, which is on an SD card, writable for heavy-duty, long-term tasks where reliability is important. It is not made for that. Among other things, this includes logging.
Instead, I am using this script:
https://github.com/fitu996/overlayRoot.sh
which mounts an overlay-filesystem with the bottom layer being the root-fs, the upper layer a new fs on writable media, which is a RAID partition in my case, and swaps the overlayfs with the root fs. That means that from then, the sd card of the Raspberry is not modified, and all changes go to the RAID disk. If you want to modify the system configuration, you need to re-boot with a different kernel parameter, which is detailed on the linked page.
> I've never seen that on Linux, in 22 years using it
Its surprisingly common, especially when a machine is underload and spending ages flushing to disk. A kernel oops happens and bam, broken partition.
> So, what kind of set-up are you exactly talking about, a distributed system of some kind? A storage cluster? Ceph? DynamoDB?
Noooooope!
just a second machine, with a copy of whatever you want to keep. when you are doing backups, have each one as a round robin target.
Ceph is not something you'd want to run for redundancy/reliability. I've spent many years supporting "HA" filesystems. The simpler the better (unless its GPFS, that's actually good.)
1. That is what journaling file systems like ext4 are for. These are exactly to prevent that unfinished writes of metadata corrupt the file system.
2. Of course, it is possible that the Linux kernel goes all bonkers, writing random stuff to you disk and firing up nuclear missiles. But I have never seen that. I also have never seen a kernel Oops on a NAS. Kernel crashes are usually caused by faulty device drivers.
3. Also, in this aspect, there is no technical difference at all to a commercial NAS since they use Linux as well. They also use ARM CPUs, like the Raspberry, since they save power and do not need a fan (which in turns makes them less prone to failures).
> just a second machine, with a copy of whatever you want to keep.
Keeping backups is something I would seriously recomment for any kind of NAS or server.
I do really not see how your argument applies in any way to a NAS based on a Raspberry Pi. The main difference I see is that it is substantially cheaper, and better suited to people who want to install extra software and occasionally like to tinker a bit. And I am obviously not recommending that the Central Bank of Canada or an institution like that uses it.
I have checked about that and mdadm uses uuids to identify partitions on USB disks:
https://serverfault.com/questions/739580/mdadm-can-i-reconne...
https://serverfault.com/questions/460138/mdadm-disk-configur...
https://www.linuxquestions.org/questions/linux-software-2/md...
Here is how it looks on my array:
root@arau:~# mdadm --detail /dev/md1
/dev/md1:
Version : 1.2
Creation Time : Thu Dec 10 08:56:22 2020
Raid Level : raid1
Array Size : 4821105600 (4597.76 GiB 4936.81 GB)
Used Dev Size : 4821105600 (4597.76 GiB 4936.81 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Thu Apr 15 11:18:54 2021
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : arau2:1
UUID : 7c1e57ea:1f7ebff2:415c1b0a:8f959031
Events : 21463
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 18 1 active sync /dev/sdb2
root@arau:~#
root@arau:~# mdadm --examine /dev/sda2
/dev/sda2:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x1
Array UUID : 7c1e57ea:1f7ebff2:415c1b0a:8f959031
Name : arau2:1
Creation Time : Thu Dec 10 08:56:22 2020
Raid Level : raid1
Raid Devices : 2
Avail Dev Size : 9642249512 (4597.78 GiB 4936.83 GB)
Array Size : 4821105600 (4597.76 GiB 4936.81 GB)
Used Dev Size : 9642211200 (4597.76 GiB 4936.81 GB)
Data Offset : 264192 sectors
Super Offset : 8 sectors
Unused Space : before=264112 sectors, after=38312 sectors
State : clean
Device UUID : 52594d2c:77f9c0cc:0b4243f6:6a8e6bcb
Internal Bitmap : 8 sectors from superblock
Update Time : Thu Apr 15 11:18:54 2021
Bad Block Log : 512 entries available at offset 32 sectors
Checksum : ca81c1ad - correct
Events : 21463
Device Role : Active device 0
Array State : AA ('A' == active, '.' == missing, 'R' == replacing)
root@arau:~#
And I looked into the madm changelog and git log and I did not find any reference to problems as you describe since 2014. I am a bit confused why you refer to hypothetical problems or ones which do not exist anymore for years?