Bare Metal Dedicated Server RAID 1 on Ubuntu 24.04

Why RAID 1 is a sensible first move on a bare metal dedicated server

If your new bare metal dedicated server ships with two matching drives, RAID 1 gives you a safer starting point than a single-disk install. It mirrors data across both disks, so one drive can fail without taking the system offline. For Hostperl customers moving production sites, mail, or small databases onto dedicated server hosting, this is often the first reliability upgrade worth doing before launch.

This tutorial shows how to build software RAID 1 on Ubuntu Server 24.04 during a fresh install, then verify that the array survives a simulated disk failure. You will also add monitoring, preserve the boot path, and keep a rollback route if the layout is wrong. If you are planning a migration from VPS or shared hosting, the same discipline applies to recovery testing; our notes on Linux maintenance checks and kernel maintenance map well to server rooms too.

What you need before you start

• A bare metal server or dedicated server with two equal-sized disks.
• Ubuntu Server 24.04 LTS installer ISO or remote console access.
• IPMI, iDRAC, Redfish, or equivalent out-of-band access for recovery.
• A second computer for SSH testing and verification.
• Enough downtime to reinstall if partitioning goes wrong.

This procedure is specific to Ubuntu Server 24.04 because we use apt, systemd, UFW, and mdadm on a Linux install path that Ubuntu supports cleanly. For customers comparing server classes, Hostperl also documents dedicated servers and unmanaged dedicated server options so you can decide where you want more hands-on control.

Connect and confirm the OS

On your local computer, open your first SSH session with the reserved example IP below.

ssh root@203.0.113.10

Use 203.0.113.10 only as documentation text. Replace it with the public IP assigned to your real server. Keep this root session open while you build and test the new layout.

On the VPS as root, confirm the operating system before you touch storage.

cat /etc/os-release

You should see Ubuntu 24.04 details. If you do not, stop and use the matching guide for your platform instead of continuing with Ubuntu commands.

Inspect the disks and choose the RAID layout

Before installing anything, identify the disk names. On many dedicated servers they will appear as /dev/sda and /dev/sdb, but do not assume that. Use stable names if the installer exposes them.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL

You want two equal disks and no data you need to preserve. If one drive already contains production data, stop here and migrate it first. RAID setup is not a live repair job.

For this tutorial, the simplest production layout is:

• /boot on mirrored RAID 1
• LVM on top of RAID 1 for flexibility
• / and /var as logical volumes

This makes kernel updates, logs, and future resizing easier to manage on a dedicated server.

Install Ubuntu Server 24.04 with mirrored disks

During the Ubuntu installer, choose Custom storage layout. Create two EFI partitions if the server boots in UEFI mode, then mirror the remaining partitions with mdadm. A practical layout looks like this:

Disk 1 /dev/sda and Disk 2 /dev/sdb

/dev/sda1  1 GiB  EFI System Partition
/dev/sda2  2 GiB  /boot RAID member
/dev/sda3  rest   RAID member

/dev/sdb1  1 GiB  EFI System Partition
/dev/sdb2  2 GiB  /boot RAID member
/dev/sdb3  rest   RAID member

Then create:

RAID1 md0 = /dev/sda2 + /dev/sdb2 mounted at /boot
RAID1 md1 = /dev/sda3 + /dev/sdb3 used as LVM physical volume

Finish the install normally. Set a strong root password or, if you prefer, create a non-root user during install and use SSH keys after first boot.

Create a non-root administrator and test sudo

Do this before you tighten SSH. Keep the root window open until the new login works.

On the VPS as root, create the deploy account, add it to sudo, and set up SSH access.

adduser deploy

Enter a strong password when prompted. Then grant sudo rights.

usermod -aG sudo deploy

Prepare the SSH directory and permissions.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

If you already have a public key on your local computer, copy it into the server now. On your local computer, run:

ssh-copy-id deploy@203.0.113.10

Then test a second SSH session from your local computer.

ssh deploy@203.0.113.10

Inside that second session, confirm sudo works.

sudo -v

You should be asked for the deploy password and then returned to the shell without errors. If that works, you can keep using the new account for the rest of the tutorial.

Install mdadm and finish the RAID toolchain

On the VPS as the non-root sudo user, update the package index and install the RAID tools plus a few helpers used for diagnostics.

sudo apt update
sudo apt install -y mdadm smartmontools initramfs-tools grub-efi-amd64

Check the installed RAID utility version.

mdadm --version

On Ubuntu 24.04, you should see a modern mdadm release from the 6.x line. That is enough for reliable software RAID management.

Verify the array and boot configuration

After the install, confirm the arrays are active.

cat /proc/mdstat

Then inspect the array metadata.

sudo mdadm --detail /dev/md0
sudo mdadm --detail /dev/md1

If your installer used different device names, replace /dev/md0 and /dev/md1 with the actual arrays shown in /proc/mdstat. You want both member disks listed as active and clean.

Save the array definition so it assembles on boot.

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

Regenerate initramfs so Ubuntu knows about the mirrored boot path.

sudo update-initramfs -u

