Creating a RAID 5 Array with mdadm on CentOS

RAID 5 combines block-level striping with distributed parity, allowing a CentOS server to keep operating after one member disk fails. It needs at least three drives and offers a practical balance between usable capacity, read performance, and redundancy.

The Linux mdadm utility manages software RAID arrays directly in the kernel. This approach avoids a dedicated hardware controller and works well for file servers, backup repositories, and small office systems in Sydney, Melbourne, or regional locations where straightforward maintenance matters.

RAID is not a substitute for backups. Accidental deletion, filesystem corruption, ransomware, and multiple disk failures can still destroy data. Before creating the array, copy important files elsewhere and confirm that the selected device names do not contain valuable information.

The commands below suit CentOS systems using common sdX device names. Replace the examples with the actual disks identified on your server, and take extra care if the machine runs from a cloud provider or a remote console in Perth, Brisbane, or another off-site location.

Check The Disks And Install mdadm

Start by inspecting storage devices and existing filesystems:

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT
sudo fdisk -l

Assume the new drives are /dev/sdb, /dev/sdc, and /dev/sdd. Remove old filesystem signatures only after verifying the names:

sudo wipefs -a /dev/sdb
sudo wipefs -a /dev/sdc
sudo wipefs -a /dev/sdd

Install the RAID management tools:

sudo yum install -y mdadm

On newer CentOS releases that use DNF, dnf install -y mdadm provides the same package. Existing disks should have matching or closely matched capacities. The array uses the size of the smallest member, so mixing a 4 TB disk with larger drives wastes the extra space.

Prepare Consistent RAID Partitions

Create a GPT partition on each disk with parted. The set 1 raid on flag marks the partition for Linux software RAID:

for disk in /dev/sdb /dev/sdc /dev/sdd; do
  sudo parted -s "$disk" mklabel gpt
  sudo parted -s "$disk" mkpart primary 1MiB 100%
  sudo parted -s "$disk" set 1 raid on
done

Check the result before proceeding:

lsblk
sudo parted -l

The expected members should be /dev/sdb1, /dev/sdc1, and /dev/sdd1. If your server uses different paths, update every later command. A naming mistake at this point can overwrite the operating system disk.

For a server located in a hot Brisbane plant room, cooling and drive airflow deserve attention during a long rebuild. RAID protects availability, but it cannot compensate for poorly ventilated hardware or unstable power.

Build And Monitor The Array

Create the RAID 5 device with three members:

sudo mdadm --create --verbose /dev/md0 \
  --level=5 \
  --raid-devices=3 \
  /dev/sdb1 /dev/sdc1 /dev/sdd1

Confirm its state:

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

The initial parity sync can take hours. Monitor /proc/mdstat regularly, especially before placing production data on the device. Avoid rebooting during the process unless necessary, and check system logs if the sync pauses or reports errors.

Save the array definition so it can assemble after a restart:

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
sudo dracut -f

If the configuration file already contains the same array definition, avoid adding duplicate lines. A spare disk can later be added with mdadm --add, providing faster recovery when a member fails.

Create A Filesystem And Mount Point

Format the assembled device with XFS, a common choice on CentOS:

sudo mkfs.xfs /dev/md0
sudo mkdir -p /srv/raid5
sudo mount /dev/md0 /srv/raid5
df -h /srv/raid5

For persistent mounting, obtain the UUID and add it to /etc/fstab:

sudo blkid /dev/md0

Example entry:

UUID=replace-with-real-uuid  /srv/raid5  xfs  defaults  0  0

Test the entry safely:

sudo umount /srv/raid5
sudo mount -a

If the array will hold shared files for a local office, the NFS file share guide can help expose the mounted directory to trusted clients. Review firewall rules and exports carefully before allowing access across an Australian business network.

Maintain The Array And Protect Data

A RAID 5 set can tolerate one failed disk, but replacement and rebuild activity place additional load on the remaining members. Inspect health information with:

sudo mdadm --detail /dev/md0
sudo smartctl -a /dev/sdb

Install smartmontools if smartctl is unavailable. Schedule checks during a quiet period, such as an afternoon maintenance window, rather than assuming an array in Perth or remote Queensland will be easy to service immediately.

If the array is placed underneath LVM, snapshots can support short-term recovery before risky changes. The guide on LVM snapshots explains that workflow, but snapshots still depend on the same storage and should not replace an independent backup.

For a small operations dashboard, an Android administrator app might display alerts from monitoring software; a simple login screen can illustrate local credential handling, although production systems should use stronger authentication and secure transport.

Checks Before Production Use

Verify the RAID level and member count with mdadm --detail
Confirm the filesystem mounts correctly after a reboot
Test alerts for disk failure and degraded-array status
Store backups on separate hardware or in a different location

Useful Failure Commands

mdadm --fail /dev/md0 /dev/sdb1 marks a known member as failed
mdadm --remove /dev/md0 /dev/sdb1 removes the failed member
mdadm --add /dev/md0 /dev/sdb1 begins rebuilding after replacement
watch cat /proc/mdstat follows rebuild progress

RAID level	Minimum disks	Usable capacity	Disk failure tolerance	Typical use
RAID 0	2	100%	None	Temporary high-speed workloads
RAID 1	2	50%	One or more, depending on layout	Operating system and critical data
RAID 5	3	About 67% with three disks	One disk	General file storage
RAID 6	4	About 50% with four disks	Two disks	Larger arrays and slower replacement windows

A dependable CentOS RAID 5 deployment therefore involves more than the creation command: identify the correct disks, persist the array configuration, monitor rebuilds, test mounting, and keep a separate backup. The practical takeaway is to treat /dev/md0 as resilient working storage, not as the only copy of important data.