RAID is the thing a dedicated server gives you that a VPS does not: control over how the disks are arranged, and therefore what happens when one fails. Getting the arrangement right is a decision you make once, because changing it later usually means rebuilding the machine.
RAID is not a backup
This is the sentence worth internalising before anything else.
RAID protects against a disk failing. It does nothing about a deleted file, a corrupted database, a compromised server, ransomware, or a mistake, all of which are written faithfully to every disk in the array, instantly.
A server with mirrored disks and no backups is a server with no backups. The array survives; the data does not.
The levels worth considering
RAID 1 (mirror). Two disks holding identical data. One can fail with no loss. You get the capacity of one disk from two. Simple, fast to rebuild, and the sensible default for a two-disk server.
RAID 10 (mirrored pairs, striped). Four or more disks. Fast for both reads and writes, survives at least one failure, rebuilds quickly. This is what most database-backed servers want, and it is what Ahosting's servers use.
RAID 5 / 6 (parity). More usable capacity from the same disks, at the cost of slower writes and slow, risky rebuilds. On large modern disks a RAID 5 rebuild takes many hours under full load, and a second failure during that window loses everything.
RAID 0 (stripe). No redundancy at all. Any disk failing loses everything. It is not a redundancy level and should not be used for anything you would miss.
Choose by rebuild behaviour, not by capacity
The usual comparison is usable space, and that is the wrong axis.
What matters is what happens after a failure. A mirror rebuild copies one disk to another and finishes reasonably quickly. A parity rebuild reads every disk in the array to reconstruct the missing one, taking hours, while the array is degraded and under heavier load than normal.
That window is when second failures happen, and it is why RAID 10 is preferred over RAID 5 on anything that matters despite using more disks for the same capacity.
Hardware or software
A hardware controller handles the array itself and usually has a battery-backed cache, which helps write performance considerably.
Software RAID is managed by the operating system, costs nothing, and is genuinely fine for many workloads. It is also easier to recover, because the array is not tied to a specific controller model.
Either is defensible. What is not defensible is not knowing which you have, since they are monitored differently.
Monitoring is the part that fails
An array with a failed disk keeps working. That is the entire point, and it means nothing tells you unless something is watching.
Servers are routinely found running on a degraded array for months, one disk from total loss, because nobody set up a check. The failure was silent by design.
Set up monitoring that emails you on any change, then confirm it works by reading the array status yourself once. An unverified alert is an assumption.
When a disk fails
Confirm which one before touching anything. Pulling the wrong disk from a degraded array destroys it, and that mistake is unrecoverable.
Replace it, start the rebuild, and expect performance to be noticeably worse until it finishes. Do not run other heavy work during a rebuild if you can avoid it.
And check your backups are current before starting, because the rebuild window is the most fragile the array will ever be. There is more on what that should look like in backups and disaster recovery.
Redundant disks address the layer least likely to take the service down. Understanding Single Points of Failure in a Server Setup goes into the ones above it.
Know which tool your array speaks
Every check below depends on identifying the controller first, and the commands differ completely between them.
lspci | grep -i raid cat /proc/mdstat # software array storcli /c0 show # Broadcom / LSI megacli -LDInfo -Lall -aALL # older LSI perccli /c0 show # Dell PERC
Write the working command into your own notes when the machine is built. Discovering which utility this controller needs, and installing it, is not something to do while an array is degraded. Testing a new server walks through doing it at the right moment.
The battery is a silent performance cliff
Hardware controllers cache writes in memory, which is where much of their speed comes from. That cache is only safe while the backup battery or capacitor is healthy.
When it fails, the controller disables write caching to protect your data (correctly) and write performance collapses. The machine keeps working and becomes dramatically slower for no visible reason.
storcli /c0/bbu show all megacli -AdpBbuCmd -aALL
This is a genuinely common cause of "the server got slow and nothing changed", and it is invisible to every tool that looks at the operating system. Monitoring server health deals with the other hardware failures that behave this way.
Scrub the array on a schedule
A disk can hold a sector that fails only when read. On an array that is otherwise healthy, nobody discovers it until a rebuild tries to read it: at exactly the moment the redundancy is already gone.
A periodic consistency check reads everything and finds those sectors while there is still a second copy to recover from.
echo check > /sys/block/md0/md/sync_action # software array storcli /c0/v0 start cc
Most distributions schedule this monthly for software arrays. On a hardware controller it is a setting, and it is frequently left off. Run it during quiet hours. It is read-heavy and slows the machine while it runs.
What a rebuild actually costs
Time it once, on a new machine, so the number is known rather than guessed.
A rebuild reads every sector of every remaining disk, which takes hours on large drives and puts sustained load on disks that are the same age as the one that just failed. That is why the risk of a second failure is highest during a rebuild.
Two consequences worth planning for. Performance is noticeably worse throughout, so schedule the replacement instead of doing it during peak hours if the array is still redundant. And have the backup verified before starting, because a rebuild is the operation most likely to expose a second failing disk. Backups and disaster recovery sets out being ready for that.