The latest DSM update makes btrfs drives unavailable on budget Synology models
community.synology.com
community.synology.com
Issue closed: intended behaviour, won't fix.
I can't think of a worst act by a company that makes data storage devices than to intentionally and deliberately break data stored by their customers.
What a stupid and nasty action by a terrible company. They deserve to be sued into oblivion
I use a DS918+ at home which I got after having deployed Clustered RS units for VM storage in a previous role. The recent moves from the company (not certifying their devices with non first party hard disks, pushing more user licensed features (VPN/Email)) and a feeling that software quality is in decline (acknowledged bug in Apple TV app hasn't been fixed in at least 8 months).
It a real shame that both Synology seems to be following the ubiquiti route to smash their reputation to increase revenue.
This is an example of a stupid error that I can’t turn off.
They’re starting to assume that all devices are internet connectable and subject to brute force. That seems insane to me and my synology is on a private network with no inbound connectivity. I don’t want to change from admin.
Actual IT security is in depth, and the simple task of having an admin account that is not the default user ID makes sense to me.
What zero days are out there that rely on a known user ID, and a known process ID for that user’s first process? You could defeat that by just following the advice from people that know better.
If there’s a zero day ravaging my kids iPad then that’s the risk I take. And it’s acceptable given my situation.
“People that know better” for my situation seems pretty hard to qualify. I’m glad it makes sense to you, but since you have zero insight to my config and the changes required to implement I think it says more about the quality of your recommendations that you can give a recommendation without understanding the usability trade offs.
Maginot lines suck for protecting countries, but simple, clear defenses are pretty darn handy for protecting home networks. I’ll take a disconnected NAS over a wonderfully synced, fully compliant NAS following every recommendation (that also includes making it network accessible).
They refused to even look at the logs if I wasn't willing to give them root access to the primary system. I told them that wasn't an option but I was happy to provide any log they wanted and they just never responded to the case again.
Not sure if Synology has their ass covered via terms of service. Even if they did, it’s their fault people lost access to their data.
Interesting to see how this unfolds.
To get btrfs, you had to use another btrfs capable NAS and then move the drives over to use that unsupported functionality (which was, again not documented and clearly marked as unsupported) and this patch has now removed a module that allowed for accidental use of that unsupported functionality.
What legal grounds do you have here?
As a customer in Germany I sure hope the consumer protection agency (Verbraucherzentrale) could make them sing.
Synology provides no recourse, effectively bricking the device you own. See how Consumer protection agency likes that.
You being unable to access files miss out on some important work, or deadline. See how courts like that if you decide to bring a civil suit against Synology.
The problem here is that they actually did allow it, and did expose those settings.
Seeing that the GUI allows BTRFS, even if it was supposedly sold without support for it, might lead people to believe that the specs or documentation were outdated especially since the current documentation is actually outdated on many other matters and cannot be relied to 100% accurately reflect the current usage of the product.
Yeah, assume documentation is outdated. That makes sense.
Features change in software all the time.
What's so outlandish about someone getting a new unit, it upgrades the software automatically on first run, and then the BTFRS filesystem is available to them use for the array.
You'd either not think twice about it or thank Synology for opening up the new feature for these lower end units.
Taking the feature away like this is the absolute trashiest behaviour.
So your analogy should be "Car commercial showed a slow but practical car, you buy the car and it turns out to have high performance and can zoom around corners, then a year later a software update forbids you from driving on the road to your house that has a high speed limit so now you can't get home"
(I know btrfs on ARM wasn't really all that great at times.)
There is no "downgrade" path from btrfs to ext4. Users have to move all their data off the NAS to some other storage, delete the btrfs volume, create a new ext4 volume and then copy the data back on.
These alleged damages are measurable in both time and the cost of storage rental.
Even worse, if you apply this upgrade without knowing that you need to do this procedure, your data is inaccessible until you contact customer support.
Then six months later Tesla pushes out a software update overnight that removes that view and offers no way to restore the old one, or start your car, or unlock it.
I don‘t want to be on any side. But is it wrong to fix a bug?
Also, just for curiosity, and without condoning what the company is doing, is there a good reason to use btrfs for a device like that? I was thinking that good filesystem repair facilities are important once you store a lot of data, and btrfs is inferior to ext4 on this? I find btrfs is fantastic if you have, say, a bunch of Yocto images, or a large video you are working on, and you want to quickly create and erase snapshots of many gigabytes of data, but what is the advantage here?
No familiarity with these devices, but there is at least a slim chance if it was an embedded device, they needed the flash or RAM for something else. Seen this happen elsewhere before
Synology can easily allow access to the volume. I would think the smartest decision when removing a feature (even a feature that was never intended to exist) to instead make the unit at least mount the volumes as read-only and allow the data to be exported to the network / cloud / USB drive.
This of course assumes that Synology doesn't remove this option before DSM 7 is released.
The "this is for security reasons" is just silly, none of the exploits they've been hit by to date that I'm aware of utilize or require inserting a kernel module into the system. And if they have the infrastructure to sign modules to allow insertion, they could extend you whatever signing they utilize.
It's not like a nation state actor couldn't hack Syno corporate and get access to signing keys if they were after a targeted attack...
Another negative to add to the list. For me Synology has mostly been a disappointment, I'm sorry to say. Seems their software has been generally in decline for a while. DSMv7 was delayed over a year ago [1], and now they don't expect to ship until summer 2021. v7 doesn't seem to bring anything interesting to the table IMO, and now they want to take away root? Meanwhile the only thing I saw from v6 updates was a request for spying/telemetry [2]. Wanted to like Syno but it's too locked down, too expensive, too annoying.
My position [3] hasn't changed from last year - I don't see myself buying a Syno product again, nor recommending them to most of my technical friends.
[1] https://www.snbforums.com/threads/dsm-7-preview-delayed-unti...
The RAID array had to be moved from another device to work. Running your RAID array on a device that explicitly doesn't support it feels like a really risky behaviour.
Synology made a mistake which they admit:
> DSM incorrectly allowed administrators to migrate from a BTRFS-capable device and utilize previously created BTRFS volumes on the affected devices
And they're punishing users for it
Specific features like RAID and deduplication are known to add to RAM and CPU requirements. Synology uses BTRFS for neither, so any performance differences are almost certainly not due to the specific fs.
I also have not seen any evidence of perf diffs.
The problem was that the GUI didn't reflect that, which was the bug. And then they "fixed the bug" the same way that they "fixed the glitch" with Milton in Office Space
Let's assume for a moment they want to go ahead and disable this accidentally enabled feature, OK, but they should have changed it such that - On existing installs: You could mount existing volumes, but not create new ones - Start showing a warning to users asking them to migrate - If they are desperate, on new installs, you could potentially disable mounting existing volumes or at least and a stern warning. (The downside is for example, if your NAS died, you got a new one, migrated the drives, you can't access them again. So this is a hit and miss idea, depending on how keen they are to push disabling the feature)
The good and bad news is that in all liklihood they didn't intentionally brick existing users but instead some braindead engineer went "oh that's not supposed to be enabled it, let's disable it" and didn't think about or realise how it would affect existing users until it was rolled out. Good because less malice, bad because they should ideally have smarter engineers reviewing such things.
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.
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.
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.
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?
Same Mini-ITX form factor, 8 hot-swappable drives, pretty solid build qualtiy in my experience.
It can be cheaper than off the shelf NAS units too.
https://www.synology.com/en-us/products/compare/DS220+/DS220...
I guess at some point they forgot to turn the feature flag for btrfs off on "j" models and now they are "fixing" that?
Seems doable but with a lot of communication & control for customers and at a very minimum it should go read-only. Super bad for their brand and their customers.
Synology users, consider disabling automatic DSM updates. I have mine set to email me when there's a new version. Works fine.
What was possible, was to put the drives into plus model, create the volume, and migrate the drives into j model. Even migrations that are not supported are pretty much possible. Or were, with the uodate not anymore.
I've seen the proof on twitter and elsewhere it was 100% an option in the GUI. Enough of your gaslighting, Synology.
I can show you similar screenshot. Does not make it genuine. I used to own a value series Synology NAS, and it was not possible to create btrfs volume. For extra fun, it was also possible to create only 32-bit ext volume (i.e. limited to 16TB; if your pool had more, you had to create separate volumes) and it didn't support some ext4 features, so you had to be very careful when creating volume on external device.
So what's a good alternative, preferably with ZFS support.
It's BSD license, and iXsystems is the primary developer behind it. They do offer some of their own hardware, so you can get a similar "commercially supported buy and turn on" experience to Synology if you'd like, though I don't think the value proposition from them right now is the best for home users or certain SMB. But it's there. And unlike DSM there's no workarounds needed to run it wherever which is another huge tick in its favor IMO. With something as critical as a NAS I don't mind paying a company for support or hardware, but lack of official easy exit options makes me nervous. For reasons like, well, this?
Does dedicated NAS have any advantages for power user? Buy some cheap Ryzen box, stuff it with harddrives, install Centos and forget about it....
For everyone else, they do have advantage, most thing you wanted is 1 click away, including something tedious for average "power users", like "using btrfs safely with RAID-5-like disk array" (so that you can take a snapshot of your drive) mentioned here.
Do you have a link to a licence sales page?
https://www.synology.com/en-global/products/VDSM_License_Pac...
I know xpenology uses the official software, but I'm not sure if that is legal.
The slots are pretty stiff so you don't massively need the screws - I didn't put them in until I was sure everything was assembled and working correctly.
A custom-built mini-ITX machine or a Proliant Microserver would be my next recommendations. But they're not nearly as energy efficient as a consumer-grade NAS.
I agree that over multiple years, electrical power becomes a substantial part of the cost (and also the environmental footprint).
Small ARM systems with sufficient memory and fast interfaces are perfect for that.
I got a NAS but found it easier to simply mount the remote system via a Samba share or SSH and process data on local machine. For RAID, I use a HDD backup. For snapshots, back up software already have snapshot feature (eg, Borg).
With this use case, any thin client works.
Who said anything about Web GUIs? I can't make sense of the rest of your comment. What does that have to do with my original question?
(NAS could be DIY or a prepared solution. I assumed the latter, one selling point of which is pretty GUI).
A reliable backup is way more important than RAID. Unless you run some kind of emergency service.
https://news.ycombinator.com/item?id=26804794
So, some NAS vendors seem to spread a bit of FUD that their hardware is purportedly better or more robust than a self-built Linux system. It isn't - they are very likely using exactly the same chips as you. What you get when you buy a ready-made NAS is that it is quicker to initially set up and less work to configure, that is what you pay a good chunk of money for. On the other hand, you are not unlikely to later end up with a system without security fixes or upgrades, or which can't be moved to newer hardware, as was my experience. Also, the easy initial configuration is nice, but it won't help that much if you need troubleshooting or a more tailored set-up.
I had similar requirements as you, specifically:
- not too expensive
- plenty of space
- very energy-efficient, so I needed an ARM CPU
- fast Gigabit Ethernet
- needs Windows file sharing for my partners' Mac
- flexible enough to set up some home services
- needs to have updates and standard Linux software support in the long run.
- easy to back up
- some protection against sudden disk failure, using a RAID
Here is my solution:
- a Raspberry Pi 400 with keyboard: https://www.raspberrypi.org/products/raspberry-pi-400/ . It has a quad-core Cortex-A72 and four GB of RAM - it is likely much better than a low-cost NAS. Also, it runs from an SD card, which makes it much easier to install, update, or revert the system, you do not need to be afraid of bricking your device because that can't happen. It also comes with a nice and comprehensive printed manual if you buy the kit.
- Two external 2.5´´ HDD drives, 5 TB each, with USB3 interface (I took a Western Digital one and an Intenso one, as it is tradition to use different makes in a RAID, in order to avoid correlated failures)
- One powered USB 3 Hub with sufficient power for all of them. These can be relatively expensive, so leave room for it on your budget, you need it.
- an industrial-grade SD card for the Raspberry's system
- you also might want some kind of organizer to keep the devices together while providing for good passive cooling, like that: https://www.amazon.com/DecoBros-Cabinet-Basket-Organizer-Sil...
That might sum up to 250 - 300 €. If you want it cheaper, you could skip the RAID, allowing to omit the second HDD and the USB hub.
My set-up includes:
- standard Raspbian for the software
- I use the root-fs overlay provided here https://github.com/fitu996/overlayRoot.sh , in order to protect the SD card from constant writing
- /var (and with it the system logs) go to a different partition of the RAID
- RAID is set up with mdadm . There are good instructions on the web.
- I use ext3 or ext4 file systems for data. btrfs is in theory easier to extend but it has worse robustness characteristics than Ext4, and for a long time had no well-working filesystem repair tool if metadata gets corrupted. Some people might use ZFS but I think it is overkill and over-complicated for this case, it is not part of the standard kernel, and it might make kernel updates more difficult or impossible.
- also I set up openssh-server, Samba, Linux NFS server, a MoinMoin Wiki, rsync.
- I configured systemd so that Ctrl-Alt-Del on the keyboard will shut down the system, even if it is disconnected.
- I configured the disks to shut down when unused for some hours, using hdparm - that saves power, too.
The overlayfs needs to be activated when everything is finished. It has the effect that changes and logs are stored on the RAID. If you update the system, it needs to be deactivated.
Of course, back-up your SD card.
Also, please always back up your data - RAID is never a substitute for backups. What RAID is good for is that it increases availability of your device in case one of your disks fails. But there are many errors which it cannot help against, so you need regular full backups (like you need for any Synology or whatever NAS as well!!).
Btrfs was never supported nor advertised to be supported on these lower end devices. But, it seems like if you created the btrfs drives on another device that did officially support them, you could then import them onto the unsupported hardware platform.
Still, its a bad look for Synology. Seems like the lack of btrfs on the lower end devices was merely artificial product segmentation, not an actual hardware limitation.
> I set up a new device and the DSM software itself gave me the possibility to create a BTRFS volume from scratch.
> (...)
> It was there, for over a year, and now my data is kept ransom by Synology because they decided I need to buy an upgraded model.
I would have way more outages, breakage, and features gone missing due to updates than missing out on “security patches” and getting targeted by hackers
These actions were always unsupported. It's like complaining using unpublished APIs does not work in future versions.
It's also surprising how many people, likely not even Synology NAS users, misread the article, and jump into full outrage mode.
That's not true. At one time, their DSM gave you the option of creating a btrfs filesystem when setting up from scratch. It may have been "unsupported" but their own setup process allowed you to continue.
This type of comment seems repeated in various outlets.
Have you personally created a btrfs filesystem on one of these 5 affected devices?
I've bought Synology NAS for a long time. Each time I buy one for myself or others, I read the spec sheet and specifically buy one that supports btrfs. It's clearly listed for each model what it supports.
If it is as they state, this unintentional bug was allowing people to do things that are not validated to run reliably, then leaving the bug unfixed is also a bad idea.
Relying on bugs to do your work is a bad plan. This shows why.
[1] https://www.reddit.com/r/synology/comments/mqks2q/the_latest...