contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Building a RAID Array with mdadm on RHEL

RHEL is a common base for Australian banking, logistics and government systems, from Sydney and Melbourne data centres to Perth branch offices. Local managed-service providers often use software RAID to standardise hosts while retaining operating-system control.

mdadm combines disks into a Linux MD array, adding redundancy or throughput while giving RHEL a consistent storage layer. RAID is not a backup: deleted data, controller faults and site damage still require separate copies and a tested recovery plan.

This guide covers planning, creation, mounting, monitoring and replacement. An authorised administrator should rehearse the procedure on non-critical disks, then schedule a quiet maintenance window and have a colleague check every destructive command.

Plan the array and inspect the host

First decide whether the array will hold databases, virtual machines or general application data. Record the required capacity, acceptable rebuild time and level of redundancy, then confirm that the disk controller is operating in pass-through or non-RAID mode.

Install the required tools and inventory the candidate disks:

sudo dnf install mdadm smartmontools
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
sudo mdadm --examine /dev/sdX

Replace /dev/sdX with each candidate device. Confirm that it is not mounted, does not contain data you need and has no existing RAID signature.

Select disks and use stable identities

Use disks of matching capacity and performance. Record each serial number and use the stable /dev/disk/by-id/ paths when creating the array, because /dev/sda, /dev/sdb and similar names can change after hardware changes.

ls -l /dev/disk/by-id/

If a recycled disk contains old metadata, remove its signatures only after checking the serial number against the storage inventory:

sudo wipefs -a /dev/sdX

Application lifecycles provide a useful contrast. The Android bound service tutorial shows how a component may depend on a bound client, whereas mdadm must discover and reassemble its members independently after every boot.

Create the array with mdadm

This example creates a RAID 5 array with three active disks and one hot spare. Substitute the real disk paths and confirm that every member is empty.

sudo mdadm --create /dev/md0 \
  --level=raid5 \
  --raid-devices=3 \
  --spare-devices=1 \
  --metadata=1.2 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

Metadata 1.2 is a normal choice on modern RHEL systems, but check that the firmware, boot loader and storage stack support the selected layout, especially when the root filesystem will be on the array.

Inspect the initial synchronisation and confirm that the spare is recognised:

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

Format, mount and persist the array

RHEL commonly uses XFS, although the filesystem must match the workload and existing management standards. Create the filesystem and retrieve its UUID:

sudo mkfs.xfs /dev/md0
sudo blkid /dev/md0

Add the array to /etc/fstab using the UUID rather than /dev/md0, since device names can change:

UUID=YOUR-ARRAY-UUID /data xfs defaults,noatime 0 2

Inspect the generated assembly information before appending it to /etc/mdadm.conf; avoid duplicate array entries:

sudo mdadm --detail --scan
sudo mdadm --detail --scan >> /etc/mdadm.conf
sudo systemctl enable --now mdmonitor

For a root array, regenerate the initramfs and GRUB configuration. On hosts that also serve web applications, follow configuring SELinux policies when placing content under a non-default path, because SELinux labels control access alongside Unix permissions.

Monitor, replace and rebuild failed drives

Check the array state regularly and inspect each member’s SMART data:

cat /proc/mdstat
sudo mdadm --detail /dev/md0
sudo smartctl -x /dev/sdX

When a member fails, mark it as failed before removing it. Once the replacement disk is installed and its identity is verified, add it to the array and allow the rebuild to finish:

sudo mdadm --manage /dev/md0 --fail /dev/sdc
sudo mdadm --manage /dev/md0 --remove /dev/sdc
sudo mdadm --manage /dev/md0 --add /dev/sdf

Do not remove a working disk merely because its SMART report looks suspicious. During an arvo maintenance window, Australian operations teams should coordinate alerts across UTC, AEDT and ACST, including daylight-saving changes, while the local service provider or 24/7 operations centre tracks the rebuild.

Choose RAID levels and make the handover

Select the RAID level according to capacity, performance and failure tolerance rather than by headline speed alone.

RAID level Minimum disks Usable capacity Failed-disk tolerance Typical RHEL use
RAID 0 2 100% None Temporary data or high-throughput scratch space
RAID 1 2 About 50% One disk Boot volumes and small critical datasets
RAID 5 3 N−1 disks One disk Read-heavy application storage
RAID 6 4 N−2 disks Two disks Larger arrays requiring extra write protection
RAID 10 4 for two mirror pairs About 50% One disk per pair Databases and high-write virtualisation

On RHEL, mdadm often provides the disk layer beneath LVM, allowing logical volumes or snapshots to be built on top. Record the RAID level, member identifiers, rebuild procedure and mount configuration in the system handover pack.

The practical takeaway is to keep the verified device map, mdadm.conf, filesystem configuration and tested recovery procedure together, so the array can be restored predictably after a disk or host failure.