Realistically all important data should have backups.  This is all well and good, but backups get out of date, this is where RAID comes in.  RAID puts one or more disk into an active mirroring of the data so, in the event of a disk failure, no data is actually lost.  You can read more information on RAID at wikipedia.

There are really two types of RAID sets to consider in server environments  RAID 1+0 and RAID 5.  RAID 0+1 is never to be considered, if a single disk is lost the entire RAID set is in peril - regardless of how many disks are available.  RAID 1+0 uses the same number of disks for essentially identical performance, but without this problem.

RAID 5 is very fast for block level reads and relatively quick for block level writes.   It sufferers a mathematical bottleneck with the parity.  Every block has parity information on it.  This parity information will allow the block to be rebuilt in the event that the original data goes missing or bad.  Reads and writes automatically call on this parity bit for data integrity.  For non-real time operations RAID 5 offers the best performance, disk space, and protection combination.  With RAID 5 you get around 2/3 of the disk space inserted into the RAID set for data storage; the rest is consumed by the parity calculation.  RAID 5, however, is especially bad for databases.  Databases are not only real time, but also generally ignore block boundaries in writing data.  This can lead to one database commit having 10 or 12 disk writes, each of which must find, calculate parity, update the parity, and verify the parity write was successful in addition to just merely writing the data to disk.  While this may sound far fetched, I have personally seen one normal Oracle checkpoint create over a hundred scattered writes merely to rotate redo logs.

RAID 1+0 is much simpler.  Every disk has an identical copy at all times.  Each identical pair holds a percentage of every file so that the data is spread out more or less evenly.  If there were 4 identical pairs, each one would have about 25% of the data for a given file on it.  This makes reads and writes relatively fast.  The RAID set keeps track internally of what parts of what file is where.  This, however, comes at a rather high cost.  In RAID 1+0 you receive about 48% of the disk allocated to the set. Half of the disk becomes the on-line mirror and about 1% of the overall space is allocated for keeping track of what files are where.  The 1% usage is duplicated onto the second disk, so if two 100 G drives were added (200G) only about 98G would be available for usage by the RAID set.  Why would anyone want to use this instead of RAID 5?  RAID 1+0 is a real-time RAID set.  It does not have the problem RAID 5 has in verifying the data on either reads or writes.  The data is assumed accurate, that is assured by the extra disk allocated for duplication.  This skips over entirely the mathematical problems RAID 5 encounters on non-block writes.  Every database out there should only be run on RAID 1+0 and every best practice guide should say this.

There has been some mention that the new Banner server should be faster, the primary reason for this is the RAID switch.  Old Banner was on RAID 5 as advised by an off-site specialist.  The new Banner is on RAID 1+0, this one change should substantially improve the performance and, hopefully, lead to a more stable registration environment.