• Program error – the simplest case which does not depend on whether RAID is there or not.

• User error – quite common scenario.

• Crash of two disks in RAID-5 (or three in RAID-6). You might think that it is unlikely to happen. No it’s not. If high-capacity disks are used, the possibility of repeated failure considerably increases when array is rebuilding in the event of disk crash. Besides that, a banal problem with power unit could simply ‘kill’ the electronics on several disks.

• Accumulated logical errors. Where do they come from? Usually hardware RAID Controllers have cache, able considerably increase disk performance. However, if cache is not protected, then any unexpected system reboot will lead to data loss in controller cache. If reboot occurred when data simply ‘waited’ in cache, then the error occurs on the file system level. But, in case if at the moment of rebooting cache data has been written to disks, data might be written only partially. At this stage the errors occur not only at file system level but also at the level of RAID array, since it is not clear what part of stripe was successfully written and what was not. The majority of manufacturers advise consistency check to ‘catch’ such errors, but who uses them unless in trouble? You can protect yourself by having battery backup unit, flash memory capacitors or disabling write cache. The first one cost money, second – decreases performance.

• Not only controller has cache but disks do too. Disk write operations are cached. It is recommended to disable this cache, though for SATA disks and weak controllers it substantially reduces disk subsystem performance. And those who are not willing to get slow system let it remain on. What can happen? Correct, as it is mentioned above, reboot can lead to cached data loss. Even if controller thinks that array is fine, in reality, the data will be different. And if such failure occurred in the parity block, the data will be accessible until everything is fine with array. As soon as the block is used for recovery (after failure of another disk), the recovered data will be a complete ‘trash’.

• Controller interacts with disks which can ‘respond’ to its commands with different delays (for example disk tries to remap a bad sector), and controller may not wait for the answer and send the disk ‘to rest’. What happens if it is already a seconds disk in RAID-5? Correct, say good bye to data. Well, of course, disks from the compatibility lists experience such problems very seldom, but how often does the user check these notorious lists? Despite the presence of lists, unfortunately, the outcome of voting is usually based either on money or in favour of the favourite brand.
I have listed above only the most common cases. All such problems can pile up and the number of potential problems would expand like a snow ball. If at the moment of failure there is a ‘risky’ array operation taking place (for instance, adding a disk), the probability of successful recovery with own hands (I am not even talking of controller tools) rapidly nears zero chances. It is, unfortunately, what we observe quite often (from the side).

So you may say that RAID controllers are ‘evil’ and a tool for enrichment of avaricious manufacturers. So many terrifying stories have been told, so do I really need RAID at home? In which cases it makes sense to use it?

• If you need to increase the speed of disk subsystem performance (when one disk performance is not enough). IF your hobby is video processing or ‘games’ with virtual machines, why not?

• Computer is a part of home office and contains crucial commercial information. You need to protect your data before it is backed up.

• Can’t spare time to reinstall the system in case of disk failure. Quite reasonable, especially if computer is not a test range and weekly Windows re-installation is not due on every Sunday 

• You keep huge volumes of data in on-line mode and you do not wish to recover it in case of disk failure.

Things you need to remember when you decided to make life easier with RAID?

1. Using any RAID, installation of BBU, disabling caches, regular checking – nothing guarantees data security and integrity, unless you have a reliable backup copy.
2. Copies of important data shall be kept on separate storage devices and it is highly advised that one of such devices is not rewritable.
Below you will find several tips in case you still don’t care about said above and decided to go your own way:
1. When creating RAID array note down all settings (disk order, size of stripe etc.). Note down even if you accepted all defaults. Actual meaning of default may vary for different firmware versions of hardware controller. It goes without saying that you should not keep this data on the array – spare a sheet of paper.
2. Regularly update drivers and firmware. Although it doesn’t mean that you have to install a new firmware version on the day it is released. If you don’t have problems, wait a week or two. There is always a chance that it contains some problems or defects and will be soon replaced.
3. Use all available monitoring tools. If you found out about failure not from an email message but from the fact that system doesn’t boot, usually it means that it is too late to rescue anything.
4. Perform regular data integrity verification.
5. Copy at least the most important data to DVD disks, for example.
6. If you plan to modify the configuration of array (add disks, change RAID level and so forth), refer to point No 5 once again (or better read the entire article). In case if the modification was successful, recollect point No 1 and make relevant notes.
7. Do not choose disks for hardware controller on the basis of price and general brand impression, choose them from compatibility lists of the given controller.
8. If anything got broken, first of all copy the crucial data and only then try to mend the problem.

9. If something’s got broken in a way that data is not accessible any more, refrain from any actions and call professionals.

Finding professionals is not difficult nowadays – even if you are far from the city, you can mail or talk via phone. Trust me, mailing expenses would bleak on the background of recovery cost. If it is possible, make sector by sector copy of all disks and experiment on those.

All of the above will not save you from data loss, although it will help to substantially reduce the risk of loss and is likely to reduce the cost of recovery (should the ‘X’ time come). Once again: be ready to trust the recovery job to specialized organization. Do not wonder if the cost of recovery would be times higher than the cost of controller and disks put together. If you can’t bear such expenses, think once again about backing up the data you do not want to loose. So wash your hands with soap and put sugar in your tea.