Re: [gentoo-user] NAS and replacing with larger drives

[Rich Freeman]

On Thu, Dec 8, 2022 at 7:37 AM Dale <rdalek1967@×××××.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