Now check that GRUB knows which drive to target. On UEFI installs, the installer usually handles this. Still, confirm the package is present and the EFI path is mounted.

findmnt /boot/efi
sudo grub-install --version

If /boot/efi is not mounted, stop and fix the install before proceeding. A server that cannot boot after a power cycle is not ready for production.

Set up monitoring for mirror health

RAID is only useful if you notice a degraded mirror before the second disk fails. Install a simple check and log its status.

sudo apt install -y mailutils

If you already have alerting mail configured, create a cron check that reports array state. Open the file:

sudo nano /etc/cron.d/mdadm-health

Paste this content:

SHELL=/bin/bash
PATH=/usr/sbin:/usr/bin:/sbin:/bin

*/15 * * * * root cat /proc/mdstat | grep -q "_" && printf '%s\n' "RAID degraded on $(hostname -f)" | mail -s "RAID alert" admin@example.com

Save and exit nano with Ctrl+O, Enter, then Ctrl+X. Replace admin@example.com with your real alert recipient. This example only works if local mail delivery is already configured; for many customers, a better fit is external monitoring tied to a dedicated server plan.

Verify the cron file syntax is acceptable by listing it.

sudo cat /etc/cron.d/mdadm-health

Harden SSH and UFW without locking yourself out

Now you can reduce the attack surface. Add the firewall rule first, test it, and only then adjust SSH.

On the VPS as the non-root sudo user, allow SSH and common web traffic if you need it.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Confirm the rules loaded.

sudo ufw status verbose

Next, harden SSH. Open the server config.

sudo nano /etc/ssh/sshd_config

Set or confirm these lines:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
AllowUsers deploy

Save and exit, then test the syntax before reload.

sudo sshd -t

If that returns no output, the config is valid. Reload SSH carefully.

sudo systemctl reload ssh

Open a third terminal on your local computer and test a fresh login.

ssh deploy@203.0.113.10

Only after that succeeds should you stop using the root SSH session.

Simulate a disk failure and confirm the server stays up

This is the part many people skip. Do not. A mirror that has never been tested has not been proven.

List the array members.

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

Pick one member disk and mark it failed. For example, if /dev/sda3 is a RAID member, simulate a failure like this:

sudo mdadm /dev/md1 --fail /dev/sda3
sudo mdadm /dev/md1 --remove /dev/sda3

Check the degraded status.

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

You should see one active member and one removed or missing member. The system should remain online. If the server hangs or drops services, your boot or mount layout needs work before production use.

Now re-add the same disk. On real hardware, you would replace the failed drive first. For this test, add it back to confirm the resync path.

sudo mdadm /dev/md1 --add /dev/sda3

Watch the rebuild.

watch cat /proc/mdstat

When resync completes, exit with Ctrl+C. A healthy array shows no degraded flag.

Rollback and recovery path

If the mirror creation was wrong, do not try to force it into a broken production state. Reinstall from the rescue console instead. On a fresh Ubuntu image, the clean rollback path is to wipe the test array and reinstall the OS with a corrected storage layout.

If you only need to stop using the degraded test, remove the array member from monitoring and confirm the server boots cleanly after a reboot.

sudo reboot

After the machine comes back, log in again and confirm the mirror assembled automatically.

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

If the array fails to assemble, inspect the initramfs and GRUB path first. Those are usually the cause, not mdadm itself.

Final verification from the server and client

On the VPS as the non-root sudo user, run these checks:

hostname -f
systemctl status ssh --no-pager
sudo ufw status verbose
cat /proc/mdstat
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT

Expected results: SSH is active, the firewall is enabled, the RAID array is clean, and the root filesystem mounts from the mirrored storage.

On your local computer, confirm the SSH path still works after the reboot.

ssh deploy@203.0.113.10 "cat /proc/mdstat && hostname -f"

You should see the remote hostname and the live RAID status in one command. That confirms both login access and array persistence.

Troubleshooting the most common failure points

Array does not appear after reboot: run sudo cat /etc/mdadm/mdadm.conf and sudo update-initramfs -u. If the array definition is missing, re-add it with sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf and reboot again.

SSH reload fails after hardening: run sudo sshd -t. The usual clue is a typo in /etc/ssh/sshd_config. Fix the file, then reload ssh again.

UFW blocks your connection: use the provider console or IPMI/Redfish to regain access, then run sudo ufw status numbered. Add the SSH rule before enabling UFW on a new server.

Rebuild does not start after re-adding the disk: check sudo mdadm --detail /dev/md1. If the disk still appears faulty, replace it physically and then add the new device, not the old one.

FAQ

Should I use RAID 1 or backups?

Use both. RAID 1 keeps the server running after one drive fails. Backups let you recover from deletion, corruption, or a bad deploy.

Can I build RAID 1 on a live production server?

Not safely as a first pass. For a live system, back up the data, schedule downtime, and rebuild from a known-good layout.

Does RAID 1 replace monitoring?

No. A healthy mirror still needs alerting, disk SMART checks, and reboot testing.

What if my server has NVMe drives instead of SATA disks?

The process is the same. Only the device names change, for example /dev/nvme0n1 and /dev/nvme1n1. Verify them with lsblk before you create the array.