RAID Levels in Plain Terms: Which Protects Your Data and Which Speeds It Up

RAID combines several disks into one storage unit, either to go faster, to survive a disk failure, or both. Here is the short version. RAID 0 is fast and protects nothing, so one failed disk takes the whole array with it. RAID 1 mirrors two disks, costs you half the capacity and survives one failure. RAID 5 gives you the capacity of all disks minus one and survives one failure, but writes are slower and rebuilding large disks is a genuine gamble. RAID 6 survives two failures at the cost of two disks of capacity. RAID 10 stripes across mirrors, costs half the raw capacity, and combines fast reads and writes with a quick, relatively safe rebuild. That is why CLOUD runs RAID 10 for customer data and RAID 1 for the operating system disk on every physical server. The single most important point in this article is that RAID protects you from a disk dying and nothing else. It will not save you from a deleted file, ransomware or a corrupted database, so it is never a backup. Below you will find real numbers for each level using four 4TB disks, how long rebuilds take, and the Linux commands to check an array.

The Five Levels by the Numbers

Let us use one fixed example: four disks of 4TB each, giving 16TB raw. The table shows what you actually get to use, how many disks you can lose before data is gone, and how many physical writes each application write costs (the write penalty).

Level	Minimum disks	Usable from 16TB	Disks you can lose	Write penalty
RAID 0	2	16TB (100%)	0	1
RAID 1	2	4TB on two disks (50%)	1 of 2	2
RAID 5	3	12TB (75%)	1	4
RAID 6	4	8TB (50%)	2	6
RAID 10	4	8TB (50%)	1 guaranteed, 2 if they sit in different mirrors	2

The write penalty deserves attention. In RAID 5 every small write means reading the old data and the old parity, then writing both back, so four operations instead of one. If a single disk delivers 200 random write IOPS, four disks in RAID 5 give you roughly 200 write IOPS in total, while RAID 10 gives you about 400. A database writing thousands of small rows per minute feels that difference directly in query latency.

RAID 0: Speed Without a Safety Net

RAID 0 spreads data across every disk in turn, so you get the sum of their speed and capacity. The catch is that risk multiplies with every disk you add. If one disk has a 2% chance of failing in a year, the chance that any of four fails approaches 8%, and any failure means losing everything. The only sensible use is scratch data you can regenerate, such as cache files or temporary processing space.

RAID 1: The Simple Mirror

Every byte lands on two identical disks. Reads can speed up because the system reads from either side, while writes run at roughly single disk speed. Its big strength is simplicity: if one disk dies the other carries on with no calculation, and the rebuild is a straight disk to disk copy.

RAID 5 and RAID 6: Capacity at a Price

RAID 5 stores distributed parity that lets the array recalculate any missing disk, and RAID 6 adds a second parity block. RAID 5 looks attractive because it gives you 75% of raw capacity in our example, yet its weakness shows up exactly when a disk fails, which is the subject of the next section.

RAID 10: Striped Mirrors

The four disks form two mirrors, and data is striped across the two mirrors. Reads approach four disks of throughput, writes approach two, the write penalty is just 2, and a rebuild is simply a copy from the failed disk's partner.

Rebuilds: The Most Dangerous Hours in an Array's Life

When a disk fails and you insert a replacement, the array rebuilds its contents. With RAID 1 and RAID 10 that means reading one disk and copying it. With RAID 5 it means reading every remaining disk end to end and computing parity for each block, and for that entire window you have no redundancy at all. A second failure ends the array.

Consider the timing. A 16TB hard drive reads at about 150MB/s under ideal conditions, so reading it fully takes 16,000,000MB divided by 150, about 106,000 seconds or close to 30 hours. Under normal production load rebuilds slow down considerably and stretch from two to four days. Disks in the same array are usually from the same batch and the same age, and days of full load are exactly what pushes the next one over the edge.

The second, lesser known risk is the unrecoverable read error (URE). Many consumer drives are rated at one error per 10^14 bits read, which is roughly one error every 12.5TB. Rebuilding a RAID 5 of four 16TB disks requires reading 48TB from the three survivors, so hitting at least one error along the way is very likely, and some RAID controllers abort the whole rebuild on the first one. That is why RAID 5 on large disks is not something we recommend for important data today. Use RAID 6 or RAID 10 instead.

