Enable write back cache on RAID 5 good idea or bad idea

I just installed Intel Rapid Storage Technology and can now see what the heck I have been missing all this time. Wow.  Server has been running with no way to monitor the condition of the drives.  Now that I have this Intel utility running, the first question that comes to mind, if I enable the volume write back cache, is that good, bad? What is typically done?  This server has been running with that off, so I am thinking it will improve our wait time on SQL queries?  It is connected to a UPS with about a 2 hour run time, so I don't think power interruption is an issue. Any other considerations before I decide to turn it on?
Who is Participating?
DavidConnect With a Mentor PresidentCommented:
don't ennable it on that lowend raid.  too risky for data integrity, it has nothing to do with a ups. issue is how it handles timeouts and retries.
Mohammed RahmanConnect With a Mentor Commented:
Can have a look at the article below. It explains what exactly the RAID CACHING is. Also, it highlights pros and cons of it.

rodynetworkAuthor Commented:
Our server supports 4 people on a LAN. We use Exchange for email and our desktops use an app that is interfaced via Internet Explorer and it uses SQL database queries all day.  I am wondering what part of cache enabling might cause data loss/corruption. Is it simply the functioning of the RAID, or is it the new data being written, or is it the read only that causes a problem? Is it possible to only enable read cache and not write cache (is that even feasible?) maybe that would eliminate the risk?  Our biggest time lag right now is simply having to wait on SQL queries to make certain pages display all the already written/stored data. If we could turn on the read aspect of the cache, maybe that would speed things up?
WEBINAR: GDPR Implemented - Tips & Lessons Learned

Join the WatchGuard team on Thursday, March 29th as we recount some valuable lessons learned in weighing the needs of a business against the new regulatory environment, look ahead at the two months left before implementation, and help you understand the steps you can take today!

Mohammed RahmanConnect With a Mentor Commented:
Write-back Cache:
As per the article, whenever the data is recieved from X source to be written on RAID, the data is written on the cache and not on the actual disk. The cache then sends acknowledgement to the X source that the data was written on the disk. However, the data is still on the cache and not on the disk. Cache will take its sweet time to write the data to the disk (as per my inderstanding from the article).

The time required to flush the data from the cache to the actual disk may depend on the amount of data to be flushed onto the disk and the controller (hardware) used. Better the hardware, better the performance.

W have a backup of 2 hours through USP. All we should calculate is the following below:

Amount of data that the cache can handle. (can write on itself before flushing it to he actual disk)
Time taken by the controller to flush entire data from cache to the disk.

If the time taken above exceeds the 2 hours, we may either plan to drop the write-back cache OR increase the backup time.

Write-Thru Mode.

This mode does not utilize the RAID cache for accelerating write I/O requests. In most cases it will be slower than Write-Back mode.
Hence, selecting Write-back over Write-thru will be a good deal (provided, we have a proper electricity backup).

I am wondering what part of cache enabling might cause data loss/corruption? (Looks like the Write Back will result in data loss and crruption in the event of power failure if the time taken by the cache to flush the data to the disk is more than 2 hours)

You can also read write-back vs write-thru and the conclusion from the article below:

** After reading all these articles, I would suggest not to turn it ON unless you are expecting drastic improvement in performance. Or, check if we can get any software to benchmark both and take a call.
DavidConnect With a Mentor PresidentCommented:
First, you could have another issue .. specifically what HDDs do you have?   But ignoring that for a moment, the RAID controller you have has issues with RAID5 and it is just a low-end controller and simply not suited for multiple error scenarios.   While the write-back/write-through information above is correct, the information does not take into consideration error recovery scenarios when you do not have a battery protected controller.

write back cache can result in data integrity/bit rot issues that make it  unsuitable for RAID5.
CallandorConnect With a Mentor Commented:
Like the others, I would advise against using a write back cache if you are not using a hardware RAID controller with battery backup.  The possibility of losing power, even with a UPS, means any data in the cache not yet written will corrupt your database, so I would urge using the most stringent precautions.  You can use a read cache with no problems, and it should be possible to enable it separately.

With only 4 users, your database query problems are probably not due to the hardware, but to the design of the queries.  You might want to ask an SQL question to get the experts their take on it and see if you can optimize them.
rodynetworkAuthor Commented:
Good input guys. Thanks for keeping me out of self inflicted trouble!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.