{"id":25020,"date":"2026-10-20T12:19:45","date_gmt":"2026-10-20T12:19:45","guid":{"rendered":"https:\/\/atalnetworks.com\/?p=25020"},"modified":"2026-10-20T12:27:23","modified_gmt":"2026-10-20T12:27:23","slug":"mdadm-software-raid-bare-metal-server","status":"publish","type":"post","link":"https:\/\/atalnetworks.com\/el\/mdadm-software-raid-bare-metal-server\/","title":{"rendered":"How to Set Up Software RAID on a Bare Metal Server (mdadm)"},"content":{"rendered":"

Software RAID lets Linux combine physical drives into one storage device. With <\/span>mdadm<\/span>, two data drives can form a RAID 1 mirror so the array remains available if one drive fails. The important work goes beyond creating <\/span>\/dev\/md0<\/span>: you must identify the right disks, confirm the array returns after a reboot, receive failure alerts, and know how to replace a member.<\/span><\/p>\n

This guide builds a <\/span>new data mirror<\/b> from two empty drives on a bare-metal server running Ubuntu Server 24.04 LTS. It does not convert a live operating-system disk into RAID. Creating partitions and formatting the wrong device can erase a working server, so verify every drive by serial number before running the write commands.<\/span><\/p>\n

Before you begin: confirm the drives and your recovery path<\/strong><\/h2>\n

The example server has three physical drives:<\/span><\/p>\n\n\n\n\n\n\n\n
Example device<\/b><\/th>\nRole<\/b><\/th>\nAction in this guide<\/b><\/th>\n<\/tr>\n<\/thead>\n
\/dev\/sda<\/span><\/td>\nExisting Ubuntu system drive<\/span><\/td>\nLeave untouched<\/span><\/td>\n<\/tr>\n
\/dev\/sdb<\/span><\/td>\nFirst empty data drive<\/span><\/td>\nCreate a RAID member partition<\/span><\/td>\n<\/tr>\n
\/dev\/sdc<\/span><\/td>\nSecond empty data drive<\/span><\/td>\nCreate a RAID member partition<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Your server may use different names, especially with NVMe drives. <\/span>\/dev\/sdb<\/span> is an example, not a reliable way to identify hardware. Check the serial number, model, size, and stable <\/span>\/dev\/disk\/by-id\/<\/span> link against your provider’s inventory. A device name can change after a reboot or replacement.<\/span><\/p>\n

Have a recent off-server backup and confirm you can restore it. Arrange remote console or rescue access before modifying storage on a machine you administer only over SSH. Check whether a hardware RAID controller exposes physical drives directly; if Linux sees only a single controller volume, the procedure below does not describe that layout. Ask the provider how replacement drives are identified and swapped.<\/span><\/p>\n

Start with read-only checks:<\/span><\/p>\n

cat \/etc\/os-release<\/p>\n

findmnt -no SOURCE \/<\/p>\n

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL<\/p>\n

ls -l \/dev\/disk\/by-id\/<\/p>\n

sudo wipefs -n \/dev\/sdb<\/p>\n

sudo wipefs -n \/dev\/sdc<\/p>\n

The <\/span>wipefs -n<\/span> option reports signatures without erasing them. Stop if either proposed data drive has a partition, filesystem, RAID signature, LVM membership, or data you need to preserve. Also stop if you cannot confidently map the listed devices to physical bays or serial numbers.<\/span><\/p>\n

Choose the RAID level before partitioning<\/strong><\/h2>\n

For two drives that must survive one disk failure, RAID 1 is the straightforward choice. Other levels serve different goals:<\/span><\/p>\n\n\n\n\n\n\n\n\n\n
Level<\/b><\/th>\nUsual minimum drives<\/b><\/th>\nApproximate usable capacity with equal drives<\/b><\/th>\nFailure tolerance<\/b><\/th>\nTypical fit<\/b><\/th>\n<\/tr>\n<\/thead>\n
RAID 0<\/span><\/td>\n2<\/span><\/td>\nAll drive capacity<\/span><\/td>\nNone<\/span><\/td>\nDisposable scratch data<\/span><\/td>\n<\/tr>\n
RAID 1<\/span><\/td>\n2<\/span><\/td>\nOne drive’s capacity with two members<\/span><\/td>\nOne of two drives<\/span><\/td>\nOS or production data mirror<\/span><\/td>\n<\/tr>\n
RAID 5<\/span><\/td>\n3<\/span><\/td>\n(N – 1) \u00d7 drive capacity<\/span><\/td>\nOne drive<\/span><\/td>\nCapacity-oriented workloads after rebuild and write-risk review<\/span><\/td>\n<\/tr>\n
RAID 6<\/span><\/td>\n4<\/span><\/td>\n(N – 2) \u00d7 drive capacity<\/span><\/td>\nTwo drives<\/span><\/td>\nLarger arrays that need two-drive fault tolerance<\/span><\/td>\n<\/tr>\n
RAID 10<\/span><\/td>\nCommonly 4 for paired mirrors<\/span><\/td>\nRoughly half of total capacity<\/span><\/td>\nDepends on which members fail<\/span><\/td>\nI\/O-heavy workloads with several drives<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These are planning figures before filesystem overhead. Linux MD supports layouts that differ from the usual four-drive RAID 10 arrangement, so document the exact layout rather than assuming every RAID 10 array has identical failure behavior. A pair of 1 TB manufacturer-rated drives in RAID 1 provides about 1 TB of raw mirrored capacity, which Linux displays in smaller TiB units.<\/span><\/p>\n

RAID protects availability against specified drive failures. It does not recover an accidentally deleted file, a damaged database, ransomware-encrypted data, or the loss of the entire server location. Keep independent backups and test restores.<\/span><\/p>\n

Understand the storage stack<\/strong><\/h2>\n

The example uses one Linux RAID partition on each empty drive. <\/span>mdadm<\/span> combines those partitions into <\/span>\/dev\/md0<\/span>. The ext4 filesystem sits on <\/span>\/dev\/md0<\/span>, and the application accesses it through <\/span>\/srv\/data<\/span>.<\/span><\/p>\n

\/dev\/sdb1 + \/dev\/sdc1\u00a0 ->\u00a0 \/dev\/md0\u00a0 ->\u00a0 ext4\u00a0 ->\u00a0 \/srv\/data<\/p>\n

\u00a0\u00a0\u00a0\u00a0\u00a0RAID members \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 MD array \u00a0 \u00a0 filesystem \u00a0 mount point<\/span><\/p>\n

Format the MD device once. Do not create separate filesystems on the member partitions. An optional LVM layer can sit above the array when you need logical-volume flexibility, but it adds decisions that the basic mirror does not require.<\/span><\/p>\n

Create a RAID 1 data array on Ubuntu Server 24.04<\/strong><\/h2>\n

Run the next steps only when <\/span>\/dev\/sdb<\/span> and <\/span>\/dev\/sdc<\/span> are confirmed empty data drives and <\/span>\/dev\/sda<\/span> is the existing OS drive. Substitute the actual devices on your server. On NVMe, a member partition may look like <\/span>\/dev\/nvme1n1p1<\/span>.<\/span><\/p>\n

1. Install mdadm and confirm drive identity again<\/strong><\/h3>\n

sudo apt update<\/p>\n

sudo apt install mdadm gdisk<\/p>\n

findmnt -no SOURCE \/<\/p>\n

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL<\/p>\n

Compare the output with your recorded drive serials. Do not proceed if the system partition or any mounted data volume appears on either selected drive.<\/span><\/p>\n

2. Partition the two empty drives<\/strong><\/h3>\n

The following commands <\/span>replace the partition tables<\/b> on the named disks. <\/span>sgdisk -o<\/span> creates a GPT table. <\/span>-n 1:0:0<\/span> creates a first partition using the available space, and <\/span>-t 1:FD00<\/span> marks it for Linux RAID.<\/span><\/p>\n

sudo sgdisk -o -n 1:0:0 -t 1:FD00 \/dev\/sdb<\/p>\n

sudo sgdisk -o -n 1:0:0 -t 1:FD00 \/dev\/sdc<\/p>\n

sudo partprobe \/dev\/sdb \/dev\/sdc<\/p>\n

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS \/dev\/sdb \/dev\/sdc<\/p>\n

Confirm that <\/span>\/dev\/sdb1<\/span> and <\/span>\/dev\/sdc1<\/span> exist and have suitable matching sizes. If the kernel cannot reread a new partition table because the device is busy, stop and investigate. Do not push ahead with a different device name.<\/span><\/p>\n

3. Create the mirror and observe synchronization<\/strong><\/h3>\n

sudo mdadm –create \/dev\/md0 –level=1 –raid-devices=2 \/dev\/sdb1 \/dev\/sdc1<\/p>\n

cat \/proc\/mdstat<\/p>\n

sudo mdadm –detail \/dev\/md0<\/p>\n

–level=1<\/span> requests mirroring, and <\/span>–raid-devices=2<\/span> declares two active members. <\/span>mdadm<\/span> may warn that its default metadata placement needs special care for a boot device. This example is a data array; the boot plan appears later.<\/span><\/p>\n

In <\/span>\/proc\/mdstat<\/span>, <\/span>[2\/2] [UU]<\/span> indicates that both members are present. A <\/span>resync<\/span> progress line can appear while the initial mirror is being built. Wait for synchronization to finish before declaring setup complete. A status such as <\/span>[U_]<\/span> indicates a missing or failed member and needs investigation.<\/span><\/p>\n

4. Create a filesystem and mount it<\/strong><\/h3>\n

The next <\/span>mkfs<\/span> command <\/span>destroys any existing filesystem on <\/b>\/dev\/md0<\/b>. Confirm the MD array is the new one you just created.<\/span><\/p>\n

sudo mkfs.ext4 -L data_raid1 \/dev\/md0<\/p>\n

sudo mkdir -p \/srv\/data<\/p>\n

sudo mount \/dev\/md0 \/srv\/data<\/p>\n

findmnt \/srv\/data<\/p>\n

df -hT \/srv\/data<\/p>\n

sudo blkid \/dev\/md0<\/p>\n

Use the UUID from <\/span>blkid<\/span> for the permanent mount. Set ownership and access permissions for your application after deciding which service account should write to <\/span>\/srv\/data<\/span>.<\/span><\/p>\n

5. Save assembly settings and make the mount persistent<\/strong><\/h3>\n

First inspect the generated array definition and the current configuration:<\/span><\/p>\n

sudo mdadm –detail –scan<\/p>\n

sudo grep ‘^ARRAY ‘ \/etc\/mdadm\/mdadm.conf<\/p>\n

Edit <\/span>\/etc\/mdadm\/mdadm.conf<\/span> so it contains <\/span>one correct <\/b>ARRAY<\/b> line for this array<\/b>. Do not repeatedly append the scan output; duplicate or outdated entries complicate troubleshooting. Rebuild Ubuntu’s initramfs:<\/span><\/p>\n

sudo update-initramfs -u<\/p>\n

Add a line to <\/span>\/etc\/fstab<\/span> using the <\/span>filesystem UUID reported for <\/b>\/dev\/md0<\/b>, not the example value below:<\/span><\/p>\n

UUID=<your-ext4-filesystem-UUID>\u00a0 \/srv\/data\u00a0 ext4\u00a0 defaults\u00a0 0\u00a0 2<\/p>\n

defaults<\/span> makes the mount a normal boot dependency. If the data volume is optional and you deliberately want the system to boot when it is unavailable, assess <\/span>nofail<\/span> and your application’s dependency behavior before choosing it. An apparently successful boot with an unmounted data directory can cause an application to write onto the root filesystem instead.<\/span><\/p>\n

Validate the entry while you still have console access:<\/span><\/p>\n

sudo findmnt –verify<\/p>\n

sudo umount \/srv\/data<\/p>\n

sudo mount \/srv\/data<\/p>\n

findmnt \/srv\/data<\/p>\n

Schedule a controlled reboot. After the server returns, verify both assembly and mounting:<\/span><\/p>\n

cat \/proc\/mdstat<\/p>\n

sudo mdadm –detail \/dev\/md0<\/p>\n

findmnt \/srv\/data<\/p>\n

Look for both active members, no failed devices, the expected filesystem, and the intended mount point. Keep the recorded drive serials and array UUID with the server’s maintenance notes.<\/span><\/p>\n

Monitor array health, physical drives, and backup restores<\/strong><\/h2>\n

A RAID 1 server can keep serving requests with one failed drive. That continued operation is useful, but it can hide the failure until the second drive has a problem. Check <\/span>mdadm<\/span> status and deliver alerts to someone who will act on them.<\/span><\/p>\n

cat \/proc\/mdstat<\/span><\/p>\n

sudo mdadm –detail \/dev\/md0<\/span><\/p>\n

The <\/span>mdadm.conf<\/span> MAILADDR<\/span> setting can direct monitor alerts, but an email address alone is insufficient. Confirm that the monitor is running on the installed Ubuntu image, configure a working mail relay or event handler, and test end-to-end delivery. A test event can be generated with:<\/span><\/p>\n

sudo mdadm –monitor –scan –oneshot –test<\/span><\/p>\n

Inspect each physical drive’s SMART or NVMe health information as well. Array status and drive diagnostics answer different questions: an MD array can be clean while a device reports concerning media or controller errors. A periodic MD consistency check can identify disagreements between members, but interpreting <\/span>mismatch_cnt<\/span> requires care; it does not independently tell you which copy is correct. Follow the Linux kernel MD guidance before repairing mismatches.<\/span><\/p>\n

Finally, restore a sample file or application backup to a separate location. A mirrored array is not proof that a backup can recover the service.<\/span><\/p>\n

Replace a failed RAID 1 member<\/strong><\/h2>\n

Treat drive replacement as a controlled maintenance task. Before touching hardware, confirm the current array state with <\/span>mdadm –detail<\/span>, map its member partition to a <\/span>physical serial number<\/b>, and verify a usable backup. Never assume that <\/span>\/dev\/sdc<\/span> still refers to the same bay after a replacement.<\/span><\/p>\n

    \n
  1. Identify the failed member.<\/b> Record the array UUID, healthy member, device serials, and current <\/span>[U_]<\/span> or <\/span>[_U]<\/span> status. Investigate controller and system logs for the underlying error.<\/span><\/li>\n
  2. Remove only the failed member from the array.<\/b> If the member still appears active but has confirmed hardware faults, use <\/span>mdadm –manage \/dev\/md0 –fail <failed-member-partition><\/span> and then <\/span>–remove <failed-member-partition><\/span>. A member already marked faulty may only need removal. Never run these commands against the sole healthy copy.<\/span><\/li>\n
  3. Arrange the physical replacement.<\/b> Coordinate with the provider or use an approved hot-swap procedure. Match the serial and bay before and after the swap.<\/span><\/li>\n
  4. Partition the new disk.<\/b> Reproduce the intended RAID member partition, ensuring its usable size is at least as large as the array requires. If copying a GPT layout, give the new disk its own disk and partition GUIDs. Inspect the result before adding it.<\/span><\/li>\n
  5. Add the new member partition and watch recovery.<\/b> For a replacement now identified as <\/span>\/dev\/sdc1<\/span>, the command is <\/span>sudo mdadm –manage \/dev\/md0 –add \/dev\/sdc1<\/span>. Follow <\/span>\/proc\/mdstat<\/span> and <\/span>mdadm –detail<\/span> until recovery finishes and both members are active.<\/span><\/li>\n
  6. Recheck operations.<\/b> Confirm alerts, physical-drive health, backups, and the mount. If this was also a boot disk, restore and test its boot path separately.<\/span><\/li>\n<\/ol>\n

    A simulated <\/span>–fail<\/span> test exercises array management. It does not validate bay identification, hot-swap wiring, firmware boot entries, or the provider’s physical replacement process.<\/span><\/p>\n

    Bootable RAID 1 requires more than a mirrored root filesystem<\/strong><\/h2>\n

    The walkthrough above assumes Ubuntu already boots from a separate system drive. If the operating system itself must survive a boot-drive failure, plan the layout during a fresh installation or follow a separately tested migration procedure. First check the firmware mode:<\/span><\/p>\n

    [ -d \/sys\/firmware\/efi ] && echo UEFI || echo BIOS<\/strong><\/p>\n\n\n\n\n\n\n
    Boot mode<\/b><\/th>\nAdditional work beyond an MD root mirror<\/b><\/th>\n<\/tr>\n<\/thead>\n
    UEFI<\/span><\/td>\nProvide a usable EFI System Partition on each intended boot disk, keep boot files current on both, maintain firmware boot entries, and test each disk independently. The ESP is commonly managed separately from the MD root array.<\/span><\/td>\n<\/tr>\n
    Legacy BIOS<\/span><\/td>\nInstall a working bootloader path on each intended boot disk, meet the partitioning requirements of the boot mode, and test both drives.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    The initramfs must also be able to assemble the root array. A server that serves data after one disk fails may still be unable to restart if the surviving disk lacks a valid boot path. Provider rescue access and a real one-disk boot test establish the answer. Follow documentation for the exact firmware, distribution, installer, and storage layout rather than reusing the data-array commands as a root-disk migration recipe.<\/span><\/p>\n

    Troubleshoot common mdadm problems<\/strong><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n
    Symptom<\/b><\/th>\nFirst safe checks<\/b><\/th>\nLikely next decision<\/b><\/th>\n<\/tr>\n<\/thead>\n
    \/proc\/mdstat<\/span> shows <\/span>[U_]<\/span> or <\/span>[_U]<\/span><\/td>\nmdadm –detail<\/span>, drive serials, system logs<\/span><\/td>\nDiagnose the member and controller; replace the correct drive.<\/span><\/td>\n<\/tr>\n
    Resync is taking longer than expected<\/span><\/td>\n\/proc\/mdstat<\/span>, drive health, workload and I\/O logs<\/span><\/td>\nCheck errors and load; do not assume a fixed rebuild time.<\/span><\/td>\n<\/tr>\n
    Array returns under an unexpected MD name<\/span><\/td>\nmdadm –detail –scan<\/span>, <\/span>mdadm.conf<\/span>, <\/span>lsblk<\/span><\/td>\nResolve duplicate or foreign assembly configuration; rely on filesystem UUID for the mount.<\/span><\/td>\n<\/tr>\n
    Data directory is not mounted after reboot<\/span><\/td>\nfindmnt<\/span>, <\/span>blkid<\/span>, <\/span>\/etc\/fstab<\/span>, <\/span>journalctl<\/span><\/td>\nFix the UUID, assembly or boot ordering before starting the application.<\/span><\/td>\n<\/tr>\n
    Replacement partition cannot be added<\/span><\/td>\nlsblk<\/span>, <\/span>sgdisk -p<\/span>, <\/span>mdadm –detail<\/span><\/td>\nCheck its actual usable size and old RAID signatures before altering it.<\/span><\/td>\n<\/tr>\n
    MD state looks clean but drive errors appear<\/span><\/td>\nSMART\/NVMe logs and kernel messages<\/span><\/td>\nInvestigate the physical disk; a clean array state does not certify hardware.<\/span><\/td>\n<\/tr>\n
    Server cannot boot after a disk is removed<\/span><\/td>\nRemote console, firmware entries, ESP or GRUB state<\/span><\/td>\nRestore the missing boot path using the appropriate BIOS or UEFI procedure.<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    Avoid <\/span>mdadm –assemble –force<\/span>, signature erasure, or repair commands as a first response to an unclear state. Preserve the healthy member and backup while you determine what failed.<\/span><\/p>\n

    Match the storage plan to the workload<\/strong><\/h2>\n

    A two-drive RAID 1 mirror is a practical starting point for application data or a planned system installation where single-drive availability matters. Four or more drives may justify RAID 10 for an I\/O-heavy database or virtual-machine host, but capacity, layout, and failure patterns still require design review. RAID 0 belongs only where losing the entire array is acceptable. Large parity arrays need closer review of rebuild time and write behavior.<\/span><\/p>\n

    If you are selecting a new server, confirm the physical drive count, interface, replacement process, remote-console access, and backup plan before choosing a RAID level. <\/span>Explore Atal Networks’ bare metal server options<\/span><\/a> and ask which storage configuration is available for the specific machine and location.<\/span><\/p>\n

    Frequently asked questions<\/strong><\/h2>\n

    Does RAID 1 replace backups?<\/span><\/h3>\n

    No. Both mirror members can contain the same deleted, encrypted, or corrupted data. Keep separate backups, retain appropriate history, and test a restore.<\/span><\/p>\n

    Can I add RAID 1 to an existing server without losing data?<\/span><\/h3>\n

    It can be done with a carefully designed migration, but the empty-disk creation commands in this guide are destructive. Back up the server and use a migration procedure for its exact disk and boot layout.<\/span><\/p>\n

    Will the server boot if one RAID 1 drive fails?<\/span><\/h3>\n

    Only if the firmware, bootloader, required boot partitions, and MD root assembly work from the surviving drive. Test both boot paths with remote console access.<\/span><\/p>\n

    Can I mirror a SATA SSD and an NVMe drive?<\/span><\/h3>\n

    Linux MD can combine block devices exposed by different storage interfaces. The usable size follows the smaller member, and the devices may differ in speed, endurance, and failure characteristics. Matched drives are generally simpler to operate.<\/span><\/p>\n

    How long will the RAID 1 rebuild take?<\/span><\/h3>\n

    There is no reliable universal time. Drive capacity, sustained I\/O, interface speed, media health, and concurrent workloads all matter. Watch the reported recovery progress and errors rather than trusting a fixed estimate.<\/span><\/p>\n

    Can a clean array contain a failing disk?<\/span><\/h3>\n

    Yes. A clean MD state describes array synchronization; it does not replace physical health checks. Review SMART or NVMe logs and system errors alongside the array state.<\/span><\/p>\n

    Final verification checklist<\/strong><\/h2>\n