Choosing a RAID layout for your dedicated server

Every dedicated server and GPU server with two or more data disks can be delivered with its disks already combined into a RAID array. You choose the layout on the deploy page, next to the operating system; our team builds the array before delivery, so the server comes up with the space and the redundancy you picked. This guide explains each layout, what it costs in usable space, and how to look after the array once the server is yours.

The layouts at a glance

The deploy page shows the usable space of each layout for the server you picked. As a reference, with disks of the same size S:

On a Ryzen 7 7700 with 2 × 1 TB NVMe, RAID 1 gives 1 TB and RAID 0 gives 2 TB. On a Storage 40 TB with 4 × 10 TB hard drives, RAID 6 and RAID 10 give 20 TB, RAID 5 gives 30 TB and RAID 0 gives 40 TB. On a Storage 60 TB with 6 × 10 TB, RAID 6 gives 40 TB, RAID 10 30 TB and RAID 5 50 TB.

What we recommend

The layout marked Recommended on the deploy page is the one we would pick for ourselves:

• Two disks: RAID 1. Half the space, but a failed disk is a ticket, not an outage. Reads get faster too, since both disks can serve them.
• Four or more NVMe or SSD disks: RAID 10. Flash disks rebuild a mirror in an hour or two rather than a day, and RAID 10 has no parity to compute, so writes stay fast under load. It is the classic layout for databases.
• Storage servers with large hard drives: RAID 6. Rebuilding a 10 TB hard drive takes a day or more, during which every other disk is read end to end. With RAID 5, a second failure or an unreadable sector during that window loses the array; RAID 6 survives it.

Pick RAID 0 only when losing the whole array costs you nothing but time, for example a render cache or a copy of a dataset that lives elsewhere. Pick RAID 5 only for data you can rebuild from another copy.

How we set it up

• Linux distributions: Linux software RAID (mdadm). On two-disk servers the whole system lives on the array. On storage servers, the operating system goes on the separate SSD and the hard-drive array is mounted at /data.
• Proxmox VE: a ZFS pool with the same redundancy (mirror, striped mirrors or RAID-Z2), which Proxmox manages natively.
• Windows Server and custom ISOs: the disks are delivered separate. With Windows, pool them with Storage Spaces or mirror them in Disk Management; with your own ISO, set them up during the install from the IPMI console.

Software RAID costs a negligible amount of CPU on these processors, survives a mainboard swap (the array is read from the disks, not from a controller), and every tool below works on it.

Check the array

A healthy mdadm array lists every member as up, shown as [UU] for two disks or [UUUU] for four:

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

An underscore, as in [U_], means a member is missing: the array still works but has lost its redundancy. On Proxmox, check the pool instead:

zpool status

Look at the health of the disks themselves with smartmontools. Reallocated or pending sectors that grow from one week to the next announce a failing disk:

apt install -y smartmontools
smartctl -H -A /dev/sda
smartctl -H -A /dev/nvme0

We never email you, so have the server tell you: a daily cron job that runs mdadm --detail --test /dev/md0 and alerts your own monitoring when it exits with a non-zero status is enough.

When a disk fails

1. Note the serial number of the failed disk: smartctl -i /dev/sdX shows it, and mdadm --detail tells you which member dropped out.
2. Open a ticket from your server's page in the client area with the serial number and the output of cat /proc/mdstat. Tell us whether the server may be powered off for the swap; many chassis allow a hot swap.
3. Once the new disk is in, copy the partition table of a healthy disk onto it, give the copy new identifiers, and add it back to the array. The rebuild starts at once, and you can follow it in /proc/mdstat. Here /dev/sda is the healthy disk and /dev/sdb the new one; on NVMe servers the names look like /dev/nvme1n1 and /dev/nvme1n1p1.

apt install -y gdisk
sgdisk --replicate=/dev/sdb /dev/sda
sgdisk --randomize-guids /dev/sdb
mdadm --manage /dev/md0 --add /dev/sdb1

On a two-disk server that boots from the array, make the new disk bootable too: run grub-install /dev/sdb on a BIOS system, or copy the EFI partition of the healthy disk onto the new one on a UEFI system. Otherwise the server cannot start if the old disk fails next.

RAID is not a backup

RAID protects you from one thing: a disk that dies. It copies every mistake as faithfully as your data, so a deleted directory, a corrupted database, ransomware or a server you lose access to take the whole array with them. Keep encrypted off-site copies with restic or Borg, as shown in the backup section of the snapshots guide, on another server or in another of our locations.

Changing the layout later

Changing the RAID level of an array that holds data is slow and risky, so treat the layout as a choice for the life of the server. To start over, reinstall from the IPMI console with the layout you want, or ask by ticket for a reinstall with a new layout before you put data on the server. A reinstall erases the disks, so copy anything you need first.