How to Set Up Software RAID with mdadm on AlmaLinux 8/9, Step-by-Step for Production

Okay, I’ll be honest — this is one of those setups that sounds scary at first but turns out to be genuinely awesome once you see it work. Software RAID with mdadm on AlmaLinux is free, it’s rock solid, and honestly it’s saved my team more times than I can count. And here’s the best part: you can simulate a dead disk, watch the array keep serving data, swap in a new drive, and the whole thing rebuilds itself. I still get a kick out of watching that happen. Let’s build something awesome today!

Here’s the thing though. Most people I talk to have never actually tested their RAID. They bought a server, someone set up RAID 1, and nobody ever checked whether it actually works. Then one day a drive dies and they realize the array was never assembled, or the config was never saved, and now the server boots to a broken /dev/md127. Sound familiar? That’s exactly why I’m writing this complete software RAID setup guide for AlmaLinux — so you don’t learn it the hard way like some folks I know.

The stakes are real. A single disk failure is not some rare event — it happens, and it happens more often on drives that have been running 24/7 for a few years. Without RAID, one dead disk means your production server goes down, your website goes down, your orders stop, and your phone starts ringing. With RAID 1 or RAID 5, the server keeps humming along even when a drive fails, because the data is still readable from the surviving disk. That’s the whole point: uptime goes up, data loss risk goes down, and you actually get to sleep at night.

Now, before we get our hands dirty, you need to pick the right RAID level, because choosing wrong is a mistake you’ll feel for a long time. RAID 0 is just striping — zero redundancy, so if one drive dies, every single byte on the array is gone. RAID 1 mirrors data onto two drives at once, so one drive can die and you’re still fine. RAID 5 stripes with parity across at least 3 drives, giving you more usable space, but rebuilds take a while. RAID 6 is RAID 5’s bigger sibling that survives two dead drives. Simple enough, right?

In my experience, RAID 1 is the go-to for critical web and database servers, while RAID 5 or 6 is what you pick for bulk storage with many disks. This guide walks through RAID 1 with two empty drives, because it’s the most common setup and the easiest to follow. The commands are almost identical for other levels anyway — you just change the level number and the drive list. Alright, enough talk, let’s get to the fun part: building the array.

Think of RAID 1 like carrying a spare umbrella. You carry two identical umbrellas; if one snaps in a storm, you still end up with a dry shoulder. The array writes the same data to both drives, so when one fails, the other holds a complete copy. Simple logic, and on AlmaLinux it’s just a handful of commands away.

1. Identify Your Drives First

Step one, and please don’t skip this: make absolutely sure the drives you’re about to use for the array are empty. Creating the RAID will wipe everything on them. Check what the system sees first:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

Expected output on a server with the system drive plus two blank drives:

NAME            SIZE TYPE  FSTYPE MOUNTPOINT
sda              100G disk  ext4   /
sdb               40G disk
sdc               40G disk

Here /dev/sdb and /dev/sdc are the two blank drives that’ll form our RAID 1. /dev/sda is the system drive running AlmaLinux — hands off! If you’re ever unsure which drive is which, double-check with the by-id symlinks:

ls -l /dev/disk/by-id/ | grep -E "sdb|sdc"

Verify before you proceed. Wrong drive means gone data, and there’s no undo button on a wiped disk.

2. Install mdadm

mdadm usually ships with AlmaLinux, but make sure it’s present and up to date:

dnf install -y mdadm
mdadm --version

Expected output: mdadm – v4.2 – 2021-12-30. If you see a version, you’re good to go.

3. Create RAID Partitions on Both Drives

Each drive needs a partition flagged as Linux RAID. On AlmaLinux 9, GPT partitions with the raid flag are the modern, safe way to go. Run these commands on each drive, swapping /dev/sdb for /dev/sdc on the second one:

parted /dev/sdb mklabel gpt
parted /dev/sdb mkpart primary 1MiB 100%
parted /dev/sdb set 1 raid on

Repeat the same for /dev/sdc. Then verify:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

You should see /dev/sdb1 and /dev/sdc1 with the part type. Both present? Great, let’s build the array.

4. Create the RAID Array

This is the big moment. The command below builds a RAID 1 array from the two partitions:

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

mdadm will ask for confirmation with Continue creating array? Type y and hit enter. Creating the array is fast, but the data resync runs in the background. Watch it:

cat /proc/mdstat

Output should look like:

Personalities : [raid1]
md0 : active raid1 sdc1[1] sdb1[0]
      41937920 blocks super 1.2 [2/2] [UU]
      [=================>...] resync = 45.2% (19000000/41937920) finish=4.2min speed=100000K/sec

