Finally decided to build my 2nd TrueNAS server

[CheeryFlame]

Hello!

I've started the TrueNAS journey since a few months already and I feel like it's now the right time to backup my server (see in signature) onto a consumer computer that I would host at a remote site. I'm trying to avoid to buy a crappy NAS (Qnap/Synology/Terramaster/etc) whom only advantage seems to be it's size. So I started digging into building the smallest computer to mimic as close as possible the size of a commercial 5 bay NAS.

Here's the configuration I came with so far after reading this page -> https://ca.pcpartpicker.com/list/CBYk4s

This brought up some questions which I'm gonna write down here and would really appreciate some help!

1. The chosen motherboard has 2x M.2 slots which I would use for dual boot drives. I had issues in the past with power outages that has corrupted my boot drive and since then I'm running this configuration with my boot-pool. Unfortunately it's not something I can afford at the moment and since I'm trying to make a tiny build I would probably want to use the HBA controller for the HDDs. Would using 2x nvme drives would be a good alternative to get redundancy with my boot-pool or I absolutely need to have 3 drives?
2. As I'm currently on a budget I would start with 2x 20tb SATA hard drives that I would directly connect to the motherboard. At a later date I'll need to add more hard drives and I'll run out of SATA connections on the motherboard. Would there be any benefit of investing in a HBA card at this time, considering I'll only have 2x 20tb drives?
3. I plan on getting a total of 6x20tb SATA drives in this computer and I'd like to know the recommended RAM amount I should get for this build. I currently chose 32GB but I feel this might not be enough. I asking before ordering since this can't be upgraded at a later having only 2 slots on the motherboard. To help you answer this question, I'm not gonna use applications on this build since it's only to backup my server with an rsync task.

On top of those 3 questions, I'm very open to hear any recommendations regarding this project.

Thank you!

 

[winnielinnie]

Would using 2x nvme drives would be a good alternative to get redundancy with my boot-pool or I absolutely need to have 3 drives?

Are you implying that in the event of a power outage and failure/corruption of one M.2 boot drive, you won't have physical access nor remote access to power on the system and change the primary boot device?

I currently chose 32GB but I feel this might not be enough.

Seems like the low-end, especially for that much capacity. However, since you're not going to have any VMs or "Apps", and it sounds like it's mainly serving as a backup destination (almost exclusively writes), there isn't that much need for a massive ARC to speed up reads to lessen HDD activity. (Still think you can bump it to 64 GiB if it's within your budget.)

To help you answer this question, I'm not gonna use applications on this build since it's only to backup my server with an rsync task.

If it's going to be a TrueNAS server, why use rsync for your backups? Why not ZFS snapshots + replications? Not only is it faster and more efficient, unlike rsync, ZFS replications do not need to "crawl" the entire directory tree. Hence, you don't even need dedicated space on ARC to house a lot of metadata. This also lowers your RAM requirements. (Still think you can bump it to 64 GiB if it's within your budget.)

 

[CheeryFlame]

Are you implying that in the event of a power outage and failure/corruption of one M.2 boot drive, you won't have physical access nor remote access to power on the system and change the primary boot device?

I'll have access to it. I just want to not have to keep reinstalling TrueNAS if something happens. Still the build will be plugged on battery that I'll decommission from home this year. Although I don't think it has a function to let TrueNAS know it's on battery and that it should shutdown.

Seems like the low-end, especially for that much capacity. However, since you're not going to have any VMs or "Apps", and it sounds like it's mainly serving as a backup destination (almost exclusively writes), there isn't that much need for a massive ARC to speed up reads to lessen HDD activity. (Still think you can bump it to 64 GiB if it's within your budget.)

That is correct it's mainly serving as a backup destination. I mean I would make it work if it was absolutely necessary. Will I see a bump in the speed when backing up? The drives can probably write no more than 300mb/s, this is IF I get fiber as well at my remote destination. I wonder what's the bottleneck of 32GiB for my use case. I'm highly doubting I would max out a 1GiB per second with HDDs!

If it's going to be a TrueNAS server, why use rsync for your backups? Why not ZFS snapshots + replications? Not only is it faster and more efficient, unlike rsync, ZFS replications do not need to "crawl" the entire directory tree. Hence, you don't even need dedicated space on ARC to house a lot of metadata. This also lowers your RAM requirements. (Still think you can bump it to 64 GiB if it's within your budget.)

As you can see, I'm new to this forum and I'm still learning. I always used rsync so I guess, judging from by comment, that I should use it.

Thanks for all the great insights, that really helped me!

 

[Whattteva]

If it's going to be a TrueNAS server, why use rsync for your backups? Why not ZFS snapshots + replications? Not only is it faster and more efficient, unlike rsync, ZFS replications do not need to "crawl" the entire directory tree.

ZFS send/receive is also a lot more efficient than rsync when you're making small changes to large files like VM images.

 

[winnielinnie]

I'll have access to it. I just want to not have to keep reinstalling TrueNAS if something happens.

Then a two-way mirror boot-pool should suffice. Should one of the M.2 drives partially fail or become corrupt, and it happens to be the first boot device configured in your BIOS (which prevents the system booting up from the "good" M.2 drive), then you can just tell the BIOS to use the "good" M.2 drive as the primary boot device. (No need to reinstall anything.)

You can purchase another M.2 in the meantime, and then use the TrueNAS GUI to resilver the boot-pool by replacing the failed drive.

This, of course, doesn't negate the fact that you should make regular backups of your config.

That is correct it's mainly serving as a backup destination. I mean I would make it work if it was absolutely necessary.

This is really up to you and your budget. If it's not that much extra cost, doubling the RAM to 64 GiB can give you a higher ceiling and makes the system more "future proof". For example: in case you later repurpose the server.

As you can see, I'm new to this forum and I'm still learning. I always used rsync so I guess, judging from by comment, that I should use it.

Rsync is probably the best and most flexible "file-based" tool for transfers. Works great for ZFS to ZFS, ZFS to non-ZFS, non-ZFS to ZFS, and non-ZFS to non-ZFS. I highlighted ZFS to ZFS in bold, because it is the only pairing where you can leverage "block-based" transfers. This is where snapshots and replications come in.

It is wayyyyyyyy more efficient than using rsync, by orders of exponential magnitude.

Let's say there's only been a few changes since the last time you did a "backup".

With rsync, the entire directory tree (all filenames, locations, sizes, timestamps, permissions, and metadata) needs to be "crawled" on both sides. Even if there are only a few files that were added, modified, or deleted. This takes time, disk IO, and RAM.

With ZFS-to-ZFS incremental replication (using a common snapshot as the "base"), it immediately sends only the differences in blocks. No crawling an entire directory tree. No checking timestamps, filenames, or paths.