Disk Storage Configuration Help

[meketone]

Hi.  I'm building my first NAS server and I have a question about how I setup my drivers.  I have a SSD as the main drive to be used for caching as I understand it.  I have three HDDs (12, 10, 10).  I will use  the system to back up multiple laptops and store data that will only exist on the NAS server (let's call this Project Data).   I'm not sure how to set this up.  Do I set this up as:

 

Drive 1 (12): Parity Drive in pool

Drive 2 (10): 2nd pool drive

Drive 3 (10): Project Data

 

I guess I would back up the Laptops to unraid (Drive 1 and 2) and back up Drive 3 to unraid.

 

Am I thinking this correctly?

[trurl]

17 minutes ago, mmkeaton said:

store data that will only exist on the NAS server

Parity is not a substitute for backups.

 

You must always have another copy of anything important and irreplaceable. 

[meketone]

BTW, I'm a novice, obviously, at this.  Maybe I'm not understanding.  If I have a separate drive (Drive 3) that stores Project Data and backup Drive 3 to the unraid pool, essentially Drive 1 & 2, then I would have two copies, one on Drive 3 and one on redundant Drives 1/2? 

Edited November 7, 2023 by mmkeaton

[dboonthego]

 

10 hours ago, mmkeaton said:

BTW, I'm a novice, obviously, at this.  Maybe I'm not understanding.  If I have a separate drive (Drive 3) that stores Project Data and backup Drive 3 to the unraid pool, essentially Drive 1 & 2, then I would have two copies, one on Drive 3 and one on redundant Drives 1/2? 

 

You're better off writing to the array first (drives 1 & 2)(technically parity and data disk1) and then backing up to project data (disk3).  Disk3 would be outisde the array and therefore unprotected. Doing it the other way would mean new files would be susceptible to data loss until disk3 is backed up to array.  Keep in mind your backup is still in the same physical system.  Consider storing backups off-site also.

 

A single parity disk provides fault tollerance due to physical disk failure of up to one disk at a time.  From user perspective, this allows the system to operate normally until a replacement disk can be installed and rebuilt.

 

As said, parity is not a backup.  It won't save you from theft, disasters, filesystem corruption, or accidental mistakes like writing a script to move thousands of files and forgetting the trailing slash/ in the destination.  Yeah, I did that and it wasn't fun.  Luckily I had good backups.

 

Parity protection has performance overhead because every array write must also be written to parity.  Using a cache disk allows you to initially write to the cache disk at faster speeds.  Those files will be moved to the array off hours through a mover script.  Dockers and virtual machines are also typically strictly stored on cache.  You can add a 2nd cache disk for redundancy.  You mentioned cache as main disk.  Not sure what you meant by that.

 

 

[meketone]

dboonthego, thank you for your response, it is very helpful.  Sorry you had the trailing slash/ experience.

 

I have a 2 tb ssd (main disk) that I would use as the cache disk (a Pool disk?).  I will create some docker containers for home automation, and from what you said, I should install them on the cache disk. 

 

I'll correct the naming of the disk configuration.  Is this right?

 

HDD 1 (12tb): Array Parity Disk

HDD 2 (10tb): Array Non-parity Disk

HDD 3 (10 tb):  Project Data Disk

SSD 1 (2 tb): Cache disk

 

I presume there is a process for "backing up" the Project Data.  Would that be a move script?

Edited November 8, 2023 by mmkeaton

[trurl]

On 11/8/2023 at 11:45 AM, meketone said:

correct the naming of the disk configuration

That is what confused me earlier.

 

Better way to specify disks is by their assignment. Don't use numbers at all except when specifying the assigned slots in the parity array.

 

Parity is called parity, or you could even call it disk0. This seems to be what you mean by HDD 1.

 

The first data disk in the parity array is disk1. This seems to be what you mean by HDD 2. Just call it disk1.

 

Still unclear what you mean by HDD3. Sounds like you mean it is not assigned at all. In that case, it would be an Unassigned Disk, which you could access with the Unassigned Devices plugin to copy its data to the array. Could even be a disk on another system.

 

I guess you mean SSD 1 to be the first (and only) disk in a pool named 'cache'. Just call it 'cache'.

 

[dboonthego]

On 11/8/2023 at 8:45 AM, meketone said:

HDD 1 (12tb): Array Parity Disk

HDD 2 (10tb): Array Non-parity Disk

HDD 3 (10 tb):  Project Data Disk

SSD 1 (2 tb): Cache disk

We think we understand your layout.  In this config, it looks like you'll have an array with a 12tb parity disk and a 10tb data disk giving you a total array capacity of 10tb.  Then outside the array, you have a 2tb cache disk and a 10tb unassigned device disk (Project Data).  The unassigned device is not in the array and therefore is not covered with parity protection.  If all data here will truly be backups of stuff stored elsewhere, then this isn't a bad config.

 

On 11/8/2023 at 8:45 AM, meketone said:

I presume there is a process for "backing up" the Project Data.  Would that be a move script?

There's no built-in feature to handle backups.  Various dockers are out there that can help with this though.  Lucky backup is popular.  Getting yourself familiar with rsync will help you perform manual file operations.  

 

The mover is there to manage files between your cache and array disks according to your share settings.  You can review here:

https://docs.unraid.net/legacy/FAQ/cache-disk/#the-mover