Apps using NAS grade HDDs - is that ok?

I have 3 NAS grade HDDs in my true nas (Toshibas N300’s) - one pool. (System is on small SSD). It seems that when I install an app that uses database like postgres I hear a “crunch” in about two second interval from the drive, which means it r/w frequently (even if just a little), right? Example apps are Home Assistant, Warracker but even Nginx Proxy Manager seemed to do that…

My question is fairly simple. The drives were quite costly - am I wearing them unnecessarily by running the apps on it? I assume those drives are optimized for storage rather than constant r/w, right?

What could I do?. Should I add one SSD just for the apps? Or should I add it as a cache?

Thank you

Apps don’t need much space for their installation and configuration data. If you have the slots and money, you might be happier purchasing two SSDs to make a simple mirror pool just for your Apps. They don’t even need to be NVMe. SATA SSDs are just fine for this.

This will eliminate the noise and leave the spinners dedicated to user data only.

You’ll also get extra capacity for doing temporary work. This can be used for datasets to test things or temporarily hold onto data when shuffling things around or receiving torrent downloads.

3 Likes

“NAS-grade” does not give a mechanical drive more IOPS.
If the three drives are set in raidz1 rather than 3-way mirror, you’re adding a further layer of insufficiency for small transactions, such as databases.
Get a SSD or two (mirror).

2 Likes

@winnielinnie @etorix thank you both! This really helps :slight_smile: I think I might add only one ssd and back it up once a day to storJ. Otherwise I would have to buy some sata expansion.

Just back up to your HDD pool.

1 Like

That is an option, but I would back that up to Storj anyway (I am already doing that), so maybe It makes sense to do it directly.

“NAS-grade” just means it’s made to run 24x7 and supposedly is more reliable than a desktop HDD. Running a database on these drives probably isn’t actually hurting them, but their performance for such a workload (lots of small IOPs) is very poor compared to a modern SSD. As someone else suggested, you should run these databases on an SSD (or a mirrored array if you want redundancy), and then automatically back them up to the HDD array. This is pretty easy to do in TrueNAS; you can set the SSD to have daily snapshots, and then also copy those snapshots to your HDD pool.

I would back up to your HDD pool and then back up only the HDD pool to Storj not the SSD one. Since the SSD pool has no parity when that SSD fails you will have to pay to get your data back (egress costs). If you back up to your HDD pool, a lot more drives have to fail at once to make it so that you have to pay to egress the data. Otherwise you can just restore the data locally.

1 Like

Thanks, I ordered the SSD yesterday, I didn’t realize the performance suffers such. Kinda make sense though :grinning:
Btw isn’t snapshot just a table that says where the data are on the drive? So if the drive fails, how is that beneficial to have such a table on different drive? The data are gone anyway, no?

Aha, that is a very good point. Thank you!

In fact, some apps will fail/error if they are hosted on a small hd pool as they are not expecting such low performance

In a way yes, but when you replicate the snapshot all the referenced data is copied.

All right, got it. Thank you for the additional information :slight_smile: Still waiting for the ssd to arrive, seems I was unlucky but I think they just re-stocked :crossed_fingers: