Getting rid of cache drive, your thoughts?

[RoboRick]

I bought two nvme pcie 2tb drives and here's my plan:

Current setup:

(4) 14TB Drives - 1 is parity, 3 data
(1) 500GB SSD Cache Drive

Future setup:

(4) 14TB Drives - 1 is parity, 3 data
(2) 2TB NVMe drives (both data)
Remove cache drive altogether

 

Using share restriction to drives I would push AppData, system, downloads, etc to the NVMe drives. Movies, etc, to the spinning disk drives.
Setup a nightly cron job to move data from downloads to their respective 14tb shares.

My goal is to have parity for the nvme drives as I bought cheap ones. today the only way to have resiliency in cache drive is a pool format but I lose half the space.

Anyone do this before? Any gotchas? Or am I headed down the wrong path?

[JonathanM]

Writes will be speed limited by the parity drive, so most of the advantage of SSD is gone if you mix them with regular spinning parity drives.

[trurl]

And SSDs in the array cannot be trimmed.

 

Since you are planning to move downloads anyway, why not just do cache pool, downloads as cache-yes, and use the CA Backup plugin to backup appdata? Docker image in system doesn't need backup since it is easily recreated. 

[RoboRick]

10 hours ago, trurl said:

And SSDs in the array cannot be trimmed.

 

Since you are planning to move downloads anyway, why not just do cache pool, downloads as cache-yes, and use the CA Backup plugin to backup appdata? Docker image in system doesn't need backup since it is easily recreated. 

I didnt think about the trim. For the Docker image, is the config for each one stored in appdata? I have been backing up the docker and libvert all this time.

[trurl]

You specify the path of the docker image when you enable docker service in Settings - Docker. The default is in the system share. There is absolutely no reason to back it up. In fact, we often recommend people delete it when they have some kinds of problems, so it can be recreated.

 

The docker image contains the executable code of all your containers, and these are easily downloaded again. The Previous Apps feature on the Apps page will reinstall your dockers just as they were.

 

Possibly what you are thinking of when you say "config" is the mappings and other things on the Add/Edit Container page. These are saved in a template on the flash drive when you create/edit a container, and these templates can be reused by simply selecting the template on the Add Container page, or more simply, by using the Previous Apps feature previously mentioned.

 

So, a current backup of flash is also important. It is especially important to have a flash backup with the current disk assignments. You can download a zipped backup of flash at any time by going to Main - Boot Device - Flash - Flash Backup. Or you can schedule an automatic backup of flash with CA Backup.

 

It seems like all the reasons you are considering removing cache has better solutions. And letting Unraid manage cache as part of user shares is much simpler.

[RoboRick]

10 minutes ago, trurl said:

You specify the path of the docker image when you enable docker service in Settings - Docker. The default is in the system share. There is absolutely no reason to back it up. In fact, we often recommend people delete it when they have some kinds of problems, so it can be recreated.

 

The docker image contains the executable code of all your containers, and these are easily downloaded again. The Previous Apps feature on the Apps page will reinstall your dockers just as they were.

 

Possibly what you are thinking of when you say "config" is the mappings and other things on the Add/Edit Container page. These are saved in a template on the flash drive when you create/edit a container, and these templates can be reused by simply selecting the template on the Add Container page, or more simply, by using the Previous Apps feature previously mentioned.

 

So, a current backup of flash is also important. It is especially important to have a flash backup with the current disk assignments. You can download a zipped backup of flash at any time by going to Main - Boot Device - Flash - Flash Backup. Or you can schedule an automatic backup of flash with CA Backup.

 

It seems like all the reasons you are considering removing cache has better solutions. And letting Unraid manage cache as part of user shares is much simpler.

Thank you sir. this makes sense and i use the CA backup tool to back everything up, including the docker image. I will remove that as i just tested what you said and it works well. Do i need to backup the libvirt file or is that file an easy recovery as well. The goal was to have a larger faster data area(4tb) with resiliency. The 2tb drives arent cheap. I guess I have to mirror for now and wait for drive prices to go down.

[RoboRick]

Is there an option/plugin in unraid to sync data immediately between cache and spinning disk? Would rsync work? I use it to sync my duplicati backups to a cloud spot. If so i would stripe the cache to get my 4tb on nvme, then a duiplicate set of data is sitting on spinning disk. 

[hugenbdd]

Check out this thread.  He moves files from array to cache, and then cleans up cache himself.  Files are in both locations.  However, You will be ignoring unraids built in mover.  And I don't think this is best practice and you may run into issues.

 

 

If you back your content up to cloud, then you can span the 2TB cache drives to 4TB as you have a backup in the cloud.  And use CA Backup plug-in to backup appdata/dockers.  Just be ready to restore from the plug-in if you lose a cache drive.