Storing data on unRAID as RAID1

[vvzvlad]

Good afternoon, I want to organize a server with storage, for which I pre-selected Hardware RAID controller in RAID1, and ESXi, which is deployed on a virtual disk provided by RAID controller, and a virtual machine with NAS functionality(e.q. FreeNAS), which is running in ESXi hypervisor. 

But as far as I can see, my needs are quite covered by UnRAID - I can run virtual machines and Docker containers in it. I also really like the licensing policy and active community, as well as the responsive interface, ssd cache. I would like to upgrade to unRAID.

However, my fundamental requirement is to store data on disks in mirrored mode, without using parity control. I have had experience with RAID5 and understand that the weak point of this data organization is the increased probability of one more disk failing in the process of intensive reading from the remaining disks when replacing one disk and rebuilding the array.
So, I want to be able to pull the second disk out of the array if the first disk fails and find all the files I had stored on it. 

As far as I understand, in case I have only two disks, one of which is set as parity and the other as disk1, I have a storage system similar to RAID1: on the second disk I have a copy of the data of the first disk, only in an inverted form. But what should I do if I need to use more than two disks? A system with three disks will no longer meet the requirement of a mirrored array. 

Is it possible to store data as a mirror array in unRAID?  
 

As far as I see, the raid view settings are in pool. But is it possible to store all data in pool at all, while keeping the benefits of caching on SSD?

Edited March 22, 2021 by vvzvlad
minor update

[JonathanM]

1 hour ago, vvzvlad said:

As far as I understand, in case I have only two disks, one of which is set as parity and the other as disk1, I have a storage system similar to RAID1: on the second disk I have a copy of the data of the first disk, only in an inverted form. But what should I do if I need to use more than two disks? A system with three disks will no longer meet the requirement of a mirrored array. 

Pretty much correct, but because Unraid uses EVEN parity, a 2 drive parity array is a copy, not inverted.

 

You could always add multiple BTRFS RAID1 pools in addition to a 2 drive parity array.

 

Cache is somewhat of a misnomer if you compare it to traditional caching, it would be more accurate to just refer to them as pools with a fuse filesystem that merges all the root folders on all participating pools. You can schedule moves between the parity array and individual pools.

[vvzvlad]

4 minutes ago, jonathanm said:

Pretty much correct, but because Unraid uses EVEN parity, a 2 drive parity array is a copy, not inverted.

 

Do I understand correctly that if I have only two disks, one of which is installed as parity, I have the same data on both disks? I.e., if the primary disk fails, I can pull out the parity disk and read it as a normal disk? (of course, the first mount will likely break the ability to use that disk as a parity disk later on, due to the metadata change).
 

 

6 minutes ago, jonathanm said:

You could always add multiple BTRFS RAID1 pools in addition to a 2 drive parity array.

 

Then what is the difference between a basic array and pools? The ability to add many different hard drives to the array and the mechanism of balancing the loading of the array by alternating writing files, as well as the mechanism of "unraid-like" parity, which is different from traditional RAID2/3/5? Are there any other differences?
 

 

9 minutes ago, jonathanm said:

Cache is somewhat of a misnomer if you compare it to traditional caching, it would be more accurate to just refer to them as pools with a fuse filesystem that merges all the root folders on all participating pools. You can schedule moves between the parity array and individual pools.

So I can not use a regular parity array, but install two disks of the same capacity as part of a separate pool (let's call it a storage pool), and use them that way, and it won't be any different in use than a regular parity array?
(I mean, it won't be any different for the user and the applications that will use the stored files, I understand that at a low level the principles of storage will be different)

And in that case, I would still be able to set up a relocation mechanism so that new files are quickly written/read from the SSD that is available in the cache-pool, but then, overnight, moved to the storage-pool consisting of two large HDD? 

[JonathanM]

1 hour ago, vvzvlad said:

Do I understand correctly that if I have only two disks, one of which is installed as parity, I have the same data on both disks? I.e., if the primary disk fails, I can pull out the parity disk and read it as a normal disk? (of course, the first mount will likely break the ability to use that disk as a parity disk later on, due to the metadata change).

Yes, a 2 disk Unraid parity with only parity slot 1 used is functionally a RAID1, but only the data disk actively participates in reads, and so limits read speeds to single drive specs. Just like any RAID volume, once the disks are mounted out of band, they must be resynched. I'm not sure what you mean by not being able to use the disk as parity, Unraid will happily overwrite any disk you assign to the parity slot, regardless of content.

 

1 hour ago, vvzvlad said:

Then what is the difference between a basic array and pools?

The basic array is the only pool that uses the Unraid special sauce parity code. All other pools are either XFS single volume or some flavor of BTRFS with or without software BTRFS RAID.

 

Think of the Unraid parity array as the mothership, all the subordinate pools can have automatic moves scheduled between the individual pool and the main array, but lateral moves from pool to pool aren't natively supported.

 

You could always script your own solution to move between 2 different sub pools, they are all exposed in the filesystem.

 

The overarching /mnt/user filesystem is simply a fuse of root directories on the main array and all the pools, and there are rules that can be applied for which pools participate.

 

1 hour ago, vvzvlad said:

I would still be able to set up a relocation mechanism so that new files are quickly written/read from the SSD that is available in the cache-pool, but then, overnight, moved to the storage-pool consisting of two large HDD? 

That is available by default, it's how the "cache" pool was developed to begin with and it's still usable that way. You create a user share with cache:yes and assign which pool you want to receive writes, and when the mover runs it moves the data from /mnt/poolname/sharename to /mnt/disk1/sharename, and the data is useable at /mnt/user/sharename no matter where the actual data resides.