Setting Up RAID Arrays (mdadm) for Server Disks

A disk failure never happens on schedule. It usually occurs on a Friday evening when there is no RAID on the server and data hasn't been backed up for a week. Our engineers encounter this regularly: a panicked client calls, and within an hour we rebuild the array and restore access. mdadm is the standard tool for software RAID on Linux, and with proper configuration it runs for years without intervention. We guarantee a correct configuration that will survive a disk failure and a planned kernel update. Our experience shows that 90% of RAID problems stem from incorrect initial setup. Over 8 years of work, we have configured more than 50 RAID arrays on servers of varying complexity, including critical production environments with SLO 99.9%. Ensuring server fault tolerance starts with choosing the right RAID level and configuring it correctly.

Which RAID Level to Choose for Your Task

Before running mdadm --create, it's worth understanding what exactly needs protection. Three scenarios are most common:

RAID 1 — mirroring of two disks. Simple, reliable, no unnecessary calculations. Suitable for system partitions, small databases, and any critical data where recovery speed matters. When one disk fails, the system continues to operate without interruption.

RAID 5 — minimum three disks, one used for parity. Provides a balance between capacity and fault tolerance. Problem: during a rebuild on modern 4TB+ disks, the process takes 10–20 hours, and during this period the load on the remaining disks is maximum. If a second disk fails, the array is lost.

RAID 10 — mirror over striping. Requires at least four disks, but tolerates one disk failure in each pair. On high-load servers with heavy write activity, this is the best option. RAID 10 is at least twice as fast as RAID 5 on write operations, as shown in our benchmark testing.

RAID levels are defined by the SNIA standard

How to Create a RAID Array and Not Lose Data

Basic creation of RAID 1 from two disks:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
update-initramfs -u

Without this step, the array may not assemble automatically after a reboot. Symptoms: the system boots with a degraded array or does not see /dev/md0 at all.

Monitoring the status:

cat /proc/mdstat mdadm --detail /dev/md0 

To set up email alerts on array degradation, add the line MAILADDR [email protected] to /etc/mdadm/mdadm.conf and enable the daemon: systemctl enable mdmonitor.

Why Chunk Size Matters?

The --chunk parameter affects performance and is often overlooked during quick setup. For RAID 5/6 with three disks, a chunk of 512K provides the best balance for random reads. For RAID 10 with large sequential writes, 256K is better. Choosing the wrong chunk can reduce performance by 30%.

Partition alignment is equally important. Modern disks with 4K sectors and SSDs require the partition start to be aligned to a 1MB boundary. If the partition is created via fdisk without explicit specification, alignment is correct by default. But on older systems or with manual cylinder calculation, you can get an offset that halves performance.

How to Perform Hot Swap and Rebuild

Add a spare disk to the array for automatic replacement upon failure:

mdadm /dev/md0 --add-spare /dev/sdd 

Note: when a disk starts producing errors (S.M.A.R.T. warnings, errors in dmesg), the correct procedure is:

mdadm /dev/md0 --fail /dev/sdb mdadm /dev/md0 --remove /dev/sdb mdadm /dev/md0 --add /dev/sdb 

The rebuild will start automatically. Progress is visible in /proc/mdstat. To limit the rebuild speed and avoid I/O load on production:

echo 50000 > /proc/sys/dev/raid/speed_limit_max 

Typical Mistakes in Self-Configuration

Two points we regularly encounter during server audits:

• Missing mdadm.conf. The array is created and working, but the config is not saved. After a planned kernel update and update-initramfs, the system does not pick up the configuration. Result: the server boots into rescue mode with a panic about a missing root device.

• RAID built over partitions instead of whole disks. Technically it works, but when replacing a disk, you need to recreate the partition with exactly the same geometry. In practice, this is an extra step that gets forgotten, and the rebuild fails due to size mismatch. We recommend building RAID over whole disks (/dev/sdb, /dev/sdc), and then creating partitions inside the array.

Process of Work

We approach RAID configuration systematically:

1. Audit of current hardware and load — measure I/O profile, determine criticality.
2. Design — choose RAID level, calculate number of disks and chunk size.
3. Deployment — create the array considering your interfaces (SATA, SAS, NVMe).
4. Testing — load testing with fio, verify hot-swap failure recovery.
5. Monitoring — set up alerts via mdmonitor, Prometheus, or Zabbix.

Timeframes and Scope of Work

Cost is calculated individually after auditing the server configuration and availability requirements. Get a consultation on choosing the optimal RAID level and setting up monitoring. Contact us — we will help you avoid degradation and downtime.