Stop right here. Do NOT continue until resync hits 100%. On a 1TB RAID 1, this can take a few hours. If you’re forced to reboot mid-resync, no panic — mdadm picks up where it left off automatically.

5. Save the Array Config

You must save the array configuration so it assembles automatically at boot. Skip this and after a reboot your array shows up as /dev/md127 or doesn’t assemble at all:

mdadm --detail --scan >> /etc/mdadm.conf

Then rebuild your initramfs so the array config makes it into the boot image:

dracut --force

Check /etc/mdadm.conf to confirm the ARRAY entry is there:

cat /etc/mdadm.conf

Expected output:

MAILADDR root@localhost
ARRAY /dev/md0 metadata=1.2 name=server-01:0 UUID=9c8f1a3b:2d4e:5f6a:7b8c:9d0e:1f2a:3b4c:5d6e

6. Format, Mount, and Make It Persistent

The array is ready for a filesystem. XFS is the default on AlmaLinux and handles large files beautifully:

mkfs.xfs /dev/md0

Create a mount point and mount the array:

mkdir /data
mount /dev/md0 /data

For automatic mounting at boot, grab the array’s UUID and add it to /etc/fstab:

blkid /dev/md0

Output: /dev/md0: UUID=”xxxx-xxxx” TYPE=”xfs”. Then add this line to /etc/fstab, using your actual UUID:

UUID=xxxx-xxxx  /data  xfs  defaults,noatime  0 0

Test the fstab entry before rebooting:

mount -a
df -h /data

7. Verify the Array Is Healthy

Everything’s in place. Time to confirm the array is genuinely healthy:

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

Check the State field in the mdadm –detail output — it should read active. And both drives must be listed as active sync. If anything shows up degraded, something’s wrong with one of the drives.

8. Simulate a Drive Failure and Rebuild

This is the part everyone skips, and honestly it’s the most important. You need to know what happens when a drive dies, before it actually dies — not when your phone is blowing up at 3 AM.

To simulate a dead drive, mark one partition as failed:

mdadm --fail /dev/md0 /dev/sdb1

Check the array state — it should now show degraded:

cat /proc/mdstat

Output becomes:

md0 : active raid1 sdc1[1] sdb1[0](F)
      41937920 blocks super 1.2 [2/1] [_U]
      ...

The F means the drive is marked failed, and [2/1] means only 1 of 2 drives is active. The array keeps serving data — that’s the magic of RAID. Now pull the failed drive out:

mdadm --remove /dev/md0 /dev/sdb1

Swap in the new physical drive, partition it as in step 3, and add it back to the array:

mdadm --add /dev/md0 /dev/sdb1

mdadm kicks off the rebuild automatically. Watch the progress:

cat /proc/mdstat

During rebuild, I/O load goes up and performance dips. Totally normal. Whatever you do, don’t reboot the server mid-rebuild unless it’s an emergency.

Common Troubleshooting

Here’s a quick reference if things go sideways:

Symptom	Likely Cause	Fix
/dev/md0 missing after boot	mdadm.conf not saved or initramfs not rebuilt	Redo step 5, run dracut –force, reboot
Array shows up as /dev/md127	Default incremental assembly with no named config	Add the ARRAY line with the UUID from mdadm –detail to mdadm.conf
Resync stuck at one percentage	Heavy I/O competing with the resync	Let it run, or check with iostat for a bottleneck
Healthy drive marked failed	Loose SATA cable or an undetected SMART error	Check with smartctl, reseat cables, re-add the drive
dnf can’t find the mdadm package	BaseOS or AppStream repo disabled	Run dnf repolist and re-enable the repos

Pro Tips and Warnings

Set up monitoring so you actually know when the array goes degraded — mdadm can email you through MAILADDR in /etc/mdadm.conf, or you can hook an agent like Netdata or Zabbix for real-time alerts. And please hear me on this: RAID protects against hardware failure, it does not protect against you. Fire, theft, or one bad rm -rf command will still destroy data even on a perfectly healthy RAID. Backup is not optional.

For a proper backup strategy, check out our 3-2-1 backup strategy guide. To catch failures earlier, read how to monitor your server with Netdata. If you want more flexibility with partitions later, our LVM guide pairs perfectly with mdadm. And when you’re done, don’t skip AlmaLinux server hardening before going live.

FAQ

That’s it — your complete guide to software RAID on AlmaLinux. Before you close this page, run through this checklist: 1) is /etc/mdadm.conf saved correctly, 2) did mount -a succeed with your fstab entry, 3) is your backup still running even though RAID is active? All three checked? Then your setup is genuinely production-ready. Try it on a test box first if you’re nervous, so the real server doesn’t have to be your first rodeo. Have fun, and go kill a drive in simulation — it’s weirdly satisfying!