You can mirror a server’s system disk with software RAID 1 and keep that server running and booting after a single drive failure. The operating system then exists as two identical copies, one on each disk. On Linux you will work with mdadm; on Windows Server you will use Disk Management. This guide walks you through prerequisites, how to configure software RAID 1 on both platforms, verification that the mirror actually boots, and the maintenance routine that keeps it healthy. Back up the server before you change any RAID setting. Treat the mirror as a responsibility you carry forward, not a task you finish once.

Prerequisites and tooling

Hardware and software requirements

RAID 1 gives you full data redundancy by mirroring data exactly between two or more drives. If one drive fails, the other takes over. For a system disk, that means the operating system survives a single disk loss and the server keeps booting.

Before you configure software RAID 1, confirm you have two identical or closely matched disks. Mismatched capacity wastes space on the larger drive, because the mirror is only as big as the smaller member. Check that your Linux distribution ships mdadm, or that your Windows Server edition supports mirrored volumes in Disk Management. Plan for a maintenance window and a verified backup.

Using RAID 1 for OS boot drives provides redundancy for the operating system on physical servers. Some bare-metal providers offer software RAID for OS redundancy out of the box, for example with Windows Server 2022 images. Confirm what your provider pre-configures before you change anything.

When software RAID 1 fits best

Software RAID and hardware RAID are complementary options, and each fits a different situation. Software RAID runs on the host CPU and needs no extra controller card. Hardware RAID offloads parity and mirroring work to a dedicated controller with its own cache and battery backup.

FactorSoftware RAID 1Hardware RAID 1
CostNo controller purchaseController card required
PortabilityArray moves with the OSTied to controller model
CPU overheadUses host CPUOffloaded to controller

Choose software RAID 1 when you want a simple, low-cost mirror on a single server and you value portability across hardware. Choose hardware RAID when you need controller-level cache, hot-swap management, or consistent behavior across many machines. Neither approach is inherently better; match the tool to the workload.

Configure software RAID 1 step by step

Back up the server before you change any RAID setting. An existing RAID configuration may need to be deleted first, and that step destroys data.

Create the array on Linux with mdadm

You will work from a live environment or the installed system, depending on whether the OS is already in place. The sequence below assumes two blank disks, /dev/sda and /dev/sdb.

  1. Partition both disks with fdisk or parted. Create a partition of identical size on each drive and set the type to Linux RAID autodetect (fd).
  2. Create the mirror with mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1. Confirm the array assembles cleanly.
  3. Format the array with your chosen filesystem, for example mkfs.ext4 /dev/md0.
  4. Mount the array at your target mount point and copy or install the operating system onto it.
  5. Install the bootloader on both disks, not just the first. On GRUB, run grub-install against /dev/sda and again against /dev/sdb. This step is where most failed mirrors begin.
  6. Write the array definition to mdadm.conf so the system reassembles the mirror at boot.

When you configure software RAID 1 on an existing system, you often must shrink a partition, create the mirror, and migrate data. Test that path on a spare machine first.

Configure software RAID 1 on Windows Server

Windows Server handles the mirror through Disk Management. Press Windows key + R, type diskmgmt.msc, and press Enter.

  1. Confirm both disks appear and initialize any disk marked as uninitialized.
  2. Right-click the boot volume and choose Add Mirror.
  3. Select the second disk as the mirror target and confirm.
  4. Wait for the resynchronization to finish before you reboot or change anything else.

Disk Management mirrors the boot volume at the volume level, so you do not partition manually. The mirror status shows as Resynching until the copy completes. If you configure software RAID 1 on a server that already carries a RAID set, remove the old configuration first and verify the disks are clean.

Verify the mirrored system disk

Check array status and boot integrity

A mirror you never test is a guess. Run a reboot test before you trust the array. On Linux, mark one disk faulty with mdadm --manage /dev/md0 --fail /dev/sdb1, then remove it and reboot. The server should come up from the remaining disk. On Windows Server, power down, disconnect one drive, and boot again. Confirm the operating system loads and your services start. Reconnect the disk afterward and let the mirror resynchronize. This test proves the bootloader lives on both disks, which is the step most people get wrong when they configure software RAID 1.

