On Thu, Dec 8, 2022 at 7:37 AM Dale <rdalek1...@gmail.com> wrote: > > Path two, I've researched building a NAS using a Raspberry Pi 4 8GB as > another option. They come as parts, cases too, but the newer and faster > models of Raspberry Pi 4 with more ram seem to work pretty well.
For this sort of application the key improvement of the Pi4 over its predecessors is IO. The Pi4 has USB3 and gigabit ethernet, and they are independent, so you get the full bandwidth of both (in theory). That is a massive step up over USB2 and 100Mbps ethernet that consumes the USB2 bandwidth. I can't really speak to the commercial solutions as I haven't used them. Main concern there is just the limited capacity, lack of expandability, and so on. Some are no doubt better than others in those regards. As far as DIY goes, you can definitely do all of that with a Pi4. Don't expect it to perform as well as sticking it on a decent amd64 motherboard, but for backup and saturating the throughput of 1 hard drive at a time it can probably mostly make do. Encryption can be accomplished either with cryptsetup or a filesystem that has native encryption like ZFS. I've done both on Pi4s for storage. I will warn you that zfs encryption is not hardware-optimized on ARM, so that will not perform very well - it will be completely functional, but you will get CPU-bound. Linux-native encryption (ie cryptsetup/LUKS) will use hardware capabilities on the Pi4, assuming you're using something it supports (I think I'm using AES which performs adequately). For the Pi4 you would need to use USB storage, but for hard drives IMO this is perfectly acceptable, especially on a Pi. The gigabit ethernet and internal IO of the Pi is only going to max out one hard drive no matter how you connect it, so the USB3 interface will not be a bottleneck. On ARM SBCs that have PCIe you don't really get any better performance with an HBA and SATA/SCSI simply because the board IO is already pretty limited. USB3 is actually pretty fast for spinning disks, but depending on the number of hosts/etc it could become a bottleneck on a decent motherboard with a large number of drives. If you're talking about an amd64 with a 10GbE NIC and a decent HBA with sufficient PCIe lanes for both then obviously that is going to saturate more spinning disks. For NVMe you absolutely need to go that route (probably need to consider server-class hardware too). I use USB3 hard drives on Pis for my bulk storage because I care about capacity far more than performance, and with a distributed filesystem the performance is still good enough for what I'm doing. If I needed block storage for containers/VMs/whatever then use a different solution, but that gets expensive fast. Oh, one other thing. One of your issues is that you're using a backup solution that just dumps everything into a single file/directory and requires all the backup storage to be mounted at the same time in a single filesystem. There are solutions that do not have this requirement - particularly ones that are adaptable to tape. Unfortunately the best FOSS option I've found for this on linux is bacula and that is a serious PITA to use. If anybody has a better one I'm all ears (the requirement is to be able to store a backup across multiple hard drives, and this can't involve first storing it all in one place and then splitting it up later, or having more than one storage drive attached at the same time - basically I want to treat hard drives like tapes). If you're storing a LOT of backups then LTO is another option. Every time I do the math on that option it never makes sense unless you're backing up a LOT of data. If you got to a point where your backups consumed 10+ max-capacity hard drives it might start to make sense. Those USB3 hard drives on sale for $15/TB though are just really hard to beat when the tapes aren't all that much cheaper and the drives cost $1k. -- Rich
