Software RAID on Linux with mdadm

By Kokil Thapa | Last reviewed: September 2026

When a single disk fails on a production server, everything on that volume can vanish unless you planned for redundancy. Software RAID on Linux with mdadm solves that problem without a dedicated RAID card. The kernel's Multiple Device (MD) driver mirrors or stripes block devices, and mdadm creates, monitors, and repairs those arrays. I've relied on this stack on Ubuntu servers that host Linux system administration workloads for Laravel apps, MySQL databases, and nightly backup volumes. This guide walks through RAID levels, setup commands, monitoring, disk replacement, and the mistakes that cause painful recoveries.

What is software RAID on Linux with mdadm?

Software RAID runs entirely in the Linux kernel and user-space tools. Hardware RAID offloads parity and mirroring to a controller with its own firmware and often proprietary management. Software RAID uses CPU cycles instead, but it costs nothing beyond the disks themselves and works on any server—from a VPS with extra volumes to bare-metal EC2 instances I maintain for production booking platforms.

The mdadm package (current stable releases ship version 4.x on Ubuntu 24.04 LTS) manages MD devices exposed as /dev/md0, /dev/md1, and so on. Each MD device is a virtual block layer sitting above member partitions such as /dev/sdb1 and /dev/sdc1. File systems, LVM physical volumes, or direct mounts sit on top of the MD device.

Software RAID pairs naturally with LVM for flexible disk management. A common pattern places an MD RAID 1 array beneath LVM, then creates logical volumes for /, /var, and database storage. That separation lets you resize volumes without rebuilding the underlying mirror.

Software RAID vs hardware RAID

For most small and mid-size web servers I operate, software RAID on Linux with mdadm is the practical default. Hardware RAID earns its place when you need battery-backed write cache and sub-millisecond latency guarantees on heavy database workloads.

Which RAID level should you choose for a Linux server?

Choosing the wrong RAID level is a common mistake. RAID 0 stripes data for speed but offers zero redundancy—lose one disk and you lose everything. RAID 1 mirrors two disks; you keep half the raw capacity but survive a single failure. RAID 5 stripes with distributed parity across three or more disks; you lose one disk's worth of capacity and tolerate one failure. RAID 6 adds a second parity block and tolerates two simultaneous failures. RAID 10 (1+0) mirrors then stripes pairs; it needs at least four disks and delivers strong read performance with one-disk fault tolerance per mirror pair.

On production Laravel hosts I maintain, RAID 1 on two NVMe drives covers the operating system and application code. Database data either sits on a separate RAID 10 set or on cloud block storage with its own redundancy. RAID 5 makes sense for bulk backup storage where cost per terabyte matters more than write latency.

• RAID 1: Two disks, 50% usable capacity, simplest recovery path.
• RAID 5: Three or more disks, good read speed, slow rebuilds on large drives.
• RAID 6: Safer during rebuild windows when another disk might fail.
• RAID 10: Best random I/O for databases; needs four disks minimum.

Match your RAID choice to recovery time objectives. A 4 TB RAID 5 rebuild can take many hours. During that window the array runs in degraded mode. Plan automated database backups on Linux regardless of RAID level—RAID is not a backup strategy.

How do you create a RAID array with mdadm on Ubuntu?

Start with identical disk sizes when possible. Mixed capacities work, but the array sizes itself to the smallest member. Use GPT partition tables and mark RAID partitions with type FD (Linux RAID) so tools recognise them instantly.

Install mdadm and prepare disks

sudo apt update
sudo apt install mdadm
lsblk -o NAME,SIZE,TYPE,FSTYPE
sudo parted /dev/sdb --script mklabel gpt mkpart primary 1MiB 100%
sudo parted /dev/sdc --script mklabel gpt mkpart primary 1MiB 100%
sudo parted /dev/sdb set 1 raid on
sudo parted /dev/sdc set 1 raid on

Verify partition types before proceeding. A wrong partition flag causes mdadm to reject members or GRUB to miss boot partitions. On servers where I deploy alongside domain and hosting setup, I document disk serial numbers in the runbook before touching partitions.

