Hello All:
Brand new to TrueNAS. Abandoning a long serving WHS 2011 server (hey, it still worked!) in favor of something more up-to-date. Looking around led to FreeNAS, then to TrueNAS. Have been wrestling with the learning curve for about a week and a half, and am starting to understand the basics. It's taken a while, but it looks good now that I'm starting to get the hang of it. This will be a tad long -- and I apologize in advance to you gurus for whom this will all be verbose and boring (but I do have a couple of questions for you at the end if you're game, so just skip to there if you're falling asleep). For the benefit of other beginners in hopes that it may take DAYS off of somebody's learning curve, here are some things I at least think I've learned:
1. WHICH TRUENAS: There are TWO free versions of TrueNAS, and you need to decide which one you want. They are "Core" (based on the FreeBSD OS) and "Scale" (based on Debian Linux). I repeat this primarily because there's so much background on the web about Core being the "free" version of TrueNAS, and the designated successor of FreeNAS that I didn't even know Scale was an option during my initial install. Even when pointed to it when I started having trouble with plug ins, I initially ignored the advice because I assumed that all other versions of TrueNAS meant $$$. iX Systems could help with this -- both by being more up front about where this is all going (they're quite forthright in the forums, but the splashy web pages can be seriously misleading). But they're busy with OS builds, so just know that there are two versions, that you must choose, and that you should probably choose Scale if you're new and your use case isn't very, very much about rock solid stability.
Why does that matter? Well, if like me, you're looking for a home server (I consider 6 HDDs in a box to be a LOT), and you're not an IT pro, you're likely to be interested in Plug ins -- which are widely touted for both systems. Alas, those on the Core side a) apparently don't work well, or at all, and b) are not going to be maintained, and will get little or no additional attention according to iX systems -- they're apparently moving on to Scale, because the Linux side Docker plug ins used there are far more popular (presumably with developers).
In my case, that meant I could not use the similarly much touted Asigra backup -- because it requires resources that are not available on Core. The plug in just refuses to install indicating that it needs "13.1 release" -- apparently the FreeBSD version required to run the Plug in (and no, the newer version that is available on Core won't work). Huh?
Core is apparently the gold standard release, but seems to be headed more toward being an pure, ZFS driven, attached storage box. Scale is the new kid on the block, appears to be the future, and is effectively required if you want to run plug in apps.
Core apparently uses memory more efficiently out of the box, but you can "fix" the problem with Scale over on the Debian side.
www.youtube.com
In my case this may well mean I need to rebuild my system with Scale before I actually start using it -- even if I'm not going to use Plug-ins short term (more on that later). You get the feeling that iX Systems is committed to Scale now, and I don't want to have to do the rebuild exercise again in a year or two for no good reason.
2. FEAR, LOATHING, ECC and Desktop HDDs: There are numerous recitations in the official documentation that strongly recommend server grade parts (including HDDs) and ECC (error checking) RAM. This seems to be partly because of the way ZFS works (memory errors can threaten your storage solution) and partly because these systems are used by serious IT types in settings where people wander around talking about everything from ball-point pens to antiaircraft assets being "mission critical."
However, you'll also see reference to the fact that any number of hobbyists use what they have for a TruNAS Box, including desktop drives and ordinary RAM. I've been buying NAS HDDs for several years now -- they cost a few bucks more, but they have what seem useful reliability features, the performance difference is minimal (and if you care, there's that NVMe slot on the motherboard these days). But I wouldn't write off desktop drives if I already owned them. And I don't have ECC memory, and my AsRock motherboard housing the old i7 3770k I'm using apparently doesn't support it.
But here's the thing. One of the primary reasons for a server in my house is backup. I want it to be reliable, but we're all constantly reminded that failures will happen no matter what you do, and that we should never rely on any one storage location for data. ZFS seems to be a significant advance over other file systems, so I'm content to risk it. Wish me luck!
I would probably not use an overclocked gaming motherboard -- you're not going to work the cpu that hard, right? So it likley makes sense to fall back to defaults unless you're very certain about the stability of your overclock. But that's just me.
3. ZFS, POOLS, Vdevs, Oh My: Before you dive into either version of TrueNAS you'll want to read about ZFS in some detail. I did that, but it didn't help all that much at first. If like me, you're used to Windows and NTFS or various Linux equivalents, ZFS is big, complex, and -- if you have or are willing to buy the right group of physical discs -- absolutely fantastic. But initially, you're fairly likely not to "get' the relationship between Pools and Vdevs in particular.
I have six disks for the project -- things I had lying around or that could be had cheap (and come on, storage in hard drives is capital "C" cheap these days, so don't scrimp too much). I initially allocated them in two pools, in keeping with the way I had always thought about storage, as follows:
Pool 1: ZFS RAID (single parity) 4 x 4tb drives = 10+tb
Polls 2: Mirror 2 x 8tb drives = 8 tb
For effective RAID sizes see: https://wintelguy.com/zfs-calc.pl
That seemed pretty good, and probably would have been fine. But there's a widely recited ZFS trope that you should only have one pool, and that "more Vdevs" is better for performance. I didn't really understand the point, until I read this article:
I've had to rebuild a RAID array before, and it works. I'm not so massively concerned about losing another drive during the rebuild -- again that's for the mission critical crew. But the rebuilds do take forever even on what are today considered modest sized drives, which, along with the other good arguments in the article, led me to abandon the two-pool plan in favor of this:
Pool 1 (and only):
VDevs:
a: 2 x 4tb Mirror
b. 2 x 4tb Mirror
c. 2 x 8tb Mirror = 16tb total
That cost me 2 tb or so of storage, but this is PLENTY of space. Further, if I'm finally following, ZFS will stipe across the three Vdevs as though they were a RAID array -- which is why more Vdevs lead to better performance. It's like you have a RAID setup made of mirrors. Safe, fast and pretty impressive tech. What's not to like? And, as the article points out, its much easier to increase space in this setup later.
If you choose to experiment, you'll find that Core (and I'd guess Scale) makes changes easy as long as you don't have data on the drives yet. I was able to swap the drives around with just a bit of work under the storage tab. The interface is a bit daunting at first, but it seem to work well, and has a lot o bases covered.
4. BACKUP HELL, AND EVENTUAL SALVATION: As noted, one of the primary reasons for my having a server in the house is backup. In fact, syncing data files between a couple of machines, and providing a robust back up solution is the thing I really rely on the server for. Media Server? Maybe. Download target? Maybe. But there are other ways to accomplish those things.
WHS 2011 was the first OS I'd had that could both backup all the machines in the house daily without difficulty, could restore files you deleted or lost somehow, and could (at least Redmond claimed) do a bare-metal OS restore if things REALLY went south. With a plug in, you could build a "pool" (in a different sense that mentioned above) from HDDs of varying sizes, and tell the system what data (folders) you wanted duplicated to avoid loss due to a drive failure. The backup database would get corrupted from time-to-time, but it worked well enough. I'm STILL cranky with Microsoft for abandoning the product just as it was starting to get good.
So, how would I replace that function in TrueNAS? Should be simple, right? Don't you believe it. Here's what I learned over days of experiments trying to find something workable:
1. Asigra, the Core plug in is broken, as noted, and there's no indication that it will be fixed. It was apparently a good solution when it worked, . . . but not for you or me these days.
www.storagereview.com
2. A lot of folks like Veeam, but I got caught up in a complex group of issues there. First, I didn't understand that what I needed to understand was just the Windows client side piece, so I started with a piece of software meant to be insalled on a server. Then, I couldn't get the "Veeam Agent for Windows" to browse my peer-to-peer network. That's apparently a common problem, becasue the software relies on a SMBv1 to do so, which I seem to recall having been widely abandoned because of security issues. Windows turns it off by default, so Veeam can browse my other sources/drives -- but not True NAS. I think. Otherwise, Veeam looked pretty good. Could i fix it?
Well, browsing's not such a bid deal for backup. You just type the path to your backup folder, and you should be good, right? Nope. Not so fast. I asked to backup to a shared drive, designated the path to my target dataset, put in my Window credentials, and hit next -- but Veeam still couldn't get to the dataset I'd established for backups. What's up with that? (More in a sec).
3. OK, so how about something like the apparently excellent Paragon backup or something similar? Nope. Same problem. But now, the error messages (those in Veeam were varied, and pretty much incomprehensible in my ignorance) were suddenly sufficient for failure to be come a teacher -- "Access is denied." Since I could run test backups to other shared folders in the Workgroup, this meant that there was something about access to the TrueNAS dataset that needed attention (think "folder" for now, but better, and read up on that topic too if you're new).
After trying every possible version of syntax in the path (slashes or not, IP address instead, computer name before username or not, etc., etc., followed by extra-strength Tylenol) I started in on the "access denied" question under pools, by clicking the triple dot menu associated with the intended dataset. But I quickly found that security here involved groups and such, and I wasn't sure how I had my users set up. So an went to accounts and opened the "users" interface, followed by the user I had logged on during my experiments. Click the caret/arrow at the end of the line, then "edit" on the bottom left.
Hmm, lets see. As with all things TrueNAS, flexibility means complexity, and there are lots of options here, but in the far bottom corner on the right I saw this:
Check that one little box, and you're all good. Come on, really? That simple? Now Paragon could back up, Veeam could back up, and I'm off to figure out which free or paid option is best. Backup tools work. Sync tools work. Clouds parted and the Sun came out. Sheesh.
Apparently, using password pairs that match those on your Windows machines isn't enough out of the box. Great for security, I'm sure. Not so great for getting something simple like what I was trying to do. And since I'm NOT an IT God, this hadn't occurred to me until Paragon threw one of the few intelligent error messages I've encounterd in years and years of reading them. Live and learn.
So far, all of these are client based -- not like what I was used to with WHS, or like what was promised with Asigra. But I don't have that many clients, so I can certainly make this work.
5. QUESTIONS: I've reached the point where I know I can make this work. And I like what I see (now that I can finally see it), and look forward to using the new system. But that does still leave questions if you gurus would care to weigh in:
1. Which OS: The trend seems to be towards Scale, and I can certainly contemplate the possibility that plug ins will be of interest. But I didn't use many/any on the WHS 2011 box, and the max RAM for my Motherboard is the 32gb already in the slots.
There are three options, I think.
a. Stick with Core: Stable, built, and ready to serve now.
b. Move to Scale: Easy to do I suspect, with just a bit of configuration that largely mirrors what I've already described. Seems to be the perceived future. Plug ins could be useful if i have enough memory to run them.
c. Move to Scale and minimize Plug ins -- probably none for now. Apply the fix for memory described above and play like it's Core for now. Consider it future proofing.
Any thoughts on the best option?
2. Still toying with Read Cache options (L2ARC). Not sure I really need it, and it will bite into the existing RAM a bit. But I have this old 64gb synapse cache SATA SSD drive that's small enough not to take much of it, would add a decent slice of cache. Not the fastest, but certainly faster than the spinning drives, right? Worth a try, or skip and and just use the server?
3. Backup Options: I'll pick a product, but is it better on a small system of <10 PCs to run client only, client server combos, or Asigra's server-does-it-all solution? Should I care?
Appreciation in advance for any advice. And before I go -- great looking OS. LOTS of capability, and likely good performance and safety. Notwithstanding some comments here, I'm aware that I'm working out of my depth. So thanks to all of the developers, both before and after iX Systems took over, and thanks also for allowing us amateurs to experiment and use the product for free.
Brand new to TrueNAS. Abandoning a long serving WHS 2011 server (hey, it still worked!) in favor of something more up-to-date. Looking around led to FreeNAS, then to TrueNAS. Have been wrestling with the learning curve for about a week and a half, and am starting to understand the basics. It's taken a while, but it looks good now that I'm starting to get the hang of it. This will be a tad long -- and I apologize in advance to you gurus for whom this will all be verbose and boring (but I do have a couple of questions for you at the end if you're game, so just skip to there if you're falling asleep). For the benefit of other beginners in hopes that it may take DAYS off of somebody's learning curve, here are some things I at least think I've learned:
1. WHICH TRUENAS: There are TWO free versions of TrueNAS, and you need to decide which one you want. They are "Core" (based on the FreeBSD OS) and "Scale" (based on Debian Linux). I repeat this primarily because there's so much background on the web about Core being the "free" version of TrueNAS, and the designated successor of FreeNAS that I didn't even know Scale was an option during my initial install. Even when pointed to it when I started having trouble with plug ins, I initially ignored the advice because I assumed that all other versions of TrueNAS meant $$$. iX Systems could help with this -- both by being more up front about where this is all going (they're quite forthright in the forums, but the splashy web pages can be seriously misleading). But they're busy with OS builds, so just know that there are two versions, that you must choose, and that you should probably choose Scale if you're new and your use case isn't very, very much about rock solid stability.
Why does that matter? Well, if like me, you're looking for a home server (I consider 6 HDDs in a box to be a LOT), and you're not an IT pro, you're likely to be interested in Plug ins -- which are widely touted for both systems. Alas, those on the Core side a) apparently don't work well, or at all, and b) are not going to be maintained, and will get little or no additional attention according to iX systems -- they're apparently moving on to Scale, because the Linux side Docker plug ins used there are far more popular (presumably with developers).
In my case, that meant I could not use the similarly much touted Asigra backup -- because it requires resources that are not available on Core. The plug in just refuses to install indicating that it needs "13.1 release" -- apparently the FreeBSD version required to run the Plug in (and no, the newer version that is available on Core won't work). Huh?
Core is apparently the gold standard release, but seems to be headed more toward being an pure, ZFS driven, attached storage box. Scale is the new kid on the block, appears to be the future, and is effectively required if you want to run plug in apps.
Core apparently uses memory more efficiently out of the box, but you can "fix" the problem with Scale over on the Debian side.
How To Get the Most From Your TrueNAS Scale: Arc Memory Cache Tuning
https://lawrence.video/truenasZFS Arc Value Location /sys/module/zfs/parameters/zfs_arc_maxBytes converterhttps://whatsabyte.com/P1/byteconverter.htmTrueNAS ...
www.youtube.com
In my case this may well mean I need to rebuild my system with Scale before I actually start using it -- even if I'm not going to use Plug-ins short term (more on that later). You get the feeling that iX Systems is committed to Scale now, and I don't want to have to do the rebuild exercise again in a year or two for no good reason.
2. FEAR, LOATHING, ECC and Desktop HDDs: There are numerous recitations in the official documentation that strongly recommend server grade parts (including HDDs) and ECC (error checking) RAM. This seems to be partly because of the way ZFS works (memory errors can threaten your storage solution) and partly because these systems are used by serious IT types in settings where people wander around talking about everything from ball-point pens to antiaircraft assets being "mission critical."
However, you'll also see reference to the fact that any number of hobbyists use what they have for a TruNAS Box, including desktop drives and ordinary RAM. I've been buying NAS HDDs for several years now -- they cost a few bucks more, but they have what seem useful reliability features, the performance difference is minimal (and if you care, there's that NVMe slot on the motherboard these days). But I wouldn't write off desktop drives if I already owned them. And I don't have ECC memory, and my AsRock motherboard housing the old i7 3770k I'm using apparently doesn't support it.
But here's the thing. One of the primary reasons for a server in my house is backup. I want it to be reliable, but we're all constantly reminded that failures will happen no matter what you do, and that we should never rely on any one storage location for data. ZFS seems to be a significant advance over other file systems, so I'm content to risk it. Wish me luck!
I would probably not use an overclocked gaming motherboard -- you're not going to work the cpu that hard, right? So it likley makes sense to fall back to defaults unless you're very certain about the stability of your overclock. But that's just me.
3. ZFS, POOLS, Vdevs, Oh My: Before you dive into either version of TrueNAS you'll want to read about ZFS in some detail. I did that, but it didn't help all that much at first. If like me, you're used to Windows and NTFS or various Linux equivalents, ZFS is big, complex, and -- if you have or are willing to buy the right group of physical discs -- absolutely fantastic. But initially, you're fairly likely not to "get' the relationship between Pools and Vdevs in particular.
I have six disks for the project -- things I had lying around or that could be had cheap (and come on, storage in hard drives is capital "C" cheap these days, so don't scrimp too much). I initially allocated them in two pools, in keeping with the way I had always thought about storage, as follows:
Pool 1: ZFS RAID (single parity) 4 x 4tb drives = 10+tb
Polls 2: Mirror 2 x 8tb drives = 8 tb
For effective RAID sizes see: https://wintelguy.com/zfs-calc.pl
That seemed pretty good, and probably would have been fine. But there's a widely recited ZFS trope that you should only have one pool, and that "more Vdevs" is better for performance. I didn't really understand the point, until I read this article:
I've had to rebuild a RAID array before, and it works. I'm not so massively concerned about losing another drive during the rebuild -- again that's for the mission critical crew. But the rebuilds do take forever even on what are today considered modest sized drives, which, along with the other good arguments in the article, led me to abandon the two-pool plan in favor of this:
Pool 1 (and only):
VDevs:
a: 2 x 4tb Mirror
b. 2 x 4tb Mirror
c. 2 x 8tb Mirror = 16tb total
That cost me 2 tb or so of storage, but this is PLENTY of space. Further, if I'm finally following, ZFS will stipe across the three Vdevs as though they were a RAID array -- which is why more Vdevs lead to better performance. It's like you have a RAID setup made of mirrors. Safe, fast and pretty impressive tech. What's not to like? And, as the article points out, its much easier to increase space in this setup later.
If you choose to experiment, you'll find that Core (and I'd guess Scale) makes changes easy as long as you don't have data on the drives yet. I was able to swap the drives around with just a bit of work under the storage tab. The interface is a bit daunting at first, but it seem to work well, and has a lot o bases covered.
4. BACKUP HELL, AND EVENTUAL SALVATION: As noted, one of the primary reasons for my having a server in the house is backup. In fact, syncing data files between a couple of machines, and providing a robust back up solution is the thing I really rely on the server for. Media Server? Maybe. Download target? Maybe. But there are other ways to accomplish those things.
WHS 2011 was the first OS I'd had that could both backup all the machines in the house daily without difficulty, could restore files you deleted or lost somehow, and could (at least Redmond claimed) do a bare-metal OS restore if things REALLY went south. With a plug in, you could build a "pool" (in a different sense that mentioned above) from HDDs of varying sizes, and tell the system what data (folders) you wanted duplicated to avoid loss due to a drive failure. The backup database would get corrupted from time-to-time, but it worked well enough. I'm STILL cranky with Microsoft for abandoning the product just as it was starting to get good.
So, how would I replace that function in TrueNAS? Should be simple, right? Don't you believe it. Here's what I learned over days of experiments trying to find something workable:
1. Asigra, the Core plug in is broken, as noted, and there's no indication that it will be fixed. It was apparently a good solution when it worked, . . . but not for you or me these days.
How it Works: Asigra FreeNAS Plugin for Backup
Asigra for FreeNAS clicks all the checkboxes for a backup solution: it is easy to use, offers security when sources to be backed up are being ingested
www.storagereview.com
2. A lot of folks like Veeam, but I got caught up in a complex group of issues there. First, I didn't understand that what I needed to understand was just the Windows client side piece, so I started with a piece of software meant to be insalled on a server. Then, I couldn't get the "Veeam Agent for Windows" to browse my peer-to-peer network. That's apparently a common problem, becasue the software relies on a SMBv1 to do so, which I seem to recall having been widely abandoned because of security issues. Windows turns it off by default, so Veeam can browse my other sources/drives -- but not True NAS. I think. Otherwise, Veeam looked pretty good. Could i fix it?
Well, browsing's not such a bid deal for backup. You just type the path to your backup folder, and you should be good, right? Nope. Not so fast. I asked to backup to a shared drive, designated the path to my target dataset, put in my Window credentials, and hit next -- but Veeam still couldn't get to the dataset I'd established for backups. What's up with that? (More in a sec).
3. OK, so how about something like the apparently excellent Paragon backup or something similar? Nope. Same problem. But now, the error messages (those in Veeam were varied, and pretty much incomprehensible in my ignorance) were suddenly sufficient for failure to be come a teacher -- "Access is denied." Since I could run test backups to other shared folders in the Workgroup, this meant that there was something about access to the TrueNAS dataset that needed attention (think "folder" for now, but better, and read up on that topic too if you're new).
After trying every possible version of syntax in the path (slashes or not, IP address instead, computer name before username or not, etc., etc., followed by extra-strength Tylenol) I started in on the "access denied" question under pools, by clicking the triple dot menu associated with the intended dataset. But I quickly found that security here involved groups and such, and I wasn't sure how I had my users set up. So an went to accounts and opened the "users" interface, followed by the user I had logged on during my experiments. Click the caret/arrow at the end of the line, then "edit" on the bottom left.
Hmm, lets see. As with all things TrueNAS, flexibility means complexity, and there are lots of options here, but in the far bottom corner on the right I saw this:
Check that one little box, and you're all good. Come on, really? That simple? Now Paragon could back up, Veeam could back up, and I'm off to figure out which free or paid option is best. Backup tools work. Sync tools work. Clouds parted and the Sun came out. Sheesh.
Apparently, using password pairs that match those on your Windows machines isn't enough out of the box. Great for security, I'm sure. Not so great for getting something simple like what I was trying to do. And since I'm NOT an IT God, this hadn't occurred to me until Paragon threw one of the few intelligent error messages I've encounterd in years and years of reading them. Live and learn.
So far, all of these are client based -- not like what I was used to with WHS, or like what was promised with Asigra. But I don't have that many clients, so I can certainly make this work.
5. QUESTIONS: I've reached the point where I know I can make this work. And I like what I see (now that I can finally see it), and look forward to using the new system. But that does still leave questions if you gurus would care to weigh in:
1. Which OS: The trend seems to be towards Scale, and I can certainly contemplate the possibility that plug ins will be of interest. But I didn't use many/any on the WHS 2011 box, and the max RAM for my Motherboard is the 32gb already in the slots.
There are three options, I think.
a. Stick with Core: Stable, built, and ready to serve now.
b. Move to Scale: Easy to do I suspect, with just a bit of configuration that largely mirrors what I've already described. Seems to be the perceived future. Plug ins could be useful if i have enough memory to run them.
c. Move to Scale and minimize Plug ins -- probably none for now. Apply the fix for memory described above and play like it's Core for now. Consider it future proofing.
Any thoughts on the best option?
2. Still toying with Read Cache options (L2ARC). Not sure I really need it, and it will bite into the existing RAM a bit. But I have this old 64gb synapse cache SATA SSD drive that's small enough not to take much of it, would add a decent slice of cache. Not the fastest, but certainly faster than the spinning drives, right? Worth a try, or skip and and just use the server?
3. Backup Options: I'll pick a product, but is it better on a small system of <10 PCs to run client only, client server combos, or Asigra's server-does-it-all solution? Should I care?
Appreciation in advance for any advice. And before I go -- great looking OS. LOTS of capability, and likely good performance and safety. Notwithstanding some comments here, I'm aware that I'm working out of my depth. So thanks to all of the developers, both before and after iX Systems took over, and thanks also for allowing us amateurs to experiment and use the product for free.
Last edited:
