Is the cache disk a single point of failure? Any way to overcome this?

I am toying with the idea of using a MB with a "real" hardware RAID controller onboard, and mirroring two disks for use as the cache drive.

If I write a file to the cache drive, and it fails before its copied to the array, the file is lost.  Is there a way to force (or more frequently schedule) writes to the array?

If I install third party apps on the unraid system, they must be installed on the cache drive (correct me if I am wrong).  Thus, if my USB thumb drive fails, the system dies.  If the cache drive fails and my apps and configs are lost, the system dies. 

Do I have this correct, or am I being overly cautious?

To those of you who are using sickbeard (and etc) to download additional content to your servers, what steps are you taking to back up configs, prevent failures, etc?

Thanks.

As you mentioned, could set up your cache drive with RAID disks

Apps do not have to be on cache.  I used to run SAB/SICK on unRaid before I VMed unRaid and Win7 and never had a cache drive.

You would then need to have them on an array disk ... not your flash drive, nor a mount point that isn't a physical drive....you want to ensure you are not trying to run them in RAM

From what I've read before, you can schedule the mover script for as often as you want.

I am toying with the idea of using a MB with a "real" hardware RAID controller onboard, and mirroring two disks for use as the cache drive.

 

If I write a file to the cache drive, and it fails before its copied to the array, the file is lost.  Is there a way to force (or more frequently schedule) writes to the array?

I believe the mover script is cron adjustable, so you can set it to run more/less frequently.

If I install third party apps on the unraid system, they must be installed on the cache drive (correct me if I am wrong).

You are wrong. You can run apps off your array, or run the apps themselves on the cache drive, but copy the data the apps download/manipulates directly to the array. All depends on where you point things to.

A cache drive is nice for apps however, as you can keep the frequently read/written files (like logs, or part files) on the cache so main array drives can sleep.

Thus, if my USB thumb drive fails, the system dies.  If the cache drive fails and my apps and configs are lost, the system dies. 

Depends what you mean by "system." If you USB key dies, your unRAID will not be able to boot, and any settings on it will be lost. If your cache drive fails, you lose the data that's currently on it (either a cache-only directory that never moves to the protected array, or data that hasn't yet been moved to the array from the mover script). However, your unRAID can still boot and all data on the array is still safe and accessible.

Do I have this correct, or am I being overly cautious?

 

To those of you who are using sickbeard (and etc) to download additional content to your servers, what steps are you taking to back up configs, prevent failures, etc?

 

Thanks.

I wouldn't say you're being overly cautious, but you may want to look at priorities and think about what data is re-obtainable and what is unique.

If you use a cache drive and run apps like SickBeard, SABnzbd, CouchPotato, etc., and the cache drive dies, you're going to lose the configs for those apps and any data you've downloaded that hasn't yet been moved to the protected array. However most of these apps are pretty easy to reconfigure (about 10 minutes to configure any of them from scratch),  and the data that they download can usually be redownloaded easily. A simple cron command or two could back up your various apps data to the array in a tar file periodically as well, in case of failure.

Most of the plugins that unRAID 5.0 uses for third party apps often have the app itself run in memory, but the config files get written to a location of your choice. That location could be on the protected array.

If we're talking about unique data that is not re-obtainable, say home movies, you should probably just write those directly to a disk (or invoke the mover script more often).

All that stuff above +

Might just be easiest to not use a cache drive. Cache drive is not required. Using a cache drive does introduce an additional thing to fail and your solution (mirroring) ties you to the motherboard/raid controller should that fail your two drives might not be readable elsewhere.

For things I cannot get back I have a share that does not use the cache drive. For tv shows and the like I got it once I can do it again. For app configs I back them up once I'm happy with the config or after I make any changes. The flash drive gets backed up weekly. I back up configs to my dropbox, larger files like home videos get backed up to a cloud server as well as a server I put in my parents house.

I've reinstalled Sab sickbeard and couchpotato so many times on various systems I can completely set them up from scratch in less than 10 minutes (all together) still nice to have the drag and drop backup though.

Sent from my HTC Vivid

What Influencer said - you can set up cache drive usage per share, so for anything that's absolutely critical, set the share up so it doesn't use the cache drive. 

Using a cache drive does introduce an additional thing to fail and your solution (mirroring) ties you to the motherboard/raid controller should that fail your two drives might not be readable elsewhere.

If you use hardware RAID1 (Mirror) your cache drives would be able to be accessed independently on another machine, regardless of whether one of the drives fails or the controller dies. This is one of the major benefits of RAID1. Keep in mind that you will likely have to use a controller card for this setup as most motherboard RAID controllers are software controlled and won't work with unRAID. A Mirrored cache "volume" does provide redundancy for your cache as well as a slight improvement in read speed (from your cache "volume") as the drives will also be able to be accessed independently.

I'm thinking that you're over thinking it. Set your mover script to once a day, say right after your normally go to bed, and you should have very little to worry about.

I'm thinking that you're over thinking it. Set your mover script to once a day, say right after your normally go to bed, and you should have very little to worry about.

+1

This is what I do, every morning at ~4.30am my mover is run. I do most of my copies in the evening so for 3/4 of the day my cache drive is usually empty anyway. I can afford to lose one days worth of data if it comes to that. If there is something I can't afford to lose and I don't want to risk even that small of a time frame, I either leave another copy on my desktop PC for an extra day before removing it or I copy directly to the disk shares.

Using a cache drive does introduce an additional thing to fail and your solution (mirroring) ties you to the motherboard/raid controller should that fail your two drives might not be readable elsewhere.

 

If you use hardware RAID1 (Mirror) your cache drives would be able to be accessed independently on another machine, regardless of whether one of the drives fails or the controller dies. This is one of the major benefits of RAID1. Keep in mind that you will likely have to use a controller card for this setup as most motherboard RAID controllers are software controlled and won't work with unRAID. A Mirrored cache "volume" does provide redundancy for your cache as well as a slight improvement in read speed (from your cache "volume") as the drives will also be able to be accessed independently.

Actually, moving a mirrored drive into another server does not always work. Tried many times with Dell PERC4,5,6, HP P400, etc.

Using a cache drive does introduce an additional thing to fail and your solution (mirroring) ties you to the motherboard/raid controller should that fail your two drives might not be readable elsewhere.

 

If you use hardware RAID1 (Mirror) your cache drives would be able to be accessed independently on another machine, regardless of whether one of the drives fails or the controller dies. This is one of the major benefits of RAID1. Keep in mind that you will likely have to use a controller card for this setup as most motherboard RAID controllers are software controlled and won't work with unRAID. A Mirrored cache "volume" does provide redundancy for your cache as well as a slight improvement in read speed (from your cache "volume") as the drives will also be able to be accessed independently.

 

Actually, moving a mirrored drive into another server does not always work. Tried many times with Dell PERC4,5,6, HP P400, etc.

OK well I change my statement to "more often than not." Proprietary NAS controller cards likely "do their own thing" as intended by HP/Dell etc. An off-the-shelf controller card or controller built onto a modern motherboard (provided it isn't software controlled) setup in RAID1 shouldn't have an issue being read by an external PC. Keep in mind that if a drive is removed from a mirror and accessed then returned to the array it will likely appear as "degraded" (even if no files were added/removed) and require some time to re-sync.