Create a RAID 1 mirror array

sudo mdadm --create /dev/md0 \
  --level=1 \
  --raid-devices=2 \
  /dev/sdb1 /dev/sdc1

cat /proc/mdstat
sudo mkfs.ext4 /dev/md0
sudo mkdir -p /mnt/raid
sudo mount /dev/md0 /mnt/raid

The --create command writes superblock metadata to each member. That metadata lets mdadm reassemble the array after reboot. Without saving the array definition, your server may boot with degraded or missing arrays.

Persist the array across reboots

1. Capture the array layout: sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
2. Update the initramfs so early boot can assemble RAID: sudo update-initramfs -u
3. Add a /etc/fstab entry using the MD UUID, not /dev/md0
4. Test with a controlled reboot during a maintenance window

sudo blkid /dev/md0
# Add to /etc/fstab:
# UUID=abc123-def456  /data  ext4  defaults,nofail  0  2

Using UUIDs in fstab prevents mount failures when device names shift after adding disks. This behaviour mirrors the guidance in articles on Linux file permissions and ACLs—predictable, explicit configuration beats assumptions about device order.

Create RAID 5 for bulk storage

sudo mdadm --create /dev/md1 \
  --level=5 \
  --raid-devices=4 \
  /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdg1

RAID 5 creation triggers an initial parity calculation. Monitor progress with watch cat /proc/mdstat. Heavy I/O during sync slows the process. Schedule creation during low-traffic hours and read about log rotation and disk space management before filling the array with application logs.

How do you monitor and recover a failed mdadm RAID disk?

Monitoring is where many teams fail. They build the array once and forget it until a disk dies at 2 AM. Set up proactive alerts before that happens.

Check array health

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo smartctl -a /dev/sdb

The State line in mdadm --detail output should read clean. A degraded state means a member is missing or failed. The Rebuild Status section shows progress when a replacement disk is syncing. Integrate these checks into your existing Linux server monitoring with Netdata and alerts pipeline, or schedule them via cron jobs.

Replace a failed disk

1. Identify the failed member: sudo mdadm --detail /dev/md0
2. Mark it failed if not already: sudo mdadm --manage /dev/md0 --fail /dev/sdb1
3. Remove it from the array: sudo mdadm --manage /dev/md0 --remove /dev/sdb1
4. Physically replace the disk, partition the new drive identically
5. Add the new member: sudo mdadm --manage /dev/md0 --add /dev/sdb1
6. Watch rebuild: watch cat /proc/mdstat

During rebuild the array operates in degraded mode. Another disk failure on RAID 1 means total data loss. On RAID 5, a second failure during rebuild destroys the array. Replace failed disks immediately. Keep hot spares only if your hardware supports automatic insertion.

Email alerts from mdadm ship via the MAILADDR directive in /etc/mdadm/mdadm.conf. On modern systems I prefer hooking into systemd-managed monitoring services that page on SMART errors before the disk fully dies. Predictive failure beats emergency rebuilds every time.

Simulate failure safely in staging

sudo mdadm --manage /dev/md0 --fail /dev/sdc1 --remove /dev/sdc1
sudo mdadm --manage /dev/md0 --add /dev/sdc1

Never run failure simulation on production without a verified backup and a maintenance window. Document every step in your runbook. Teams that practice recovery in staging fix real incidents in minutes instead of hours.

How do you boot Linux from a software RAID array?

Booting from software RAID on Linux with mdadm adds complexity because GRUB and the initramfs must understand MD devices. Ubuntu and Debian handle most cases automatically when you install with RAID selected in the installer. Manual setups need extra care.

Separate /boot for RAID 1

GRUB historically struggled with RAID 5 and RAID 6 boot partitions. The safe pattern mirrors both /boot and root on RAID 1 while keeping /boot on a small ext4 partition. Install GRUB to both member disks:

sudo grub-install /dev/sdb
sudo grub-install /dev/sdc
sudo update-grub