Read the array health output regularly. On Linux, cat /proc/mdstat shows each array and its state. A healthy mirror reports both members as active with the state [UU]. A degraded array shows [U_], meaning one member is missing or failed. Run mdadm --detail /dev/md0 for more detail, including the failed device and the rebuild progress. On Windows Server, open Disk Management and look at the volume status. A healthy mirror reads Healthy; a broken one reads Failed Redundancy or At Risk. Hover over the volume to see which disk dropped out.

Check these outputs after every reboot and after any disk event. A mirror can break silently, and the status line is your first warning. Record the healthy output once, so you have a baseline to compare against later.

Maintain and troubleshoot the array

Replace a failed disk and rebuild

A degraded array still runs. One member has dropped out, and the mirror now serves reads and writes from the surviving disk alone. You have no redundancy left until the rebuild finishes, so treat this state as urgent rather than comfortable.

Start by confirming the failure. Run cat /proc/mdstat and look for a status like [2/1] [U_], which tells you one disk is missing or failed. Then follow this sequence:

  1. Physically replace the failed disk and create a new RAID-autodetect partition on it, matching the partition type of the surviving member.
  2. Add the new partition to the array with mdadm --manage /dev/md0 --add /dev/sdc1. The tool confirms the device was added.
  3. Re-run cat /proc/mdstat to verify synchronization started. The output shows the new device, such as sdc1[2], plus a recovery progress line.
  4. Wait for synchronization to finish, then check again. A healthy rebuilt array reports [2/2] [UU], meaning both members are active and in sync.

Do not reboot or pull the second disk during recovery. Let the copy complete first.

Set up monitoring and alerts

A mirror can break without any visible symptom. The server keeps serving traffic from one disk, and nothing on screen warns you. That silence is the real danger, because the second failure then takes the system down with no fallback.

Set up monitoring that reads array state on a schedule and alerts you on any change from healthy. On Linux, watch /proc/mdstat or run mdadm --detail and flag any state other than [UU]. On Windows Server, watch the volume status in Disk Management and alert on Failed Redundancy or At Risk. Route alerts to a channel someone actually reads, and test the alert path once so you know it fires.

Review the status after every reboot and every disk event. Keep a recorded baseline of the healthy output. When you configure software RAID 1, the setup is the easy part; catching a silent break before the second disk fails is what protects the server.

You now have the full path: check prerequisites, build the mirror on Linux or Windows Server, verify it, and maintain it. Two steps deserve extra care. Install the bootloader on both disks, not just the first. Then prove the server still boots after you remove one disk. Skip either step, and the mirror may fail when you need it most.

Treat the array as an ongoing duty. Watch its status after every reboot and every disk event. A silent break leaves you with one disk and no warning. Configure software RAID 1 once, then keep checking it.

FAQ

Does RAID 1 replace regular backups?

No. A mirror protects you from a single disk failure, nothing more. It copies every mistake instantly, including deleted files and corrupted data. Keep separate backups for accidental deletion, ransomware, and site-level disasters.

Do both disks need to be the same size?

Match them as closely as you can. The mirror only uses the capacity of the smaller member, so a larger drive wastes space. Identical models also keep performance predictable and simplify replacement later.

Can you mirror a system that already runs on one disk?

Yes, but the path differs by platform. Windows Server can add a mirror to the boot volume directly. On Linux you typically shrink a partition, build the array, and migrate data. Test the procedure on a spare machine first.

What happens to server performance during a rebuild?

The array copies data to the new member while serving normal traffic. Expect slower disk response until synchronization finishes. Avoid heavy write workloads and never reboot or pull the second disk mid-rebuild.

Does software RAID 1 work inside a virtual machine?

It can, but the hypervisor usually provides redundancy already. Check your provider’s storage setup before you add a guest-level mirror. Duplicating protection at both layers adds overhead without extra safety.