Ir al contenido 
Software RAID lets Linux combine physical drives into one storage device. With mdadm, two data drives can form a RAID 1 mirror so the array remains available if one drive fails. The important work goes beyond creating /dev/md0: you must identify the right disks, confirm the array returns after a reboot, receive failure alerts, and know how to replace a member.
This guide builds a new data mirror 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.
Before you begin: confirm the drives and your recovery path
The example server has three physical drives:
| Example device | Role | Action in this guide |
|---|---|---|
| /dev/sda | Existing Ubuntu system drive | Leave untouched |
| /dev/sdb | First empty data drive | Create a RAID member partition |
| /dev/sdc | Second empty data drive | Create a RAID member partition |
Your server may use different names, especially with NVMe drives. /dev/sdb is an example, not a reliable way to identify hardware. Check the serial number, model, size, and stable /dev/disk/by-id/ link against your provider’s inventory. A device name can change after a reboot or replacement.
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.
Start with read-only checks:
cat /etc/os-release
findmnt -no SOURCE /
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
ls -l /dev/disk/by-id/
sudo wipefs -n /dev/sdb
sudo wipefs -n /dev/sdc
The wipefs -n 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.
Choose the RAID level before partitioning
For two drives that must survive one disk failure, RAID 1 is the straightforward choice. Other levels serve different goals:
| Level | Usual minimum drives | Approximate usable capacity with equal drives | Failure tolerance | Typical fit |
|---|---|---|---|---|
| RAID 0 | 2 | All drive capacity | None | Disposable scratch data |
| RAID 1 | 2 | One drive’s capacity with two members | One of two drives | OS or production data mirror |
| RAID 5 | 3 | (N – 1) × drive capacity | One drive | Capacity-oriented workloads after rebuild and write-risk review |
| RAID 6 | 4 | (N – 2) × drive capacity | Two drives | Larger arrays that need two-drive fault tolerance |
| RAID 10 | Commonly 4 for paired mirrors | Roughly half of total capacity | Depends on which members fail | I/O-heavy workloads with several drives |
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.
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.
Understand the storage stack
The example uses one Linux RAID partition on each empty drive. mdadm combines those partitions into /dev/md0. The ext4 filesystem sits on /dev/md0, and the application accesses it through /srv/data.
/dev/sdb1 + /dev/sdc1 -> /dev/md0 -> ext4 -> /srv/data
RAID members MD array filesystem mount point
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.
Create a RAID 1 data array on Ubuntu Server 24.04
Run the next steps only when /dev/sdb y /dev/sdc are confirmed empty data drives and /dev/sda is the existing OS drive. Substitute the actual devices on your server. On NVMe, a member partition may look like /dev/nvme1n1p1.
1. Install mdadm and confirm drive identity again
sudo apt update
sudo apt install mdadm gdisk
findmnt -no SOURCE /
lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL
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.
2. Partition the two empty drives
The following commands replace the partition tables on the named disks. sgdisk -o creates a GPT table. -n 1:0:0 creates a first partition using the available space, and -t 1:FD00 marks it for Linux RAID.
sudo sgdisk -o -n 1:0:0 -t 1:FD00 /dev/sdb
sudo sgdisk -o -n 1:0:0 -t 1:FD00 /dev/sdc
sudo partprobe /dev/sdb /dev/sdc
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS /dev/sdb /dev/sdc
Confirm that /dev/sdb1 y /dev/sdc1 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.
3. Create the mirror and observe synchronization
sudo mdadm –create /dev/md0 –level=1 –raid-devices=2 /dev/sdb1 /dev/sdc1
cat /proc/mdstat
sudo mdadm –detail /dev/md0
–level=1 requests mirroring, and –raid-devices=2 declares two active members. mdadm 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.
In /proc/mdstat, [2/2] [UU] indicates that both members are present. A resync progress line can appear while the initial mirror is being built. Wait for synchronization to finish before declaring setup complete. A status such as [U_] indicates a missing or failed member and needs investigation.
4. Create a filesystem and mount it
The next mkfs command destroys any existing filesystem on /dev/md0. Confirm the MD array is the new one you just created.
sudo mkfs.ext4 -L data_raid1 /dev/md0
sudo mkdir -p /srv/data
sudo mount /dev/md0 /srv/data
findmnt /srv/data
df -hT /srv/data
sudo blkid /dev/md0
Use the UUID from blkid for the permanent mount. Set ownership and access permissions for your application after deciding which service account should write to /srv/data.
5. Save assembly settings and make the mount persistent
First inspect the generated array definition and the current configuration:
sudo mdadm –detail –scan
sudo grep ‘^ARRAY ‘ /etc/mdadm/mdadm.conf
Edit /etc/mdadm/mdadm.conf so it contains one correct ARRAY line for this array. Do not repeatedly append the scan output; duplicate or outdated entries complicate troubleshooting. Rebuild Ubuntu’s initramfs:
sudo update-initramfs -u
Add a line to /etc/fstab using the filesystem UUID reported for /dev/md0, not the example value below:
UUID=<your-ext4-filesystem-UUID> /srv/data ext4 defaults 0 2
defaults 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 nofail 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.
Validate the entry while you still have console access:
sudo findmnt –verify
sudo umount /srv/data
sudo mount /srv/data
findmnt /srv/data
Schedule a controlled reboot. After the server returns, verify both assembly and mounting:
cat /proc/mdstat
sudo mdadm –detail /dev/md0
findmnt /srv/data
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.
Monitor array health, physical drives, and backup restores
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 mdadm status and deliver alerts to someone who will act on them.
cat /proc/mdstat
sudo mdadm –detail /dev/md0
The mdadm.conf MAILADDR 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:
sudo mdadm –monitor –scan –oneshot –test
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 mismatch_cnt requires care; it does not independently tell you which copy is correct. Follow the Linux kernel MD guidance before repairing mismatches.
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.
Replace a failed RAID 1 member
Treat drive replacement as a controlled maintenance task. Before touching hardware, confirm the current array state with mdadm –detail, map its member partition to a physical serial number, and verify a usable backup. Never assume that /dev/sdc still refers to the same bay after a replacement.
- Identify the failed member. Record the array UUID, healthy member, device serials, and current [U_] o [_U] status. Investigate controller and system logs for the underlying error.
- Remove only the failed member from the array. If the member still appears active but has confirmed hardware faults, use mdadm –manage /dev/md0 –fail <failed-member-partition> and then –remove <failed-member-partition>. A member already marked faulty may only need removal. Never run these commands against the sole healthy copy.
- Arrange the physical replacement. Coordinate with the provider or use an approved hot-swap procedure. Match the serial and bay before and after the swap.
- Partition the new disk. 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.
- Add the new member partition and watch recovery. For a replacement now identified as /dev/sdc1, the command is sudo mdadm –manage /dev/md0 –add /dev/sdc1. Follow /proc/mdstat y mdadm –detail until recovery finishes and both members are active.
- Recheck operations. Confirm alerts, physical-drive health, backups, and the mount. If this was also a boot disk, restore and test its boot path separately.
A simulated –fail test exercises array management. It does not validate bay identification, hot-swap wiring, firmware boot entries, or the provider’s physical replacement process.
Bootable RAID 1 requires more than a mirrored root filesystem
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:
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
| Boot mode | Additional work beyond an MD root mirror |
|---|---|
| UEFI | Provide 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. |
| Legacy BIOS | Install a working bootloader path on each intended boot disk, meet the partitioning requirements of the boot mode, and test both drives. |
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.
Troubleshoot common mdadm problems
| Symptom | First safe checks | Likely next decision |
|---|---|---|
| /proc/mdstat shows [U_] o [_U] | mdadm –detail, drive serials, system logs | Diagnose the member and controller; replace the correct drive. |
| Resync is taking longer than expected | /proc/mdstat, drive health, workload and I/O logs | Check errors and load; do not assume a fixed rebuild time. |
| Array returns under an unexpected MD name | mdadm –detail –scan, mdadm.conf, lsblk | Resolve duplicate or foreign assembly configuration; rely on filesystem UUID for the mount. |
| Data directory is not mounted after reboot | findmnt, blkid, /etc/fstab, journalctl | Fix the UUID, assembly or boot ordering before starting the application. |
| Replacement partition cannot be added | lsblk, sgdisk -p, mdadm –detail | Check its actual usable size and old RAID signatures before altering it. |
| MD state looks clean but drive errors appear | SMART/NVMe logs and kernel messages | Investigate the physical disk; a clean array state does not certify hardware. |
| Server cannot boot after a disk is removed | Remote console, firmware entries, ESP or GRUB state | Restore the missing boot path using the appropriate BIOS or UEFI procedure. |
Avoid mdadm –assemble –force, signature erasure, or repair commands as a first response to an unclear state. Preserve the healthy member and backup while you determine what failed.
Match the storage plan to the workload
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.
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. Explore Atal Networks’ bare metal server options and ask which storage configuration is available for the specific machine and location.
Frequently asked questions
Does RAID 1 replace backups?
No. Both mirror members can contain the same deleted, encrypted, or corrupted data. Keep separate backups, retain appropriate history, and test a restore.
Can I add RAID 1 to an existing server without losing data?
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.
Will the server boot if one RAID 1 drive fails?
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.
Can I mirror a SATA SSD and an NVMe drive?
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.
How long will the RAID 1 rebuild take?
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.
Can a clean array contain a failing disk?
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.
Final verification checklist
- Both RAID member partitions match the intended physical drive serials.
- Initial synchronization has finished and /proc/mdstat shows both members active.
- The array assembles and /srv/data mounts after a controlled reboot.
- A test alert reaches the person or system responsible for replacement.
- An off-server backup restores successfully. For OS mirrors, both single-disk boot paths have been tested.
That is the difference between an array that was created and a storage setup you can operate when a drive fails.