If the primary boot disk fails, the BIOS or UEFI firmware can boot from the secondary disk. Verify both disks appear in your firmware boot order. On sister sites I maintain with Deployer 7 pipelines, boot-disk documentation lives next to deployment notes so any engineer can recover without guessing.

Initramfs requirements

The initramfs must include mdadm, required kernel modules, and the assembled array definition. After any change to RAID layout, always run:

sudo update-initramfs -u

A missing or stale initramfs produces the dreaded busybox shell on boot. The kernel cannot find the root file system because the MD array never assembled. Keep a rescue ISO or serial console access available before your first RAID boot test.

Reference the official kernel documentation at docs.kernel.org/admin-guide/md.html for MD driver internals. The Debian wiki RAID page at wiki.debian.org/RAID covers distribution-specific installer paths. Ubuntu's mdadm man page remains the authoritative command reference.

Grow an existing array

When you add disks to expand capacity, mdadm supports growing certain levels online. For RAID 1, add a member then grow:

sudo mdadm --manage /dev/md0 --add /dev/sdd1
sudo mdadm --grow /dev/md0 --raid-devices=3
sudo resize2fs /dev/md0

Back up before any grow operation. Growing triggers a resync that stresses all member disks. Combine this with Linux performance tuning with sysctl if I/O contention affects application response times during the sync.

Key Takeaways

• Software RAID on Linux with mdadm provides disk redundancy without proprietary hardware—ideal for budget servers and cloud VMs.
• Choose RAID 1 or RAID 10 for boot and database volumes; use RAID 5 for bulk backup storage where cost per terabyte matters.
• Always save /etc/mdadm/mdadm.conf and run update-initramfs -u before rebooting a new array.
• Monitor /proc/mdstat and SMART data proactively—RAID protects against disk failure, not data corruption or accidental deletion.
• Practice disk replacement in staging so production recovery takes minutes, not hours.
• Keep independent backups via tools and scripts described in your support and maintenance runbooks.

People Also Ask

Can you use software RAID on Linux with mdadm in the cloud?

Yes. AWS, DigitalOcean, and other providers attach multiple block volumes to a single VM. Partition each volume, create an mdadm array, and mount it like bare metal. The redundancy protects against single-volume failure, not availability-zone outages. Combine RAID with cross-zone backups for full coverage.

Does mdadm work with SSD and NVMe drives?

mdadm works with any block device, including NVMe namespaces and SSDs. Enable periodic TRIM on SSD-backed arrays with fstrim scheduled via systemd timer or cron. Monitor wear indicators through SMART attributes. RAID 10 on NVMe delivers excellent random I/O for MySQL and PostgreSQL workloads.

What happens if you forget to update mdadm.conf?

The array may fail to assemble at boot. The kernel sees member partitions with RAID superblocks but lacks the assembly rules. You land in initramfs recovery or face an unbootable system. Boot from rescue media, run mdadm --assemble --scan, fix the config, update initramfs, and reboot.

Is software RAID slower than hardware RAID?

For RAID 1 and RAID 10 on modern CPUs, the difference is often negligible for web workloads. RAID 5 and RAID 6 parity calculation consumes CPU cycles that a hardware controller offloads. On a typical Laravel or WordPress server, network and database query time dominate latency—not MD driver overhead.

Build reliable storage into your server architecture

Software RAID on Linux with mdadm is a proven, portable way to keep production data available when disks fail. The setup takes an afternoon. The payoff lasts years—if you monitor arrays, persist configuration correctly, and maintain backups independent of RAID. I've seen unmonitored mirrors fail silently until the second disk died and took the business offline.

If you need help designing storage for a new deployment or recovering a degraded array on an existing server, review the Linux system administration services I offer or browse the production server portfolio for examples of maintained infrastructure. For quick server-side calculations during planning, the password generator and other online tools sit alongside deeper guides on diagnosing high CPU and memory usage and essential Ubuntu commands. Contact us to discuss RAID planning for your next enterprise application deployment.