Choosing the right NAS – Synology vs. QNAP

And the reasons for that are the following:

1. QNAP is truly not suited for beginners. I consider myself quite experienced with computers. I was working on my first computers using a soldering iron, I programmed in assembler, I built entire networks and RAID storage units for professional usage in my own company 20 years ago including obtaining our own IP address space managed by our own BGP4 router and I know my way around a shell (be it MS-DOS or Unix).
   Nonetheless despite all that knowlegde, the questions I got asked by my QNAP when setting it up for the first time, caused me to google things like “static volume vs. thick volume vs. thin volume” and even after reading for an hour, I still wasn’t sure, which option to choose for my purposes. (I went with a thick volume, just to compromise between performance loss and flexibility while maintaining the highest chance of being able to correct my choice later, should it turn out to be a mistake). Also the simple creation of shared folders (a standard task to create accessible storage space on a NAS) didn’t come as easy as it did with the Synology. I am not sure how quickly I would have mastered that task without having over 3 years of experience using NAS storage systems.
2. QNAP does not support the modern filesystem Btrfs. It comes only with the older Linux standard filesystem ext4 and if you’re willing to pay extra you can install the support for the filesystem exFAT, but I am not sure why one would want to use that filesystem on a NAS (unless you want to read directly from a USB stick only available in exFAT). If I want to store data from my Windows machines, I can do so through the regular SMB or other transfer protocols and don’t really care that much about the fileformat used by the NAS to store the data on its harddrives

   Except for the filesystem Btrfs, which – if used by the NAS – offers extra checksum and autorepair functions, giving your data an additional layer of security without any manual intervention from your side needed. Btrfs also offers features like native snapshot and data protection at a fraction of the storage space needed for similar features based on ext4.

   What’s most bizarre about this: Linux offers native Btrfs support for over 12 years now, which has become quite stable about three years ago and the last fringe issue (happening only when choosing the combination of RAID5 with Btrfs and then experiencing a hard drive failure right after an unclean shutdown) has been resolved by Synology’s implementation as well. Some people argue, Btrfs would cause overhead and thus cost you performance. Please be assured that in a standard Gigabit Ethernet (or even a network where most devices are connect by WiFi) the bottleneck will always be the network throughput and whatever overhead is caused by filesystems or added encryption is covered easily by the processing power of your NAS.

   And if a QNAP fan should now argue, why I don’t mention QNAP’s support for ZFS, the answer is simple:
   a) ZFS requires a huge amount of RAM to perform reasonably. We’re talking about 16 GB or better even 32 GB of available memory. Since even most prosumer NASs are limited to 8 GB of RAM, this is simply not a feasible option.
   b) Hence ZFS is only supported on QNAP’s business line devices, which cost a lot more than your standard home user NAS.

   So there is no reason to not use Btrfs on your NAS and it actually shouldn’t require too much effort from QNAP to integrate Btrfs support into their devices.

3. QNAP does not support something equivalent to Synology’s SHR RAID. Similar to Btrfs, Linux offers natively an advanced and more flexible RAID regime called mdadm. Synology has – as often – just built a nice and easy to use wrapper around this technology and thus saves you the headache of needing to understand much of the technology behind it. The big advantage of SHR is he flexibility it offers when wanting to update your RAID regime a few years later. To make a long story short: you can easily switch RAID levels anytime when adding more harddrives and also lump together harddrives of different size without losing any of their capacity (in a classic RAID5 for example, the total size of the RAID volume is determined (and thus limited) by the smallest drive in the array and the additional space of the larger drives is wasted).
   
   
4. But it gets even stranger: while the stuff above already displays a strange absence of basic functionality, I would have never expected from a serious player in the NAS market being so negligent regarding the topic backup.
   In a nutshell: you can not backup the apps installed on your QNAP or the data generated by those apps!

   This has two severe consequences:
   a) should you want to backup for example a single application like the QuMagie app to move the connected data (i.e. face recognition database etc.) to another QNAP device of yours, there is not support for that.
   b) should you experience a severe loss of data (i.e. the entire QNAP is stolen or fried by a lightning strike in the vicinity for example), there is simply no way of just buying the same (or similar) QNAP hardware again and restoring your entire setup from any of your backup devices.

   Don’t get me wrong: of course QNAP supports backup schemes in general. But these are limited to two purposes:
   i) using the QNAP device as a backup target for your computers, mobile or other devices
   ii) using the QNAP to backup the data stored on its harddrives to an external harddrive or remote NAS

   But should your QNAP NAS itself implode, you are forced to set up everything from scratch (except for a configuration file that you hopefully thought of saving every once in a while manually). And the hours of labor you have spent in QuMagie to join the faces recognized by the AI into the same person (i.e. pictures of persons wearing sunglasses, hats, diving gear or from their early childhood) are lost. So is the entire content of apps like Notes Station or the tagging work you have performed of your photos in your Photo Station