SSDs change the picture considerably. A 1TB SSD reads at around 500MB/s, so a rebuild finishes in about 35 minutes, which is one reason we pair SSDs with RAID 10 for customer data.

Why RAID 10 for Data and RAID 1 for the OS

On every physical server we separate the operating system from customer data. The OS disk is RAID 1 on two drives because it is small, mostly read, and the only requirement is that the server keeps booting if one drive dies. Cloud server data lives on RAID 10 for three reasons:

• Random writes: ERP and CRM databases write small records constantly, and a penalty of 2 instead of 4 roughly doubles write performance on the same disks.
• Short rebuilds: copying one disk from its partner instead of reading the whole array shrinks the risk window from days to minutes or a few hours.
• Stable performance while degraded: a degraded RAID 10 runs close to normal speed, while a degraded RAID 5 computes parity on every read and slows down noticeably.

Yes, RAID 10 costs half the raw capacity, but storage is far cheaper than an hour of downtime for a company system. So when you buy a CLOUD cloud server or add 100GB SSD for 500 SAR per year, the space you see is real usable space protected by RAID 10, with twice that raw capacity behind it.

Checking an Array on Linux

If you run a physical server or software RAID through mdadm, these commands give you the status in seconds:

cat /proc/mdstat
mdadm --detail /dev/md0
smartctl -a /dev/sda | grep -Ei "reallocated|pending|uncorrectable"

In /proc/mdstat look for a pattern like [UUUU]. Each U is a healthy disk, and an underscore in place of any U means a missing one. mdadm --detail shows the array state (clean or degraded) and rebuild progress if one is running. smartctl gives early warning before failure, and a reallocated sector count climbing from 0 to dozens over a few weeks is a clear signal to replace the drive.

To create a four disk RAID 10:

mdadm --create /dev/md0 --level=10 --raid-devices=4 /dev/sdb /dev/sdc /dev/sdd /dev/sde
mdadm --detail --scan >> /etc/mdadm/mdadm.conf

Do not stop at creation. Enable email alerts through the MAILADDR line in mdadm.conf, because a degraded array nobody knows about stays degraded until the second disk fails.

On a cloud VPS you will not see physical disks or need mdadm, since protection sits at the physical server level and monitoring it is our job. Understanding it still helps you judge any provider, so ask them directly which RAID level holds your data and whether the disks are SSD.

RAID Is Not a Backup, Ever

This confusion costs companies their data every year. RAID copies every write instantly to every disk, whether that write is correct or not. If a developer runs DELETE without a WHERE clause, the table disappears from both mirrors in the same millisecond. If ransomware encrypts your files, every mirror gets encrypted. If a bug writes corrupted data, RAID preserves it faithfully.

Scenario	Does RAID protect you?	Does a backup protect you?
One disk fails	Yes	Yes, with restore time
File or table deleted by mistake	No	Yes
Ransomware	No	Yes, if isolated
Update corrupts the database	No	Yes
RAID controller or whole server fails	No	Yes

The well known 3-2-1 rule still holds: three copies of your data, on two different media, with one copy off the server. For a CLOUD cloud server you can add daily backups with 7 day retention for 800 SAR per year, or 30 day retention for 2,000 SAR per year, which works out to under 5.50 SAR a day for the longer option. Managed cloud hosting includes daily, weekly and 30 day backups in every package at no extra cost.

How to Decide

1. Temporary data you can regenerate: RAID 0 is acceptable, and nothing else is.
2. An OS disk or a small two disk server: RAID 1.
3. A large, write light archive on hard drives: RAID 6, and avoid RAID 5 with disks larger than 4TB.
4. Databases, business systems and any random write workload: RAID 10 on SSD.
5. In every case without exception: an off server backup and a real restore test at least once a quarter.

If you would rather not manage disks and arrays at all, a CLOUD cloud server runs on RAID 10 SSD in Riyadh with around 8ms latency, and the entry package starts at 3,450 SAR per year including VAT. Every package and add-on is listed on the pricing page.