Your striping description is incorrect. You described raid 5. Striping has no parity/redundancy. It should also be said that mirrors are expensive. It's generally better to go with raid 5 or 6 as a reasonable sweet spot for capacity, redundancy, and not financially "reckless". Should also consider some form of backup strategy. Tape is king wrt density, cost, reliability, and duration. Initially steep outlay but once the hardware costs are absorbed, the cost/TB get ridiculously cheap.
I was describing how striping works in TrueNAS if you choose that option from the menu, which includes striping with a parity bit. Look at RAID-Z1 using the ZFS file system. My description of that is correct.
Tape is really not very practical for SMB's or home users that might be using something like TrueNAS. Tape usually require tape drives that can be expensive, though individual tapes are relatively inexpensive. Moreover, supporting tape systems is a very manual process without autoloaders. They can become very expensive. If you want a good backup offsite at the scale I'm talking about, consider cloud storage like archive storage on Azure or Glacier on AWS. It's relatively cheap and fully automatable.
@@BlaizeTech I am a home user and I use LTO(6 and 8) and TrueNAS. As I mentioned there is definitely an upfront cost to tape but it's still king in every metric save immediate access. If your application requires realtime/near realtime access to the data, tape will not be appropriate. But it could still be a 3rd tier solution to reduce the requirement/costs on warm storage. Further, the costs of LTO can be _vastly_ reduced if one picks an appropriately "vintage" generation. LTO6 external drives are approaching the cost of a couple 20TB hard drives now-a-days. SAS HBAs can be cheaper than those 10Gbe NICs you recommend. Management is certainly a factor. However, there are tools/apps that help. Proxmox Backup Server, as one example, isn't onerous. Whether one needs a changer or not would depend on the amount of data needing to be backed up on whatever frequency is required for a given user's acceptable timeframe of potential data loss. In a typical nightly frequency, if the data needing backed up is < 2TB-2.5TB then LTO6 can do that on a single tape. 1 tape change, outside of restoration needs, isn't that onerous. I have Quantum gear but just checked and there's an HP 24 slot SAS LTO6 w/mags for $629 on ebay right now. Cloud backups are an illusory bait and switch mixed bag. Super nice to put your data out there, if you have broadband upload bandwidth sufficient to the task, but most certainly not the deal you think they are when you actually _need_ your data. The charges are unpleasantly disparate in that regard. Having physical control of one's own data is a special level of peace of mind.
@@BlaizeTech When you muddy/overload terms confusion abounds. Your chart cites "mirror" and "striped". These have recognized specific meanings both in zfs and out. "Mirror" is raid1 because there is some actual redundancy there and "striped" is raid0 because there is no redundancy/parity. At around the 6m mark you discuss what you mean there. While you do indicate 3 disks it could be intimated you meant/mean raid{z1,5} since a "stripe" set just requires > 1 drive. Again, terminology/classifications have meanings. And this introduces confusion. More problematic, however, is when you get into the pool configuration around the 22m20s mark. The status shows a single 3-drive z1 vdev. So you off camera created it correctly. But when you are glossing over the layout types your description of what 'stripe" vs "raidz1" does is where people are going to be seriously led astray. You assert that "stripe" does the same thing as choosing "raidz1". This is not the case. If people, "...aren't sure, just choose stripe or mirror..." People choosing "stripe" believing they are going to end up with a raidz1 that lose a disk, and consequently everything, are going to be most displeased. Here's the delta between what actually gets created. Although it does mark the result pool appropriately. e.g. RAID-Z1, STRIPE, etc. root@truenas[/]# zfs status -v fleem_z1 pool: fleem_z1 state: ONLINE config: NAME STATE READ WRITE CKSUM fleem_z1 ONLINE 0 0 0 raidz1-0 ONLINE 0 0 0 0ab91075-3212-4323-a9dc-7826b41c5952 ONLINE 0 0 0 6e616e93-b95d-4410-8e1f-6725302d11bf ONLINE 0 0 0 a04b2b8e-ef8c-4f9c-a8ed-48bb97ec82f8 ONLINE 0 0 0
errors: No known data errors root@truenas[/]# zfs status -v fleem_stripe pool: fleem_stripe state: ONLINE config: NAME STATE READ WRITE CKSUM fleem_stripe ONLINE 0 0 0 af3229d7-50dc-36d5-9824-dec446380f84 ONLINE 0 0 0 2d6fd5b5-aa6b-423a-bea6-18cbcae57e19 ONLINE 0 0 0 fb6a58cc-8376-48d7-a69e-a4b4a77c4b82 ONLINE 0 0 0
errors: No known data errors I'm honestly not even trying to nit here. Everything else seems reasonable. If you're aiming this at n00bs I would hope the idea would be for more, proper, clarity rather than less. Mixing in 'stripe(d)' and raid(z1|5) especially in the pool creation layout may lead to confusion/a bad time.
Tape is still used in a few enterprises, but I am seeing fewer and fewer use it because it's not really practical. And I don't see any enthusiasts or SMBs going out and spending $600 on a 24 slot tape drive or even for a single slot drive. I don't think it's a bait and switch to use cloud backup at all. It's about 1$ per TB per month, it's off-site in a secure location, and it's fully automated. The last two are worth a ton. The NICs were for my purposes. I suggested 10 GB with DAC for low latency and high throughput. But it depends on what your doing. I don't think it's creating confusion at all. What I talked about was fine for my purposes. Creating a striped set with a parity bit gives you redundancy and performance. Being pedantic about the differences between RAID levels or RAID-Z levels was not needed. It was about building a NAS with minimal hardware. I recommended redundancy regardless, 2 drives for mirrors and 3 for striping and parity. The confusion is the information overload that comes from trying to understand the nuances of all these different schemes. You're welcome to disagree with me, but I wanted this to be simple.
Your striping description is incorrect. You described raid 5. Striping has no parity/redundancy.
It should also be said that mirrors are expensive. It's generally better to go with raid 5 or 6 as a reasonable sweet spot for capacity, redundancy, and not financially "reckless".
Should also consider some form of backup strategy. Tape is king wrt density, cost, reliability, and duration. Initially steep outlay but once the hardware costs are absorbed, the cost/TB get ridiculously cheap.
I was describing how striping works in TrueNAS if you choose that option from the menu, which includes striping with a parity bit.
Look at RAID-Z1 using the ZFS file system. My description of that is correct.
Tape is really not very practical for SMB's or home users that might be using something like TrueNAS. Tape usually require tape drives that can be expensive, though individual tapes are relatively inexpensive. Moreover, supporting tape systems is a very manual process without autoloaders. They can become very expensive. If you want a good backup offsite at the scale I'm talking about, consider cloud storage like archive storage on Azure or Glacier on AWS. It's relatively cheap and fully automatable.
@@BlaizeTech I am a home user and I use LTO(6 and 8) and TrueNAS. As I mentioned there is definitely an upfront cost to tape but it's still king in every metric save immediate access. If your application requires realtime/near realtime access to the data, tape will not be appropriate. But it could still be a 3rd tier solution to reduce the requirement/costs on warm storage. Further, the costs of LTO can be _vastly_ reduced if one picks an appropriately "vintage" generation. LTO6 external drives are approaching the cost of a couple 20TB hard drives now-a-days. SAS HBAs can be cheaper than those 10Gbe NICs you recommend. Management is certainly a factor. However, there are tools/apps that help. Proxmox Backup Server, as one example, isn't onerous. Whether one needs a changer or not would depend on the amount of data needing to be backed up on whatever frequency is required for a given user's acceptable timeframe of potential data loss. In a typical nightly frequency, if the data needing backed up is < 2TB-2.5TB then LTO6 can do that on a single tape. 1 tape change, outside of restoration needs, isn't that onerous. I have Quantum gear but just checked and there's an HP 24 slot SAS LTO6 w/mags for $629 on ebay right now.
Cloud backups are an illusory bait and switch mixed bag. Super nice to put your data out there, if you have broadband upload bandwidth sufficient to the task, but most certainly not the deal you think they are when you actually _need_ your data. The charges are unpleasantly disparate in that regard. Having physical control of one's own data is a special level of peace of mind.
@@BlaizeTech When you muddy/overload terms confusion abounds. Your chart cites "mirror" and "striped". These have recognized specific meanings both in zfs and out. "Mirror" is raid1 because there is some actual redundancy there and "striped" is raid0 because there is no redundancy/parity. At around the 6m mark you discuss what you mean there. While you do indicate 3 disks it could be intimated you meant/mean raid{z1,5} since a "stripe" set just requires > 1 drive. Again, terminology/classifications have meanings. And this introduces confusion. More problematic, however, is when you get into the pool configuration around the 22m20s mark. The status shows a single 3-drive z1 vdev. So you off camera created it correctly. But when you are glossing over the layout types your description of what 'stripe" vs "raidz1" does is where people are going to be seriously led astray. You assert that "stripe" does the same thing as choosing "raidz1". This is not the case. If people, "...aren't sure, just choose stripe or mirror..." People choosing "stripe" believing they are going to end up with a raidz1 that lose a disk, and consequently everything, are going to be most displeased.
Here's the delta between what actually gets created. Although it does mark the result pool appropriately. e.g. RAID-Z1, STRIPE, etc.
root@truenas[/]# zfs status -v fleem_z1
pool: fleem_z1
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
fleem_z1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
0ab91075-3212-4323-a9dc-7826b41c5952 ONLINE 0 0 0
6e616e93-b95d-4410-8e1f-6725302d11bf ONLINE 0 0 0
a04b2b8e-ef8c-4f9c-a8ed-48bb97ec82f8 ONLINE 0 0 0
errors: No known data errors
root@truenas[/]# zfs status -v fleem_stripe
pool: fleem_stripe
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
fleem_stripe ONLINE 0 0 0
af3229d7-50dc-36d5-9824-dec446380f84 ONLINE 0 0 0
2d6fd5b5-aa6b-423a-bea6-18cbcae57e19 ONLINE 0 0 0
fb6a58cc-8376-48d7-a69e-a4b4a77c4b82 ONLINE 0 0 0
errors: No known data errors
I'm honestly not even trying to nit here. Everything else seems reasonable. If you're aiming this at n00bs I would hope the idea would be for more, proper, clarity rather than less. Mixing in 'stripe(d)' and raid(z1|5) especially in the pool creation layout may lead to confusion/a bad time.
Tape is still used in a few enterprises, but I am seeing fewer and fewer use it because it's not really practical. And I don't see any enthusiasts or SMBs going out and spending $600 on a 24 slot tape drive or even for a single slot drive. I don't think it's a bait and switch to use cloud backup at all. It's about 1$ per TB per month, it's off-site in a secure location, and it's fully automated. The last two are worth a ton.
The NICs were for my purposes. I suggested 10 GB with DAC for low latency and high throughput. But it depends on what your doing.
I don't think it's creating confusion at all. What I talked about was fine for my purposes. Creating a striped set with a parity bit gives you redundancy and performance. Being pedantic about the differences between RAID levels or RAID-Z levels was not needed. It was about building a NAS with minimal hardware. I recommended redundancy regardless, 2 drives for mirrors and 3 for striping and parity. The confusion is the information overload that comes from trying to understand the nuances of all these different schemes. You're welcome to disagree with me, but I wanted this to be simple.
Please don't support and use AI for your video covers.
Why not?
Why not?