RAID 1 and RAID 10 both rely on mirroring: every block exists on two drives. They differ in how many drives they need and how data is spread across them. On a dedicated server the choice depends first on the drive count, then on how write-heavy your application is.
| Criterion | RAID 1 | RAID 10 |
|---|---|---|
| Minimum drives | 2 | 4, in the classic 1+0 layout |
| Usable capacity | One drive, i.e. 50 % | Half of the total, i.e. 50 % |
| Example on 4hosting drives | 2 × 1.92 TB → 1.92 TB usable | 4 × 3.84 TB → 7.68 TB usable |
| Drives that can fail | 1 of 2 | 1 per pair, up to 2 of 4 |
| Reads | Can read from both drives | Can read from all 4 |
| Writes | Speed of a single drive | Split across 2 mirrors |
| Rebuild | Copies the whole surviving drive | Copies only from the affected pair |
| Matching 4hosting plans | All dedicated plans with 2 drives | Only SD Intel 32/256, with 4 drives |
| Replaces a backup | No | No |
RAID 1 writes the same data to two drives, and usable capacity equals that of the smallest drive, according to Red Hat's documentation. Lose one drive and the server keeps running. Classic RAID 10 groups four drives into two mirrors and stripes data across them, so usable capacity is still half of the total. The array survives two failures only when the failed drives sit in different pairs. The Linux md driver also accepts RAID 10 on two or three drives with other layouts, but on two drives the redundancy equals RAID 1.
On reads, both levels can serve data from several drives at once. On writes, RAID 1 runs at the speed of a single drive, since every block goes to both, while RAID 10 spreads writes across two mirrors and so wins on write-heavy databases. A rebuild copies data onto the new drive and takes time proportional to drive capacity. According to the md(4) page, resynchronisation runs in the background and the array stays usable, possibly at reduced performance. A write-intent bitmap shortens resynchronisation after an unclean shutdown.
Software RAID implements the RAID levels inside the Linux kernel through the md driver and is managed with mdadm. It needs no dedicated controller, and the drives can be moved to another Linux server. A hardware controller has its own chip and, on some models, a battery-backed cache. The catch is that if the controller fails, you need a compatible model to read the drives. For NVMe drives, software RAID with mdadm is a common and well-documented choice.
An ERP with a few dozen users reads a lot and writes moderately. SD AMD 16/128, with two 1.92 TB drives, is mirrored in RAID 1: the server survives the loss of one drive, and the team adds a daily backup stored outside the machine.
A platform that ingests data continuously needs a large volume and fast writes. SD Intel 32/256 has four 3.84 TB drives, and RAID 10 gives 7.68 TB usable, double what a RAID 1 pair of the same drives offers, with writes spread across two mirrors.
The Linux md driver technically accepts RAID 10 on 2 drives, with special layouts. Redundancy stays the same as RAID 1, though: only one drive can fail. The real advantage of RAID 10, two mirrors with data spread across them, appears from 4 drives.
The time grows with drive capacity and with the load on the server during the rebuild. On RAID 1 the whole surviving drive is copied. On RAID 10 only the affected pair is copied, so the other drives stay free to serve traffic.
RAID copies every change to all drives instantly. An accidental deletion, ransomware or a corrupt update reaches the copy just as fast. A backup keeps older versions, separate from the server, and lets you return to a known good state.
RAID 1 suits two-drive servers; on four equal drives RAID 10 doubles usable capacity and write speed, with the same protection per pair.
