Managing and rebuilding software RAID on servers using UEFI boot mode
39 Views
13.01.2026 
Cloud / Dedicated Server (bare metal)
Objective
Redundant Array of Independent Disks (RAID) is a technology that mitigates data loss on a server by replicating data across two or more disks.
The default RAID level for OVHcloud server installations is RAID 1, which doubles the space taken up by your data, effectively halving the useable disk space.
This guide explains how to manage and rebuild software RAID after a disk replacement on a server using UEFI boot mode.
Before we begin, please note that this guide focuses on Dedicated servers that use UEFI as the boot mode. This is the case with modern motherboards. If your server uses the legacy boot (BIOS) mode, refer to this guide: Managing and rebuilding software RAID on servers in legacy boot (BIOS) mode.
To check whether a server runs on legacy BIOS mode or UEFI boot mode, run the following command:
For more information on UEFI, consult the following article.
Requirements
- A dedicated server with a software RAID configuration
- Administrative (sudo) access to the server via SSH
- Understanding of RAID, partitions and GRUB
Throughout this guide, we use the terms primary disk and secondary disk. In this context:
- The primary disk is the disk whose ESP (EFI System Partition) is mounted by Linux.
- The secondary disk(s) are all the other disks in the RAID.
Instructions
When you purchase a new server, you may feel the need to perform a series of tests and actions. One such test could be to simulate a disk failure in order to understand the RAID rebuild process.
Content overview
- Basic Information
- Understanding the EFI System Partition (ESP)
- Simulating a disk failure
- Rebuilding the RAID (with non mirrored ESP)
- Rebuilding the RAID (with mirrored ESP)
- Adding the label to the SWAP partition (if applicable)
Basic Information
In a command line session, type the following code to determine the RAID status:
From the results, we currently have two software RAID devices configured, md2 and md3, with md3 being the larger of the two. md3 consists of two partitions, called nvme0n1p3 and nvme1n1p3.
The [UU] means that all the disks are working normally. A _ would indicate a failed disk.
In other cases, you would get the following results:
The results show three software RAID devices configured, md1, md2 and md3, with md3 being the larger of the three. md3 consists of two partitions, called nvme0n1p3 and nvme1n1p3.
For a server with SATA disks, you would get the following results:
This command shows our RAID volumes, but not the partition sizes. We can find that information using fdisk -l:
fdisk -l
This command can also be used to identify the partition type.
For GPT partitions, line 6 shows: Disklabel type: gpt.
This information can only be seen when the server is in normal mode.
Still going by the results, we see that /dev/md2 consists of 1022 MiB and /dev/md3 contains 474.81 GiB. If we were to run the mount command we can also find out the layout of the disk.
Alternatively, the lsblk command offers a different view of the partitions:
Furthermore, if we run lsblk -f, we obtain more information about these partitions, such as the LABEL and UUID:
Note the devices, partitions, and mount points, as this is important, especially after replacing a disk. This will allow you to verify that the partitions are correctly mounted on their respective mount points on the new disk.
In our example, we have:
- Partitions part of md2 (
/boot): nvme0n1p2 and nvme1n1p2. - Partitions part of md3 (
/): nvme0n1p3 and nvme1n1p3. - Swap partitions: nvme0n1p4 and nvme1n1p4.
- Mounted ESP (
/boot/efi): nvme0n1p1. - Unmounted ESP: nvme1n1p1.
The nvme0n1p5 partition is a config drive, i.e. a read-only volume that provides the server with its initial configuration data. It is only read once during initial boot and can be removed afterwards.
Understanding the EFI System Partition (ESP)
Unfold this section
What is an EFI System Partition?
An EFI System Partition is a partition which can contain the boot loaders, boot managers, or kernel images of an installed operating system. It may also contain system utility programs designed to be run before the operating system boots, as well as data files such as error logs.
Is the EFI System Partition mirrored in RAID?
As of December 2025, only the following OS versions mirror the EFI System Partition in RAID for new installations or reinstallations:
- Debian 13
- Proxmox 9
- Ubuntu 25.10
- AlmaLinux and Rocky Linux 10
- Fedora 43
For earlier versions, the EFI partition is not mirrored in RAID; multiple ESPs are created, one per disk. However, only one ESP is mounted at a time. The ESP is mounted at /boot/efi, and the disk on which it is mounted is selected by Linux at boot.
You can use the lsblk command to confirm whether your partition is part of a RAID setup.
From the above results, only one EFI system partition is mounted at /boot/efi. The ESPs are therefore not mirrored.
From the results above, both EFI system partitions are mounted on /boot/efi. They are therefore mirrored in RAID.
Does the content of the EFI System Partition change regularly?
In general, the contents of this partition do not change much, its content should only change on bootloader (e.g. GRUB) updates.
However, if your EFI partition is not mirrored, we recommend running an automatic or manual script to synchronise all ESPs, so that they all contain the same up-to-date files. This way, if the drive on which this partition is mounted fails, the server will be able to restart on the ESP of one of the other drives.
What if the primary disk (with the mounted EFI system partition) fails?
If your ESP is not mirrored, you may experience the following:
Please note that while we explore the most common cases below, there are several other reasons a server may not start in normal mode after a disk replacement.
Case Study 1 – There have been no changes or major updates (e.g., GRUB) to the OS.
- The server is able to boot in normal mode and you can proceed with the RAID rebuild.
- The server is unable to boot in normal mode, use the rescue mode environment to rebuild the RAID and recreate the EFI partition on the new disk.
Case Study 2 – There have been major system updates (e.g., GRUB), and the ESPs are synchronised.
- The server is able to boot in normal mode because all ESPs are up-to-date, and the RAID rebuild can be performed in normal mode.
- The server is unable to boot in normal mode, use the rescue mode environment to rebuild the RAID and recreate the EFI partition on the new disk.
Case Study 3 – There have been major system updates (e.g. GRUB) to the OS and the ESP partitions have not been synchronised.
- The server is unable to boot in normal mode, use the rescue mode environment to rebuild the RAID, recreate the EFI System Partition on the new disk, and reinstall the bootloader (e.g., GRUB).
- The server can boot in normal mode (for example, when the OS is upgraded but the GRUB version remains unchanged), allowing you to proceed with the RAID rebuild.
In some cases, booting from an out-of-date ESP may fail; for example, a major GRUB update can render the GRUB binary in the ESP incompatible with newer GRUB modules in the /boot partition.
How can I synchronise my EFI System Partitions, and how often should I synchronise them?
If your ESP is not mirrored, consider the following:
Please note that depending on your operating system, the process might differ. For example, Ubuntu can keep multiple EFI System Partitions synchronised with every GRUB update, but it is the only OS that does so. We recommend consulting the official documentation of your OS to understand how to manage ESPs.
In this guide, the operating system used is Debian.
We recommend synchronising your ESPs regularly or after each major system update. By default, all EFI System partitions contain the same files after installation. However, after a major system update, synchronising the ESPs is necessary to ensure the content remains up-to-date.
Running a script is an effective way to keep your partitions regularly synchronised. Below is a script you can use to manually sync your ESPs. Alternatively, you can set up an automated script to sync them daily or whenever the system boots.
Before executing the script, ensure that rsync is installed on your system:
Debian/Ubuntu
CentOS, Red Hat and Fedora
To execute a script in Linux, you need an executable file:
- Start by creating a .sh file in the directory of your choice, replacing
script-namewith the name of your choice:
- Open the file with a text editor and include the following lines:
Save and exit the file.
- Make the script executable:
- Run the script:
- If you are not in the folder:
When the script is executed, the contents of the mounted ESP will be synchronised with the others. You can then mount any unmounted EFI partition at the mount point: /var/lib/grub/esp to access its contents.
Simulating a disk failure
Now that we have the necessary information, we can simulate a disk failure. In this example, we will fail the primary disk nvme0n1 (note this is the disk with the mounted ESP).
The preferred way to do this is via the OVHcloud rescue mode environment.
Reboot the server into rescue mode and log in with the provided credentials.
To remove a disk from the RAID, first mark it as Failed, then remove its partitions from the RAID arrays.
Note: This is just an illustration; adapt the commands to your own configuration.
From the above output, nvme0n1 consists of two partitions in RAID which are nvme0n1p2 and nvme0n1p3.
Removing the failed disk
First, we mark the partitions nvme0n1p2 and nvme0n1p3 as failed:
Next, we run the cat /proc/mdstat command:
As shown above, the [F] next to the partitions indicates that the disk has failed or is faulty.
Next, we remove these partitions from the RAID arrays to fully remove the disk from the RAID.
The RAID status should now look like this:
Now, only two partitions appear in the RAID arrays. We have successfully failed the disk nvme0n1.
To get a disk similar to an empty one, we run the following command on each partition and then on the disk:
The disk now appears as a new, empty drive:
To ensure that the disk has been successfully "wiped":
For more information on how to prepare and request for a disk replacement, consult this guide.
Additionally, if you run the following command, you'll get more details on the RAID arrays:
We can now proceed with the disk replacement and RAID rebuild.
Rebuilding the RAID (with non mirrored ESP)
This process might be different depending on the operating system you have installed on your server. We recommend that you consult the official documentation of your operating system to have access to the proper commands.
If your server is able to boot in normal mode after the disk replacement, simply proceed with the steps from this section if your EFI system partition is not mirrored or this section if your EFI system partition is mirrored.
Rebuilding the RAID after the primary disk is replaced (rescue mode)
Once the disk has been replaced, copy the partition table from the healthy disk (in this example, nvme1n1) to the new one (nvme0n1).
For GPT partitions
The command should be in this format: sgdisk -R /dev/new disk /dev/healthy disk
Example:
Run lsblk to make sure the partition tables have been properly copied:
Next, randomise the GUID of the new disk to prevent GUID conflicts with other disks:
If you receive the message below:
Simply run the partprobe command.
Next, we rebuild the RAID array. The following code snippet shows how to add the new partitions (nvme0n1p2 and nvme0n1p3) back into the RAID array.
To check the rebuild process:
Once the RAID rebuild is complete, run the following command to make sure that the partitions have been properly added to the RAID:
Based on the results above, the partitions on the new disk have been correctly added to the RAID. However, the EFI System Partition and the SWAP partition (in some cases) have not been duplicated, which is normal since they are not included in the RAID.
The examples above are merely illustrating the necessary steps based on a default server configuration. The information in the output table depends on your server's hardware and its partition scheme. When in doubt, consult the documentation of your operating system.
If you require professional assistance with server administration, consider the details in the Go further section of this guide.
Recreating the EFI System Partition
To recreate the EFI system partition on the new disk, we need to format nvme0n1p1 and then replicate the contents of the healthy partition (in our example: nvme1n1p1) onto it.
Here, we assume that both partitions have been synchronised and contain up-to-date files.
If there was a major system update such as kernel or grub and both partitions were not synchronised, consult this section once you are done creating the new EFI System Partition.
First, format the partition:
Next, label the partition as EFI_SYSPART (this naming is specific to OVHcloud):
Next, duplicate the contents of nvme1n1p1 to nvme0n1p1.
Start by creating two folders, named "old" and "new" in this example:
Mount nvme1n1p1 in the 'old' folder and nvme0n1p1 in the 'new' folder to make the distinction:
Copy the files from the 'old' folder to 'new' one:
Once this is done, unmount both partitions:
Next, mount the partition containing the root of the operating system on /mnt. In this example, that partition is md3.
Mount the following directories to ensure that all changes made in the chroot environment work correctly:
Next, use the chroot command to access the mount point and verify that the new ESP has been properly created and that the system recognises both ESPs:
To view the ESP partitions, run the command blkid -t LABEL=EFI_SYSPART:
The results show that the new ESP has been created correctly and that the LABEL has been applied properly.
Once done, exit the chroot environment:
Next, consult this section to recreate the SWAP partition (if applicable).
Rebuilding RAID with unsynchronised ESPs after major system updates (GRUB)
Unfold this section
Only follow the steps in this section if they apply to your case.
If the primary disk is replaced while it contains EFI system partitions that have not been synchronised after major system updates that have modified the GRUB, booting from one of the secondary disks with an obsolete ESP may fail.
In this case, along with rebuilding the RAID and recreating the EFI system partition in rescue mode, you must also reinstall GRUB on it.
Once the ESP has been created (as explained above) and the system recognises both partitions, still in the chroot environment, create the /boot/efi folder to mount the new EFI system partition nvme0n1p1:
Next, reinstall the GRUB bootloader:
Then, run the following command:
Once done, exit the chroot environment:
Next, consult this section to recreate the SWAP partition (if applicable).
Rebuilding the RAID after the primary disk is replaced (normal mode)
Unfold this section
If your server is able to boot in normal mode after the primary disk is replaced, proceed with the following steps to rebuild the RAID.
Once the disk is replaced, copy the partition table from the healthy disk (in this example, nvme1n1) to the new disk (nvme0n1).
For GPT partitions
The command should be in this format: sgdisk -R /dev/new disk /dev/healthy disk.
Next, randomise the GUID of the new disk to prevent GUID conflicts with other disks:
If you receive the following message:
Simply run the partprobe command. If you still cannot see the newly-created partitions (by running lsblk), you need to reboot the server before continuing.
Next, add the partitions to the RAID:
Use the following command to monitor the RAID rebuild:
Once the rebuild is done, recreate the EFI System Partition on the new disk.
- First, make sure the necessary tools are installed:
Debian and Ubuntu
CentOS
- Format the partition. In our example
nvme0n1p1:
- Label the partition as
EFI_SYSPART(this naming is specific to OVHcloud):
Once done, synchronise both partitions using the script provided in this guide.
- Verify that the new EFI System Partition has been properly created and the system recognises it:
Next, consult this section to recreate the SWAP partition (if applicable).
Rebuilding the RAID (with mirrored ESP)
Unfold this section
Rebuilding the RAID with all partitions mirrored is easier; simply copy the data from the healthy disk to the new disk and recreate the [SWAP] partition (if applicable).
From the illustrations above, the RAID status should like this after a disk failure:
After the disk is replaced, the first step is to copy the partition table from the healthy disk (in this example, nvme1n1) to the new one (nvme0n1).
For GPT partitions
The command should be in this format: sgdisk -R /dev/new disk /dev/healthy disk.
In our example:
Run lsblk to make sure the partition tables have been properly copied:
Next, randomise the GUID of the new disk to prevent GUID conflicts with other disks:
If you receive the message below:
Simply run the partprobe command.
We can now rebuild the RAID array. The following code snippet shows how to add the new partitions (nvme0n1p1, nvme0n1p2 and nvme0n1p3) back in the RAID array.
To check the rebuild process:
Once the rebuild is complete, run the following command to make sure that the partitions have been properly added to the RAID:
Once done, consult this section to recreate the SWAP partition (if applicable).
From the illustrations above, the RAID status should look like this after a disk failure:
Once the disk is replaced, copy the partition table from the healthy disk (in this example, nvme1n1) to the new disk (nvme0n1).
For GPT partitions
The command should be in this format: sgdisk -R /dev/new disk /dev/healthy disk.
Next, randomise the GUID of the new disk to prevent GUID conflicts with other disks:
If you receive the following message:
Simply run the partprobe command. If you still cannot see the newly-created partitions (e.g. with lsblk), you need to reboot the server before continuing.
Next, add the partitions to the RAID:
Use the following command to monitor the RAID rebuild:
Once the raid rebuild is complete, consult this section to recreate the SWAP partition (if applicable).
Adding the label to the SWAP partition (if applicable)
Unfold this section
Outside the chroot environment, recreate the [SWAP] partition nvme0n1p4 and add the label swap-nvmenxxx:
Verify that the label has been properly applied:
Access the chroot environment again:
Retrieve the UUID of both SWAP partitions:
Next, replace the old UUID of the SWAP partition (nvme0n1p4) with the new one in the /etc/fstab file:
Example:
Based on the above results, the old UUID is b7b5dd38-9b51-4282-8f2d-26c65e8d58ec and should be replaced with the new one b3c9e03a-52f5-4683-81b6-cc10091fcd15. Make sure you replace the correct UUID.
Next, verify that everything is properly mounted with the following command:
Activate the SWAP partition:
Exit the chroot environment with exit and reload the system:
Unmount all the disks:
To recreate the SWAP partition, perform the following steps:
- First, recreate the partition on nvme0n1p4 and add the label swap-nvme0n1p4:
- Retrieve the UUIDs of both SWAP partitions:
- Replace the old UUID of the SWAP partition (nvme0n1p4) with the new one in
/etc/fstab:
Example:
Based on the above results, the old UUID is b7b5dd38-9b51-4282-8f2d-26c65e8d58ec and should be replaced with the new one b3c9e03a-52f5-4683-81b6-cc10091fcd15.
Make sure to replace the correct UUID.
Next, run the following command to activate the SWAP partition:
Next, reload the system:
We have now completed the RAID rebuild.
Go Further
For specialised services (SEO, development, etc.), contact OVHcloud partners.
If you would like assistance using and configuring your OVHcloud solutions, please refer to our support offers.
If you need training or technical assistance to implement our solutions, contact your sales representative or click on this link to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project.
Join our community of users.
Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode
3432