Hi! I’m new around here and want to hear second opinions. I’m a long time user of Linux/Unix for many years (not too heavy of a sysadmin, but I still know my way around decently).
I’m wanting to find a sweet spot for said NAS, and that sweet spot is a decent enough interface for regular users (since the rest of my family isn’t *nix inclined), but doesn’t abstract itself away too much to the point that if I need to dig into the guts it isn’t a massive pain in the back.
Just a Jellyfin, web-attached storage, and incremental backup to single-disk via a simple button is all I need – so a one-click Bash script or something that backs up to x disk UUID/ZFS pool or whatever should suffice.
The aforementioned single backup disk is primarily offline, so it shouldn’t be treated as a persistent piece of infrastructure, which was a big pain spot in the past on TrueNAS for me. I don’t know if I was just missing something there, but when I tried it a few years back it was really annoying to work with for this use case, and it felt like the UI didn’t accommodate for a disk only being attached for a short period of time.
My current setup is a copyparty instance pointed to a local 3x4TB BtrFS RAID 1 on Ubuntu, being backed up to a single 8TB disk using Borg Backup. Until very recently, I was using mdadm to accomplish the RAID, but it ended up being very unreliable and each reboot I had to constantly reconstruct the array manually despite having tried many things to get it mounting consistently on its own.
I’m thinking, considering my past experiences and current setup, the best balance between effort, storage space, reliability, safety, and ease of maintenance is using the existing OS installation with OpenZFS to make a RAID5 and back up either to the same Borg repository or via Syncoid. But maybe there’s something critical I was missing about TrueNAS in the past that would have made it perfect. I’d like to hear your experiences and wisdom.
Yeah, mostly. Right now, the setup is just a regular BtrFS Raid1 plus manual backups via Borg – the backup drive is physically disconnected from the server at most times, so in any catastrophic hardware destroying event the data would still remain safe, at the tradeoff that I have to manually initiate backups on my own.
I had a feeling as such…
I only have experience with ZFS inside of specialized NAS operating systems like TrueNAS thusfar who prefer having physical media be part of a ZFS pool. If I’m using a generic Linux distro, then I have a say over what filesystem the backup drive is bestowed and I can back up the files via rsync or Borg directly from the mount-point. I’d have to get a feel for how such a setup would work, really.
I only have 3 drives I’m absolutely sure I’m contributing to the RAID. My offline backup disk is 8TB, so with the drives I currently have, I probably don’t want to push it much beyond that to make sure I have enough space as data drips down onto the backup HDD over time.
That’s true, but in the past I had approached using it only via their web interfaces. It may be more worthwhile to handle the ZFS management and backups manually for such a use case, rather than trying to work around how they expect the user to interface with the data which was incompatible with my goals.
Its debian derived but afaik its set up as an appliance. Anything not done through sanctioned means (ie the gui or some cli commands that control the truenas backend application) may or may not get overwritten or ignored on reboot or update.
If you want to go custom use debian and zfs, or debian and whatever filesystem, do not try to treat truenas like its just a Debian with Webmin web interface. It will break your customizations.
Yeah zfs management is nothing special from cli and a lot less obtuse than truenas webgui. Once you learn a couple commands (since its completely self sufficient and does not rely on classic mount or fstab), the world is yours.
For example if you want to use zfs on a drive that is turned off, you can just
zpool export poolname
To stop the single drive pool and remove it from automount list and then it can be shut down.
When you connect it again
zpool import poolname
Will start up the zfs pool and mount it.
Btw you can make scripts that automate things and provide a web gui to trigger them for non technical users with projects like
I love the terminal. It seems so obtuse at first, but knowing it well I prefer using it over a GUI for a lot of tasks. It just cuts down on so much complexity and so many UX assumptions.
Ooh, I may have to give OliveTin a shot, this is new to me. Thanks!
While I won’t say it’s the best, you can do RAID1 within BTRFS. This actually works really well on 3 disks, as BTRFS RAID1 really means “Store two copies of my data on different disks”. So you can freely add and remove disks of different sizes. You can also rebalance to restore your redundancy without adding more disks, you’ll just lose free space.
In terms of the option with the best UI, I’m not sure off hand. I’d suggest making a VM with a few 1GB disks and trying out different things in TrueNAS.
Nahh, not really. This isn’t QNAP or Synology.
But hey, I am open to hear examples.
Everything you describe can be done 1:1 in the webGUI.
You can do almost everything there and you can do everything else without a problem in the shell. At least when we talk about ZFS. We would need to know what Kaylie did not like about the previous experience.
This was many years ago now so I don’t quite remember, maybe my brain is just written in the terminal and working with disks in a web dashboard is just not how my mind likes it.
I also had a massive development recently, after I wrote this post… I realized all my drives set aside for this purpose are SMR! This is a… less than adequate outcome, but it is what it is.
ZFS probably isn’t the right choice here now that I know that information. I have a 4TB WD Blue CMR disk sitting inside my main PC that I use for local backups of data on /home, but it might be advantageous to swap that disk in and assign it the task of being the parity disk in a SnapRAID setup instead, since the parity writes would be isolated to that one CMR disk instead of being striped across all pool participants like it would be on the RAIDZ1 that I was planning beforehand. Down the road, as I drop in more CMR disks, ZFS may become more viable over time.
It tells me that it is an appliciance like OPNsense.
That is IMHO not comparable with something like QNAP that overwrites your sshd settings at every boot.
Give examples. I am not aware of any stuff that TrueNAS overwrites, which could be of relevance for most users.
I know. My point was that OP argued that THIS was the reason to move away from TrueNAS, when is it perfectly possible to even do in the TrueNAS webGUI.
I used to have a rig based on Seagate Archive 8TB SMR disks back in the day. It worked without any problem. RAIDZ2 with 8 drives.
There is almost nothing that makes SMR drives less suited for ZFS than any other CoW. If you don’t plan on filling it up fast, I don’t think it’s as big of a problem as people claim it is.
SMR is very, very, very bad for sustained writes. But slowly filling up 40TB of Plex? No problem. I think it isn’t a coincidence that you won’t find people that have issues with SMR drives and ZFS unless they used a SMR drive as a replacement disk for a resilver. That of course a SMR drive is totally unsuited for.
That also does not recommend or support installing or configuring stuff manually through the shell, for the same reasons.
You compared it to syno and qnap, so you are talking to yourself here.
Why? my point is to not waste your time trying to customize an appliance, not teaching you how to do it safely at this specific point in time (which can change without notice at any moment).
Well you had the time to tell him. But above you said this regarding the use of a single drive that is often turned on and off, maybe you caused some of his confusion too.
Excuuuse me princessss?
Ive been using zfs arrays for cold storage, and zfs is fine on a single drive. whats the issue?
I concur with might be a fish, for a home nas scenario (mostly reads, not a lot of writes) the real blocker with zfs on SMR drives is mostly resilvering, i.e. a drive dies and you add a SMR drive and your resilver times become multiple weeks.
If you are just creating a pool, copying some data at the start and then just adding data piecemeal over time you are probably going to be fine. See also below for some technical reasons for that.
Just be VERY sure any drive you buy to replace a dead drive is NOT SMR.
the main reason for that is that SMR drives usually have something like a CMR cache, similar to SSDs do with SLC cache.
So they can act like CMR for a sizeable amount of writes before the CMR cache is full and performance tanks.
See for example this redditor’s experience with a SMR drive pool, where he confirms this behaviour we described.
Sometimes I need to send huge amounts of data, like for an initial zfs send of my Lightroom dataset. The performance of that looked exactly like you’d expect, it wrote at a very respectable speed for awhile (probably ~10x or 20x 20G) and then plummeted, then fluctuated up and down between “is it even working anymore?” and “is there a 10mbit network in the path?” speeds.
This is also fine for a home NAS.
In case you don’t know, snapraiid is often used together with Mergerfs.
It can “pool” the drives and make them show as a single mount point as if they were a single array, while in practice they are still just separate drives with no redundancy and mergerfs is just choosing in what drive your files go when you are adding files. (redundancy comes by using snapraid and having parity drives)
See for examples of use
I mean, yes and no. It depends on what. That is why your recommendation as an absolute is worthless. That is like me saying, trains are always better than cars.
Of course you can just run an additional NGINX server or a DynDNS bash script or whatever. Sometimes there is even an option to enable custom configs in .conf files like with KEA to precisely address your issue. But yes, I would not thinker with pf in CLI.
I was not talking about single drive or cold storage. I said that the FSwas not made for OP has in mind. And because of that, the phrase from a legend TrueNAS forums member applies here: “there might be dragons”