diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.de-de.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.de-de.md index faea64a9352..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.de-de.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.de-de.md @@ -1,32 +1,74 @@ --- -title: Software-RAID konfigurieren und neu erstellen -excerpt: "Erfahren Sie hier, wie Sie den Status des Software-RAID Ihres Servers überprüfen und im Fall eines Hardware-Austausches rekonfigurieren" -updated: 2022-10-11 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Diese Übersetzung wurde durch unseren Partner SYSTRAN automatisch erstellt. In manchen Fällen können ungenaue Formulierungen verwendet worden sein, z.B. bei der Beschriftung von Schaltflächen oder technischen Details. Bitte ziehen Sie im Zweifelsfall die englische oder französische Fassung der Anleitung zu Rate. Möchten Sie mithelfen, diese Übersetzung zu verbessern? Dann nutzen Sie dazu bitte den Button "Beitragen" auf dieser Seite. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + +## Requirements + +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions + +## 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 and prepare yourself in case it ever happens. -## Ziel +### Content overview -RAID (Redundant Array of Independent Disks) ist ein System, das Datenverlust auf Servern entgegenwirkt, indem es diese Daten auf mehreren Disks speichert. +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -Das RAID Level für OVHcloud Server-Installationen ist standardmäßig RAID-1, was den von Ihren Daten verbrauchten Speicherplatz verdoppelt und somit den nutzbaren Platz halbiert. + -**Diese Anleitung erklärt, wie Sie das RAID Array Ihres Servers konfigurieren, falls dieses aufgrund von Störungen oder Beschädigung neu eingerichtet werden muss.** +### Basic Information -## Voraussetzungen +In a command line session, type the following code to determine the current RAID status: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` -- Sie haben einen [Dedicated Server](/links/bare-metal/bare-metal) mit Software-RAID-Konfiguration. -- Sie haben administrativen Zugriff (sudo) auf Ihren Server über SSH. +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. -## In der praktischen Anwendung +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. -Den aktuellen Status des RAID erhalten Sie über folgenden Befehl: +If you have a server with SATA disks, you would get the following results: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -40,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Dieser Befehl zeigt, dass aktuell zwei RAID Arrays eingerichtet sind, wobei "md4" die größte Partition ist. Diese Partition besteht aus zwei Disks: “sda4” und “sdb4”. `[UU]` zeigt an, dass alle Disks normal funktionieren. Ein “`_`” an dieser Stelle bedeutet, dass eine Disk defekt ist. - -Dieser Befehl zeigt zwar die RAID Disks an, jedoch nicht die Größe der Partitionen selbst. Diese Information erhalten Sie mit folgendem Befehl: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,73 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -Mit dem Befehl `fdisk -l` können Sie auch Ihren Partitionstyp identifizieren. Dies ist eine wichtige Information, die Sie bei der Rekonstruktion Ihres RAID im Falle eines Ausfalls beachten müssen. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -Für **GPT** Partitionen wird zurückgegeben: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -Für **MBR** Partitionen wird zurückgegeben: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Die Ausgabe zeigt, das `/dev/md2` 888,8 GB und `/dev/md4` 973,5 GB enthält. Über den Befehl “mount” erhalten Sie das Layout der Disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` - -Alternativ kann mit dem Befehl `lsblk` eine andere Ansicht zu den Partitionen angezeigt werden: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -173,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Die Disks sind aktuell standardmäßig gemountet. Um eine Disk aus dem RAID zu entfernen, muss diese zuerst ausgehängt und dann ein Fehler simuliert werden, um sie endgültig zu entfernen. Um `/dev/sda4` aus dem RAID zu entfernen, folgen Sie den nachstehenden Schritten und verwenden Sie zunächst folgenden Befehl: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. ```sh -umount /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: ``` -> [!warning] -> Beachten Sie, dass, falls Sie mit dem Account `root` eingeloggt sind, folgende Nachricht erhalten können, wenn Sie versuchen, die Partition zu unmounten (in unserem Fall wird die Partition md4 in `/home` gemountet): -> -> 
umount: /home: target is busy
-> -> Wechseln Sie in diesem Fall zu einem anderen sudo-Benutzer (in diesem Fall `debian`) und verwenden Sie folgenden Befehl: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Wenn Sie noch keine anderen User-Accounts haben, [erstellen Sie einen](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -Als Ergebnis erhalten Sie: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -`/dev/md4` ist nicht länger gemountet. Das RAID ist jedoch noch aktiv. Daher ist es notwendig, einen Fehler zu simulieren, um die Disk zu entfernen. Dies geschieht über folgenden Befehl: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -Somit wurde ein Fehler des RAID simuliert. Im nächsten Schritt wird die Partition mit folgendem Befehl aus dem RAID entfernt: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Um zu überprüfen, ob die Partition entfernt wurde, verwenden Sie folgenden Befehl: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Die Ausgabe des nachfolgenden Befehls bestätigt, dass die Partition entfernt wurde. +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -288,54 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### RAID neu einrichten + -Wenn die Disk ersetzt wurde, kopieren Sie die Partitionstabelle einer funktionsfähigen Disk (in unserem Beispiel “sdb”) zur neuen Disk (“sda”): +### Rebuilding the RAID -**Für GPT Partitionen** +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -Der Befehl muss im folgenden Format sein: `sgdisk -R /dev/newdisk /dev/healthydisk`. +Use the following command to monitor the RAID rebuild: -Nach diesem Vorgang ist der nächste Schritt, die GUID für die neue Disk zu randomisieren, um Konflikte mit anderen Disks zu vermeiden: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**Für MBR Partitionen** +Next, retrieve the UUIDs of both swap partitions: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -Der Befehl muss im folgenden Format sein: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -Jetzt können Sie das RAID Array neu konfigurieren. Der nachstehende Code zeigt, wie das Layout der Partition `/dev/md4` mit der zuvor kopierten Partitionstabelle von “sda” wiederhergestellt werden kann: +Example: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: + +```sh +[user@server_ip ~]# sudo systemctl daemon-reload +``` + +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` + +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Überprüfen Sie die Details des RAID mit folgendem Befehl: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,24 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 ``` -Das RAID wurde neu eingerichtet. Mounten Sie die Partition (in diesem Beispiel `/dev/md4`) mit folgendem Befehl: + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. ```sh -mount /dev/md4 /home +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt ``` -## Weiterführende Informationen +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) + +[OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) (Englisch) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) -[OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) (Englisch) +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) -[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard)(Englisch) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). -[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) (Englisch) +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Für den Austausch mit unserer User Community gehen Sie auf . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-asia.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-asia.md index de7a4d03eeb..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-asia.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-asia.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements - A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-au.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-au.md index 0de4ca168ec..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-au.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-au.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ca.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ca.md index 0de4ca168ec..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ca.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ca.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-gb.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-gb.md index 89e4dac2e54..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-gb.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-gb.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of the software RAID of your server and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ie.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ie.md index 0de4ca168ec..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ie.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-ie.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-sg.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-sg.md index 0de4ca168ec..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-sg.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-sg.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-us.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-us.md index 0de4ca168ec..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-us.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.en-us.md @@ -1,7 +1,7 @@ --- -title: How to configure and rebuild software RAID -excerpt: Find out how to verify the state of your software RAID and rebuild it after a disk replacement -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- ## Objective @@ -10,21 +10,65 @@ Redundant Array of Independent Disks (RAID) is a technology that mitigates data 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 configure your server’s RAID array in the event that it needs to be rebuilt due to corruption or disk failure.** +**This guide explains how to manage and rebuild a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` ## Requirements -- A [dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration - Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions ## Instructions -### Removing the disk +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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -38,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -This command shows us that we have two RAID arrays currently set up, with md4 being the largest partition. The partition consists of two disks, which are known as sda4 and sdb4. The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. - Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,71 +129,14 @@ I/O size (minimum/optimal): 512 bytes / 512 bytes The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -For **GPT** partitions, the command will return: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` - -For **MBR** partitions, the command will return: `Disklabel type: dos`. - -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -We can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. If we were to run the mount command we can also find out the layout of the disk. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -171,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -As the disks are currently mounted by default, to remove a disk from the RAID, we first need to unmount the disk, then simulate a failure, and finally remove it. We will remove `/dev/sda4` from the RAID with the following command: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Please note that if you are connected as the user `root`, you may get the following message when you try to unmount the partition (in our case, where our md4 partition is mounted in /home): -> -> 
umount: /home: target is busy
-> -> In this case, you must log out as the user root and connect as a local user (in our case `debian`), and use the following command: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> If you do not have a local user, you need to [create one](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -This will provide us with the following output: +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -As we can see the, entry of `/dev/md4` is no longer mounted. However, the RAID is still active, so we need to simulate a failure to remove the disk. We can do this with the following command: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -We have now simulated a failure of the RAID. The next step is to remove the partition from the RAID array with the following command: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -You can verify that the partition has been removed with the following command: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -The following command will verify that the partition has been removed: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -286,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` + + ### Rebuilding the RAID -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> -**For GPT partitions** + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 ``` -The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +Use the following command to monitor the RAID rebuild: -Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 ``` -**For MBR partitions** +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Once the disk has been replaced, we need to copy the partition table from a healthy disk (in this example, sdb) to the new one (sda) with the following command: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. + +Example: + +```sh +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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 coorect UUID. + +Next, we verify that everything is properly mounted with the following command: + +```sh +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` + +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -We can now rebuild the RAID array. The following code snippet shows how we can rebulid the `/dev/md4` partition layout with the recently-copied sda partition table: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -We can verify the RAID details with the following command: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -362,16 +577,118 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -The RAID has now been rebuilt, but we still need to mount the partition (`/dev/md4` in this example) with the following command: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + ## Go Further [Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -382,4 +699,10 @@ mount /dev/md4 /home [Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-es.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-es.md index ccf7a08920c..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-es.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-es.md @@ -1,34 +1,74 @@ --- -title: Configuración y reconstrucción del RAID por software -excerpt: "Cómo verificar el estado del RAID por software de su servidor y reconstruirlo después de un reemplazo de disco" -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Esta traducción ha sido generada de forma automática por nuestro partner SYSTRAN. En algunos casos puede contener términos imprecisos, como en las etiquetas de los botones o los detalles técnicos. En caso de duda, le recomendamos que consulte la versión inglesa o francesa de la guía. Si quiere ayudarnos a mejorar esta traducción, por favor, utilice el botón «Contribuir» de esta página. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** -## Objetivo +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). -El RAID (Redundant Array of Independent Disks) es un conjunto de técnicas diseñadas para prevenir la pérdida de datos en un servidor, replicándolos en varios discos. +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` -El nivel de RAID por defecto en los servidores de OVHcloud es RAID 1. Con este nivel de RAID, el volumen que ocupan los datos se duplica, por lo que el espacio en disco útil se reduce a la mitad. +## Requirements -**Esta guía explica cómo configurar el RAID de un servidor en caso de que sea necesario reconstruirlo por corrupción o fallo del disco.** +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions -## Requisitos +## Instructions -- Tener un [servidor dedicado](/links/bare-metal/bare-metal) con RAID por software. -- Tener acceso al servidor por SSH como administrador (sudo). +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 and prepare yourself in case it ever happens. -## Procedimiento +### Content overview -### Eliminación del disco +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -Para comprobar el estado actual del RAID, utilice el siguiente comando: + + +### Basic Information + +In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -42,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Este comando muestra dos conjuntos RAID configurados actualmente. La partición de mayor tamaño es **md4**, y está formada por dos discos llamados **sda4** y **sdb4**. **[UU]** significa que todos los discos funcionan con normalidad. Un guion bajo (**_**) indicaría un fallo en un disco. - -Aunque este comando muestra los volúmenes RAID, no indica el tamaño de las particiones. Para obtener esta información, utilice el siguiente comando: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -89,73 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -El comando `fdisk -l` también le permite identificar su tipo de partición. Esta es una información importante que deberá conocer cuando se trate de reconstruir su RAID en caso de fallo de un disco. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -Para las particiones **GPT**, el comando devolverá: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -Para las particiones **MBR**, el comando devolverá: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Este comando muestra que **/dev/md2** contiene 888,8 GB y **/dev/md4** contiene 973,5 GB. Para ver la disposición del disco, ejecute el comando `mount`. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosed,nodev,noexec,relatime) -proc on /proc type proc (rw,nosed,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosed,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosed,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosed,noexec,relatime,size=326656k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosed,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosed,nodev) -tmpfs on /run/lock type tmpfs (rw,nosed,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosed,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified tipo cgroup2 (rw,nosed,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosed,nodev,noexec,relatime,xlute,name=systemd) -pstore on /sys/fs/pstore tipo pstore (rw,nosed,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosed,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosed,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosed,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosed,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosed,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosed,nodev,noexec,relatime,net_cls,net_prio) -cpuacct on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosed,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosed,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosed,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosed,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosed,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw, relatime, pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosed,nodev,relatime,size=326652k,mode=700,uid=1000,gid=1000) -``` - -Como alternativa, el comando `lsblk` ofrece una vista diferente de las particiones: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -175,91 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Ahora los discos están montados. Para sacar un disco del RAID, es necesario desmontar el disco en primer lugar y luego marcarlo como defectuoso para poder eliminarlo. -A continuación, podrá sacar **/dev/sda4** del RAID. +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. ```sh -umount /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: ``` -> [!warning] -> Tenga en cuenta que, si está conectado como usuario `root`, puede obtener el siguiente mensaje cuando intente desmontar la partición (en nuestro caso, la partición md4 está montada en /home): -> -> 
umount: /home: target is busy
-> -> En ese caso, deberá desconectarse como usuario root y conectarse como usuario local (en nuestro caso, `debian`) y utilizar el siguiente comando: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Si no tiene un usuario local, [debe crear uno](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -Obtendrá la siguiente respuesta: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -La entrada **/dev/md4** ya no está montada. Sin embargo, el RAID sigue activo. Para poder retirar el disco, debe marcarlo como defectuoso con el siguiente comando: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -De este modo, hemos simultado un fallo del RAID. Ya puede proceder a eliminar la partición del RAID con el siguiente comando: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Para comprobar el nuevo estado del RAID, utilice el siguiente comando: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -El siguiente comando permite comprobar que la partición se ha eliminado: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -291,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Reconstrucción del RAID + + +### Rebuilding the RAID + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Use the following command to monitor the RAID rebuild: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: + +```sh +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 +``` + +Next, retrieve the UUIDs of both swap partitions: -Una vez sustituido el disco, copie la tabla de particiones desde un disco « sano » (**sdb** en el ejemplo) a la nueva partición (**sda**) con el siguiente comando: +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -**Para las particiones GPT** +Example: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 ``` -El comando debe tener el siguiente formato: `sgdisk -R /dev/newdisk /dev/healthydisk`. +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 coorect UUID. -Una vez realizada esta operación, podrá aleatoriamente utilizar el GUID del nuevo disco para evitar cualquier conflicto de GUID con el resto de discos: +Next, we verify that everything is properly mounted with the following command: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -**Para las particiones MBR** +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` -Una vez sustituido el disco, copie la tabla de particiones desde un disco sano (**sdb** en el ejemplo) en la nueva partición (**sda**) con el siguiente comando: +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -El comando debe tener el siguiente formato: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -Ya puede reconstruir el RAID. El siguiente fragmento de código muestra cómo reconstruir la disposición de la partición **/dev/md4** con la tabla de particiones « sda » anteriormente copiada: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Para comprobar los detalles del RAID, utilice el siguiente comando: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -367,22 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -Una vez reconstruido el RAID, monte la partición (**/dev/md4**, en el ejemplo) con el siguiente comando: +Activate the swap partition the following command: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 ``` -## Más información +We exit the `chroot` environment with exit and reload the system: -[Sustituir un disco en caliente en un servidor con RAID por software](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) [OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[RAID por hardware](/pages/bare_metal_cloud/dedicated_servers/raid_hard) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Interactúe con nuestra comunidad de usuarios en . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-us.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-us.md index ccf7a08920c..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-us.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.es-us.md @@ -1,34 +1,74 @@ --- -title: Configuración y reconstrucción del RAID por software -excerpt: "Cómo verificar el estado del RAID por software de su servidor y reconstruirlo después de un reemplazo de disco" -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Esta traducción ha sido generada de forma automática por nuestro partner SYSTRAN. En algunos casos puede contener términos imprecisos, como en las etiquetas de los botones o los detalles técnicos. En caso de duda, le recomendamos que consulte la versión inglesa o francesa de la guía. Si quiere ayudarnos a mejorar esta traducción, por favor, utilice el botón «Contribuir» de esta página. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** -## Objetivo +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). -El RAID (Redundant Array of Independent Disks) es un conjunto de técnicas diseñadas para prevenir la pérdida de datos en un servidor, replicándolos en varios discos. +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` -El nivel de RAID por defecto en los servidores de OVHcloud es RAID 1. Con este nivel de RAID, el volumen que ocupan los datos se duplica, por lo que el espacio en disco útil se reduce a la mitad. +## Requirements -**Esta guía explica cómo configurar el RAID de un servidor en caso de que sea necesario reconstruirlo por corrupción o fallo del disco.** +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions -## Requisitos +## Instructions -- Tener un [servidor dedicado](/links/bare-metal/bare-metal) con RAID por software. -- Tener acceso al servidor por SSH como administrador (sudo). +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 and prepare yourself in case it ever happens. -## Procedimiento +### Content overview -### Eliminación del disco +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -Para comprobar el estado actual del RAID, utilice el siguiente comando: + + +### Basic Information + +In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -42,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Este comando muestra dos conjuntos RAID configurados actualmente. La partición de mayor tamaño es **md4**, y está formada por dos discos llamados **sda4** y **sdb4**. **[UU]** significa que todos los discos funcionan con normalidad. Un guion bajo (**_**) indicaría un fallo en un disco. - -Aunque este comando muestra los volúmenes RAID, no indica el tamaño de las particiones. Para obtener esta información, utilice el siguiente comando: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -89,73 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -El comando `fdisk -l` también le permite identificar su tipo de partición. Esta es una información importante que deberá conocer cuando se trate de reconstruir su RAID en caso de fallo de un disco. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -Para las particiones **GPT**, el comando devolverá: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -Para las particiones **MBR**, el comando devolverá: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Este comando muestra que **/dev/md2** contiene 888,8 GB y **/dev/md4** contiene 973,5 GB. Para ver la disposición del disco, ejecute el comando `mount`. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosed,nodev,noexec,relatime) -proc on /proc type proc (rw,nosed,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosed,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosed,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosed,noexec,relatime,size=326656k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosed,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosed,nodev) -tmpfs on /run/lock type tmpfs (rw,nosed,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosed,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified tipo cgroup2 (rw,nosed,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosed,nodev,noexec,relatime,xlute,name=systemd) -pstore on /sys/fs/pstore tipo pstore (rw,nosed,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosed,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosed,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosed,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosed,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosed,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosed,nodev,noexec,relatime,net_cls,net_prio) -cpuacct on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosed,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosed,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosed,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosed,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosed,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw, relatime, pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosed,nodev,relatime,size=326652k,mode=700,uid=1000,gid=1000) -``` - -Como alternativa, el comando `lsblk` ofrece una vista diferente de las particiones: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -175,91 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Ahora los discos están montados. Para sacar un disco del RAID, es necesario desmontar el disco en primer lugar y luego marcarlo como defectuoso para poder eliminarlo. -A continuación, podrá sacar **/dev/sda4** del RAID. +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. ```sh -umount /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: ``` -> [!warning] -> Tenga en cuenta que, si está conectado como usuario `root`, puede obtener el siguiente mensaje cuando intente desmontar la partición (en nuestro caso, la partición md4 está montada en /home): -> -> 
umount: /home: target is busy
-> -> En ese caso, deberá desconectarse como usuario root y conectarse como usuario local (en nuestro caso, `debian`) y utilizar el siguiente comando: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Si no tiene un usuario local, [debe crear uno](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -Obtendrá la siguiente respuesta: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -La entrada **/dev/md4** ya no está montada. Sin embargo, el RAID sigue activo. Para poder retirar el disco, debe marcarlo como defectuoso con el siguiente comando: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -De este modo, hemos simultado un fallo del RAID. Ya puede proceder a eliminar la partición del RAID con el siguiente comando: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Para comprobar el nuevo estado del RAID, utilice el siguiente comando: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -El siguiente comando permite comprobar que la partición se ha eliminado: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -291,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Reconstrucción del RAID + + +### Rebuilding the RAID + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Use the following command to monitor the RAID rebuild: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: + +```sh +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 +``` + +Next, retrieve the UUIDs of both swap partitions: -Una vez sustituido el disco, copie la tabla de particiones desde un disco « sano » (**sdb** en el ejemplo) a la nueva partición (**sda**) con el siguiente comando: +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -**Para las particiones GPT** +Example: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 ``` -El comando debe tener el siguiente formato: `sgdisk -R /dev/newdisk /dev/healthydisk`. +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 coorect UUID. -Una vez realizada esta operación, podrá aleatoriamente utilizar el GUID del nuevo disco para evitar cualquier conflicto de GUID con el resto de discos: +Next, we verify that everything is properly mounted with the following command: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -**Para las particiones MBR** +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` -Una vez sustituido el disco, copie la tabla de particiones desde un disco sano (**sdb** en el ejemplo) en la nueva partición (**sda**) con el siguiente comando: +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -El comando debe tener el siguiente formato: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -Ya puede reconstruir el RAID. El siguiente fragmento de código muestra cómo reconstruir la disposición de la partición **/dev/md4** con la tabla de particiones « sda » anteriormente copiada: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Para comprobar los detalles del RAID, utilice el siguiente comando: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -367,22 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -Una vez reconstruido el RAID, monte la partición (**/dev/md4**, en el ejemplo) con el siguiente comando: +Activate the swap partition the following command: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 ``` -## Más información +We exit the `chroot` environment with exit and reload the system: -[Sustituir un disco en caliente en un servidor con RAID por software](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) [OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[RAID por hardware](/pages/bare_metal_cloud/dedicated_servers/raid_hard) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Interactúe con nuestra comunidad de usuarios en . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-ca.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-ca.md index 811e36b6932..7173ac0de0f 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-ca.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-ca.md @@ -1,7 +1,7 @@ --- -title: Configuration et reconstruction du RAID logiciel -excerpt: "Découvrez comment vérifier l'état du RAID logiciel de votre serveur et le reconstruire après un remplacement de disque" -updated: 2023-08-21 +title: Gestion et reconstruction du RAID logiciel sur les serveurs en mode legacy boot (BIOS) +excerpt: "Découvrez comment gérer et reconstruire le RAID logiciel après un remplacement de disque sur votre serveur en mode legacy boot (BIOS)" +updated: 2025-12-11 --- ## Objectif @@ -10,23 +10,66 @@ Le RAID (Redundant Array of Independent Disks) est un ensemble de techniques pr Le niveau RAID par défaut pour les installations de serveurs OVHcloud est RAID 1, ce qui double l'espace occupé par vos données, réduisant ainsi de moitié l'espace disque utilisable. -**Ce guide va vous aider à configurer la matrice RAID de votre serveur dans l'éventualité où elle doit être reconstruite en raison d'une corruption ou d'une panne de disque.** +**Ce guide explique comment gérer et reconstruire un RAID logiciel en cas de remplacement d'un disque sur votre serveur en mode legacy boot (BIOS).** +Avant de commencer, veuillez noter que ce guide se concentre sur les serveurs dédiés qui utilisent le mode legacy boot (BIOS). Si votre serveur utilise le mode UEFI (cartes mères plus récentes), reportez-vous à ce guide [Gestion et reconstruction du RAID logiciel sur les serveurs en mode boot UEFI](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +Pour vérifier si un serveur s'exécute en mode BIOS ou en mode UEFI, exécutez la commande suivante : + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + ## Prérequis - Posséder un [serveur dédié](/links/bare-metal/bare-metal) avec une configuration RAID logiciel. - Avoir accès à votre serveur via SSH en tant qu'administrateur (sudo). +- Compréhension du RAID et des partitions ## En pratique -### Retrait du disque +### Présentation du contenu + +- [Informations de base](#basicinformation) +- [Simuler une panne de disque](#diskfailure) + - [Retrait du disque défaillant](#diskremove) +- [Reconstruction du RAID](#raidrebuild) + - [Reconstruction du RAID en mode rescue](#rescuemode) + - [Ajout du label à la partition SWAP (le cas échéant)](#swap-partition) + - [Reconstruction du RAID en mode normal](#normalmode) + + + + +### Informations de base + +Dans une session de ligne de commande, tapez le code suivant pour déterminer l'état actuel du RAID. + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +Cette commande nous indique que deux périphériques RAID logiciels sont actuellement configurés, **md4** étant le plus grand. Le périphérique RAID **md4** se compose de deux partitions, appelées **nvme1n1p4** et **nvme0n1p4**. + +Le [UU] signifie que tous les disques fonctionnent normalement. Un `_` indique un disque défectueux. -La vérification de l’état actuel du RAID s’effectue via la commande suivante : +Si vous possédez un serveur avec des disques SATA, vous obtenez les résultats suivants : ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -40,12 +83,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Cette commande montre deux matrices RAID actuellement configurées, « md4 » étant la plus grande partition. La partition se compose de deux disques, appelés « sda4 » et « sdb4 ». Le [UU] signifie que tous les disques fonctionnent normalement. Un « _ » indiquerait un disque défectueux. - -Bien que cette commande affiche les volumes RAID, elle n'indique pas la taille des partitions elles-mêmes. Vous pouvez obtenir cette information via la commande suivante : +Bien que cette commande renvoie nos volumes RAID, elle ne nous indique pas la taille des partitions elles-mêmes. Nous pouvons retrouver cette information avec la commande suivante : ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,73 +128,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -La commande `fdisk -l` vous permet également d'identifier votre type de partition. C'est une information importante à connaître lorsqu'il s'agit de reconstruire votre RAID en cas de défaillance d'un disque. - -Pour les partitions **GPT**, la commande retournera : `Disklabel type: gpt`. - -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +La commande `fdisk -l` vous permet également d'identifier votre type de partition. Il s’agit d’une information importante pour reconstruire votre RAID en cas de défaillance d’un disque. -Pour les partitions **MBR**, la commande retournera : `Disklabel type: dos`. +Pour les partitions **GPT**, la ligne 6 affichera : `Disklabel type: gpt`. Ces informations ne sont visibles que lorsque le serveur est en mode normal. -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Cette commande montre que `/dev/md2` se compose de 888,8 Go et `/dev/md4` contient 973,5 Go. Exécuter la commande « mount » montre la disposition du disque. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Toujours en se basant sur les résultats de `fdisk -l`, on peut voir que `/dev/md2` se compose de 888.8GB et `/dev/md4` contient 973.5GB. Alternativement, la commande `lsblk` offre une vue différente des partitions : ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -173,91 +157,141 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Les disques sont actuellement montés par défaut. Pour retirer un disque du RAID, vous devez dans un premier temps démonter le disque, puis simuler un échec pour enfin le supprimer. -Nous allons supprimer `/dev/sda4` du RAID avec la commande suivante : +Nous prenons en compte les périphériques, les partitions et leurs points de montage. À partir des commandes et des résultats ci-dessus, nous avons : + +- Deux baies RAID : `/dev/md2` et `/dev/md4`. +- Quatre partitions font partie du RAID avec les points de montage : `/` et `/home`. + + + +### Simuler une panne de disque + +Maintenant que nous disposons de toutes les informations nécessaires, nous pouvons simuler une panne de disque et poursuivre les tests. Dans cet exemple, nous allons faire échouer le disque `sda`. + +Le moyen privilégié pour y parvenir est l’environnement en mode rescue d’OVHcloud. + +Redémarrez d'abord le serveur en mode rescue et connectez-vous avec les informations d'identification fournies. + +Pour retirer un disque du RAID, la première étape consiste à le marquer comme **Failed** et à retirer les partitions de leurs matrices RAID respectives. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +À partir de la sortie ci-dessus, sda se compose de deux partitions en RAID qui sont **sda2** et **sda4**. + + + +#### Retrait du disque défaillant + +Nous commençons par marquer les partitions **sda2** et **sda4** comme **failed**. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Veuillez noter que si vous êtes connecté en tant qu'utilisateur `root`, vous pouvez obtenir le message suivant lorsque vous essayez de démonter la partition (dans notre cas, où notre partition md4 est montée dans /home) : -> -> 
umount: /home: target is busy
-> -> Dans ce cas, vous devez vous déconnecter en tant qu'utilisateur root et vous connecter en tant qu'utilisateur local (dans notre cas, `debian`) et utiliser la commande suivante : -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Si vous ne disposez pas d'utilisateur local, [vous devez en créer un](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -Le résultat obtenu sera le suivant : +Nous avons maintenant simulé une défaillance du RAID, lorsque nous exécutons la commande `cat /proc/mdstat`, nous obtenons le résultat suivant : ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Comme nous pouvons le voir ci-dessus, le [F] à côté des partitions indique que le disque est défaillant ou défectueux. + +Ensuite, nous retirons ces partitions des baies RAID. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -L'entrée de `/dev/md4` n'est maintenant plus montée. Cependant, le RAID est toujours actif. Il est donc nécessaire de simuler un échec pour retirer le disque, ce qui peut être effectué grâce à la commande suivante : +Pour nous assurer que nous obtenons un disque qui est similaire à un disque vide, nous utilisons la commande suivante. Remplacez **sda** par vos propres valeurs : ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -Nous avons maintenant simulé un échec du RAID. L'étape suivante consiste à supprimer la partition du RAID avec la commande suivante : +Si nous exécutons la commande suivante, nous voyons que notre disque a été correctement « nettoyé » : ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Vous pouvez vérifier que la partition a été supprimée avec la commande suivante : +L'état de notre RAID devrait maintenant ressembler à ceci : ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -La commande ci-dessous vérifie que la partition a été supprimée : +Les résultats ci-dessus montrent que seules deux partitions apparaissent désormais dans les matrices RAID. Nous avons réussi à faire échouer le disque **sda** et nous pouvons maintenant procéder au remplacement du disque. + +Pour plus d'informations sur la préparation et la demande de remplacement d'un disque, consultez ce [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +La commande suivante permet d'avoir plus de détails sur la ou les matrices RAID : ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -289,56 +323,200 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Reconstruction du RAID + + +### Reconstruire le RAID + +> [!warning] +> +> Pour la plupart des serveurs en RAID logiciel, après un remplacement de disque, le serveur est capable de démarrer en mode normal (sur le disque sain) pour reconstruire le RAID. Cependant, si le serveur ne parvient pas à démarrer en mode normal, il sera redémarré en mode rescue pour procéder à la reconstruction du RAID. +> + + + +#### Reconstruire le RAID en mode normal + +Les étapes suivantes sont réalisées en mode normal. Dans notre exemple, nous avons remplacé le disque **sda**. + +Une fois le disque remplacé, nous devons copier la table de partition du disque sain (dans cet exemple, sdb) vers le nouveau (sda). + +> [!tabs] +> **Pour les partitions GPT** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sgdisk -R /dev/nouveau disque /dev/disque sain`. +>> +>> Une fois cette opération effectuée, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque afin d'éviter tout conflit avec les GUID d'autres disques : +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> Si le message suivant s'affiche : +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> Vous pouvez simplement exécuter la commande `partprobe`. Si vous ne voyez toujours pas les partitions nouvellement créées (par exemple avec `lsblk`), vous devez redémarrer le serveur avant de continuer. +>> +> **Pour les partitions MBR** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sfdisk -d /dev/disksain | sfdisk /dev/nnouveaudisk`. +>> + +Ensuite, nous ajoutons les partitions au RAID : + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Utilisez la commande suivante pour surveiller la reconstruction du RAID : + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` -Une fois le disque remplacé, copiez la table de partition à partir d'un disque sain (« sdb » dans cet exemple) dans la nouvelle (« sda ») avec la commande suivante : +Enfin, nous ajoutons un label et montons la partition [SWAP] (le cas échéant). -**Pour les partitions GPT** +Pour ajouter un libellé à la partition SWAP : ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mkswap /dev/sdb4 -L swap-sdb4 ``` -La commande doit être au format suivant : `sgdisk -R /dev/nouveaudisque /dev/disquesain` +Ensuite, récupérez les UUID des deux partitions swap : + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +``` -Une fois cette opération effectuée, l’étape suivante consiste à rendre aléatoire le GUID du nouveau disque afin d’éviter tout conflit de GUID avec les autres disques : +Nous remplaçons l'ancien UUID de la partition swap (**sda4**) par le nouveau dans `/etc/fstab` : ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo nano etc/fstab ``` -**Pour les partitions MBR** +Assurez-vous de remplacer le bon UUID. + +Ensuite, rechargez le système avec la commande suivante : + +```sh +[user@server_ip ~]# sudo systemctl daemon-reload +``` -Une fois le disque remplacé, copiez la table de partition à partir d'un disque sain (« sdb » dans cet exemple) dans la nouvelle (« sda ») avec la commande suivante : +Exécutez la commande suivante pour activer la partition swap : ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo swapon -av ``` -La commande doit être au format suivant : `sfdisk -d /dev/disquesain | sfdisk /dev/nouveaudisque` +La reconstruction du RAID est maintenant terminée. + + + +/// details | **Reconstruction du RAID en mode rescue** + +Une fois le disque remplacé, nous devons copier la table de partition du disque sain (dans cet exemple, sda) vers le nouveau (sdb). + +> [!tabs] +> **Pour les partitions GPT** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sgdisk -R /dev/nouveau disque /dev/disque sain` +>> +>> Exemple : +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Une fois cette opération effectuée, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque afin d'éviter tout conflit avec les GUID d'autres disques : +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> Si le message suivant s'affiche : +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> Vous pouvez simplement exécuter la commande `partprobe`. Si vous ne voyez toujours pas les partitions nouvellement créées (par exemple avec `lsblk`), vous devez redémarrer le serveur avant de continuer. +>> +> **Pour les partitions MBR** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> La commande doit être au format suivant : `sfdisk -d /dev/disque sain | sfdisk /dev/nouveau disque` +>> + +Nous pouvons maintenant reconstruire la matrice RAID. L'extrait de code suivant montre comment ajouter les nouvelles partitions (sdb2 et sdb4) dans la matrice RAID. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -Il est maintenant possible de reconstruire la matrice RAID. L'extrait de code ci-dessous montre comment reconstruire la disposition de la partition `/dev/md4` avec la table de partition « sda » copiée récemment : +Utilisez la commande `cat /proc/mdstat` pour surveiller la reconstruction du RAID : ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Vérifiez les détails du RAID avec la commande suivante : +Pour plus de détails sur la ou les baies RAID : ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -369,12 +547,118 @@ mdadm --detail /dev/md4 1 8 18 1 active sync /dev/sdb4 ``` -Le RAID a maintenant été reconstruit. Montez la partition (`/dev/md4` dans cet exemple) avec cette commande : + + +#### Ajout du label à la partition SWAP (le cas échéant) + +Une fois la reconstruction du RAID terminée, nous montons la partition contenant la racine de notre système d'exploitation sur `/mnt`. Dans notre exemple, cette partition est `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +Nous ajoutons le label à notre partition swap avec la commande : ```sh -mount /dev/md4 /home +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sda4 -L swap-sda4 +mkswap: /dev/sda4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-nvme0n1p4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd ``` +Ensuite, nous montons les répertoires suivants pour nous assurer que toute manipulation que nous faisons dans l'environnement chroot fonctionne correctement : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Ensuite, nous accédons à l'environnement `chroot` : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +Nous récupérons les UUID des deux partitions swap : + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Exemple: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +``` + +```sh +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Ensuite, nous remplaçons l'ancien UUID de la partition swap (**sdb4**) par le nouveau dans `/etc/fstab` : + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Exemple: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Assurez-vous de remplacer l'UUID approprié. Dans notre exemple ci-dessus, l'UUID à remplacer est `d6af33cf-fc15-4060-a43c-cb3b5537f58a` par le nouveau `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Assurez-vous de remplacer le bon UUID. + +Ensuite, nous nous assurons que tout est correctement monté : + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Rechargez le système avec la commande suivante : + +```sh +root@rescue12-customer-eu:/# systemctl daemon-reload +``` + +Activez la partition swap avec la commande suivante : + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +Quittez l'environnement Chroot avec `exit` et démontez tous les disques : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +Nous avons maintenant terminé avec succès la reconstruction du RAID sur le serveur et nous pouvons maintenant le redémarrer en mode normal. + + ## Aller plus loin [Remplacement à chaud - RAID logiciel](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -385,4 +669,10 @@ mount /dev/md4 /home [Remplacement à chaud - RAID Matériel](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +Pour des prestations spécialisées (référencement, développement, etc), contactez les [partenaires OVHcloud](/links/partner). + +Si vous souhaitez bénéficier d'une assistance à l'usage et à la configuration de vos solutions OVHcloud, nous vous proposons de consulter nos différentes [offres de support](/links/support). + +Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. + Échangez avec notre [communauté d'utilisateurs](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-fr.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-fr.md index 811e36b6932..7173ac0de0f 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-fr.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.fr-fr.md @@ -1,7 +1,7 @@ --- -title: Configuration et reconstruction du RAID logiciel -excerpt: "Découvrez comment vérifier l'état du RAID logiciel de votre serveur et le reconstruire après un remplacement de disque" -updated: 2023-08-21 +title: Gestion et reconstruction du RAID logiciel sur les serveurs en mode legacy boot (BIOS) +excerpt: "Découvrez comment gérer et reconstruire le RAID logiciel après un remplacement de disque sur votre serveur en mode legacy boot (BIOS)" +updated: 2025-12-11 --- ## Objectif @@ -10,23 +10,66 @@ Le RAID (Redundant Array of Independent Disks) est un ensemble de techniques pr Le niveau RAID par défaut pour les installations de serveurs OVHcloud est RAID 1, ce qui double l'espace occupé par vos données, réduisant ainsi de moitié l'espace disque utilisable. -**Ce guide va vous aider à configurer la matrice RAID de votre serveur dans l'éventualité où elle doit être reconstruite en raison d'une corruption ou d'une panne de disque.** +**Ce guide explique comment gérer et reconstruire un RAID logiciel en cas de remplacement d'un disque sur votre serveur en mode legacy boot (BIOS).** +Avant de commencer, veuillez noter que ce guide se concentre sur les serveurs dédiés qui utilisent le mode legacy boot (BIOS). Si votre serveur utilise le mode UEFI (cartes mères plus récentes), reportez-vous à ce guide [Gestion et reconstruction du RAID logiciel sur les serveurs en mode boot UEFI](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +Pour vérifier si un serveur s'exécute en mode BIOS ou en mode UEFI, exécutez la commande suivante : + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + ## Prérequis - Posséder un [serveur dédié](/links/bare-metal/bare-metal) avec une configuration RAID logiciel. - Avoir accès à votre serveur via SSH en tant qu'administrateur (sudo). +- Compréhension du RAID et des partitions ## En pratique -### Retrait du disque +### Présentation du contenu + +- [Informations de base](#basicinformation) +- [Simuler une panne de disque](#diskfailure) + - [Retrait du disque défaillant](#diskremove) +- [Reconstruction du RAID](#raidrebuild) + - [Reconstruction du RAID en mode rescue](#rescuemode) + - [Ajout du label à la partition SWAP (le cas échéant)](#swap-partition) + - [Reconstruction du RAID en mode normal](#normalmode) + + + + +### Informations de base + +Dans une session de ligne de commande, tapez le code suivant pour déterminer l'état actuel du RAID. + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +Cette commande nous indique que deux périphériques RAID logiciels sont actuellement configurés, **md4** étant le plus grand. Le périphérique RAID **md4** se compose de deux partitions, appelées **nvme1n1p4** et **nvme0n1p4**. + +Le [UU] signifie que tous les disques fonctionnent normalement. Un `_` indique un disque défectueux. -La vérification de l’état actuel du RAID s’effectue via la commande suivante : +Si vous possédez un serveur avec des disques SATA, vous obtenez les résultats suivants : ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -40,12 +83,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Cette commande montre deux matrices RAID actuellement configurées, « md4 » étant la plus grande partition. La partition se compose de deux disques, appelés « sda4 » et « sdb4 ». Le [UU] signifie que tous les disques fonctionnent normalement. Un « _ » indiquerait un disque défectueux. - -Bien que cette commande affiche les volumes RAID, elle n'indique pas la taille des partitions elles-mêmes. Vous pouvez obtenir cette information via la commande suivante : +Bien que cette commande renvoie nos volumes RAID, elle ne nous indique pas la taille des partitions elles-mêmes. Nous pouvons retrouver cette information avec la commande suivante : ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -87,73 +128,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -La commande `fdisk -l` vous permet également d'identifier votre type de partition. C'est une information importante à connaître lorsqu'il s'agit de reconstruire votre RAID en cas de défaillance d'un disque. - -Pour les partitions **GPT**, la commande retournera : `Disklabel type: gpt`. - -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +La commande `fdisk -l` vous permet également d'identifier votre type de partition. Il s’agit d’une information importante pour reconstruire votre RAID en cas de défaillance d’un disque. -Pour les partitions **MBR**, la commande retournera : `Disklabel type: dos`. +Pour les partitions **GPT**, la ligne 6 affichera : `Disklabel type: gpt`. Ces informations ne sont visibles que lorsque le serveur est en mode normal. -```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Cette commande montre que `/dev/md2` se compose de 888,8 Go et `/dev/md4` contient 973,5 Go. Exécuter la commande « mount » montre la disposition du disque. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` +Toujours en se basant sur les résultats de `fdisk -l`, on peut voir que `/dev/md2` se compose de 888.8GB et `/dev/md4` contient 973.5GB. Alternativement, la commande `lsblk` offre une vue différente des partitions : ```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -173,91 +157,141 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Les disques sont actuellement montés par défaut. Pour retirer un disque du RAID, vous devez dans un premier temps démonter le disque, puis simuler un échec pour enfin le supprimer. -Nous allons supprimer `/dev/sda4` du RAID avec la commande suivante : +Nous prenons en compte les périphériques, les partitions et leurs points de montage. À partir des commandes et des résultats ci-dessus, nous avons : + +- Deux baies RAID : `/dev/md2` et `/dev/md4`. +- Quatre partitions font partie du RAID avec les points de montage : `/` et `/home`. + + + +### Simuler une panne de disque + +Maintenant que nous disposons de toutes les informations nécessaires, nous pouvons simuler une panne de disque et poursuivre les tests. Dans cet exemple, nous allons faire échouer le disque `sda`. + +Le moyen privilégié pour y parvenir est l’environnement en mode rescue d’OVHcloud. + +Redémarrez d'abord le serveur en mode rescue et connectez-vous avec les informations d'identification fournies. + +Pour retirer un disque du RAID, la première étape consiste à le marquer comme **Failed** et à retirer les partitions de leurs matrices RAID respectives. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +À partir de la sortie ci-dessus, sda se compose de deux partitions en RAID qui sont **sda2** et **sda4**. + + + +#### Retrait du disque défaillant + +Nous commençons par marquer les partitions **sda2** et **sda4** comme **failed**. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Veuillez noter que si vous êtes connecté en tant qu'utilisateur `root`, vous pouvez obtenir le message suivant lorsque vous essayez de démonter la partition (dans notre cas, où notre partition md4 est montée dans /home) : -> -> 
umount: /home: target is busy
-> -> Dans ce cas, vous devez vous déconnecter en tant qu'utilisateur root et vous connecter en tant qu'utilisateur local (dans notre cas, `debian`) et utiliser la commande suivante : -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Si vous ne disposez pas d'utilisateur local, [vous devez en créer un](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` -Le résultat obtenu sera le suivant : +Nous avons maintenant simulé une défaillance du RAID, lorsque nous exécutons la commande `cat /proc/mdstat`, nous obtenons le résultat suivant : ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Comme nous pouvons le voir ci-dessus, le [F] à côté des partitions indique que le disque est défaillant ou défectueux. + +Ensuite, nous retirons ces partitions des baies RAID. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 ``` -L'entrée de `/dev/md4` n'est maintenant plus montée. Cependant, le RAID est toujours actif. Il est donc nécessaire de simuler un échec pour retirer le disque, ce qui peut être effectué grâce à la commande suivante : +Pour nous assurer que nous obtenons un disque qui est similaire à un disque vide, nous utilisons la commande suivante. Remplacez **sda** par vos propres valeurs : ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -Nous avons maintenant simulé un échec du RAID. L'étape suivante consiste à supprimer la partition du RAID avec la commande suivante : +Si nous exécutons la commande suivante, nous voyons que notre disque a été correctement « nettoyé » : ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Vous pouvez vérifier que la partition a été supprimée avec la commande suivante : +L'état de notre RAID devrait maintenant ressembler à ceci : ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -La commande ci-dessous vérifie que la partition a été supprimée : +Les résultats ci-dessus montrent que seules deux partitions apparaissent désormais dans les matrices RAID. Nous avons réussi à faire échouer le disque **sda** et nous pouvons maintenant procéder au remplacement du disque. + +Pour plus d'informations sur la préparation et la demande de remplacement d'un disque, consultez ce [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +La commande suivante permet d'avoir plus de détails sur la ou les matrices RAID : ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -289,56 +323,200 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Reconstruction du RAID + + +### Reconstruire le RAID + +> [!warning] +> +> Pour la plupart des serveurs en RAID logiciel, après un remplacement de disque, le serveur est capable de démarrer en mode normal (sur le disque sain) pour reconstruire le RAID. Cependant, si le serveur ne parvient pas à démarrer en mode normal, il sera redémarré en mode rescue pour procéder à la reconstruction du RAID. +> + + + +#### Reconstruire le RAID en mode normal + +Les étapes suivantes sont réalisées en mode normal. Dans notre exemple, nous avons remplacé le disque **sda**. + +Une fois le disque remplacé, nous devons copier la table de partition du disque sain (dans cet exemple, sdb) vers le nouveau (sda). + +> [!tabs] +> **Pour les partitions GPT** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sgdisk -R /dev/nouveau disque /dev/disque sain`. +>> +>> Une fois cette opération effectuée, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque afin d'éviter tout conflit avec les GUID d'autres disques : +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> Si le message suivant s'affiche : +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> Vous pouvez simplement exécuter la commande `partprobe`. Si vous ne voyez toujours pas les partitions nouvellement créées (par exemple avec `lsblk`), vous devez redémarrer le serveur avant de continuer. +>> +> **Pour les partitions MBR** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sfdisk -d /dev/disksain | sfdisk /dev/nnouveaudisk`. +>> + +Ensuite, nous ajoutons les partitions au RAID : + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Utilisez la commande suivante pour surveiller la reconstruction du RAID : + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` -Une fois le disque remplacé, copiez la table de partition à partir d'un disque sain (« sdb » dans cet exemple) dans la nouvelle (« sda ») avec la commande suivante : +Enfin, nous ajoutons un label et montons la partition [SWAP] (le cas échéant). -**Pour les partitions GPT** +Pour ajouter un libellé à la partition SWAP : ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo mkswap /dev/sdb4 -L swap-sdb4 ``` -La commande doit être au format suivant : `sgdisk -R /dev/nouveaudisque /dev/disquesain` +Ensuite, récupérez les UUID des deux partitions swap : + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +``` -Une fois cette opération effectuée, l’étape suivante consiste à rendre aléatoire le GUID du nouveau disque afin d’éviter tout conflit de GUID avec les autres disques : +Nous remplaçons l'ancien UUID de la partition swap (**sda4**) par le nouveau dans `/etc/fstab` : ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo nano etc/fstab ``` -**Pour les partitions MBR** +Assurez-vous de remplacer le bon UUID. + +Ensuite, rechargez le système avec la commande suivante : + +```sh +[user@server_ip ~]# sudo systemctl daemon-reload +``` -Une fois le disque remplacé, copiez la table de partition à partir d'un disque sain (« sdb » dans cet exemple) dans la nouvelle (« sda ») avec la commande suivante : +Exécutez la commande suivante pour activer la partition swap : ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo swapon -av ``` -La commande doit être au format suivant : `sfdisk -d /dev/disquesain | sfdisk /dev/nouveaudisque` +La reconstruction du RAID est maintenant terminée. + + + +/// details | **Reconstruction du RAID en mode rescue** + +Une fois le disque remplacé, nous devons copier la table de partition du disque sain (dans cet exemple, sda) vers le nouveau (sdb). + +> [!tabs] +> **Pour les partitions GPT** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> La commande doit être au format suivant : `sgdisk -R /dev/nouveau disque /dev/disque sain` +>> +>> Exemple : +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Une fois cette opération effectuée, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque afin d'éviter tout conflit avec les GUID d'autres disques : +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> Si le message suivant s'affiche : +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> Vous pouvez simplement exécuter la commande `partprobe`. Si vous ne voyez toujours pas les partitions nouvellement créées (par exemple avec `lsblk`), vous devez redémarrer le serveur avant de continuer. +>> +> **Pour les partitions MBR** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> La commande doit être au format suivant : `sfdisk -d /dev/disque sain | sfdisk /dev/nouveau disque` +>> + +Nous pouvons maintenant reconstruire la matrice RAID. L'extrait de code suivant montre comment ajouter les nouvelles partitions (sdb2 et sdb4) dans la matrice RAID. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -Il est maintenant possible de reconstruire la matrice RAID. L'extrait de code ci-dessous montre comment reconstruire la disposition de la partition `/dev/md4` avec la table de partition « sda » copiée récemment : +Utilisez la commande `cat /proc/mdstat` pour surveiller la reconstruction du RAID : ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Vérifiez les détails du RAID avec la commande suivante : +Pour plus de détails sur la ou les baies RAID : ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -369,12 +547,118 @@ mdadm --detail /dev/md4 1 8 18 1 active sync /dev/sdb4 ``` -Le RAID a maintenant été reconstruit. Montez la partition (`/dev/md4` dans cet exemple) avec cette commande : + + +#### Ajout du label à la partition SWAP (le cas échéant) + +Une fois la reconstruction du RAID terminée, nous montons la partition contenant la racine de notre système d'exploitation sur `/mnt`. Dans notre exemple, cette partition est `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +Nous ajoutons le label à notre partition swap avec la commande : ```sh -mount /dev/md4 /home +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sda4 -L swap-sda4 +mkswap: /dev/sda4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-nvme0n1p4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd ``` +Ensuite, nous montons les répertoires suivants pour nous assurer que toute manipulation que nous faisons dans l'environnement chroot fonctionne correctement : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Ensuite, nous accédons à l'environnement `chroot` : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +Nous récupérons les UUID des deux partitions swap : + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Exemple: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +``` + +```sh +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Ensuite, nous remplaçons l'ancien UUID de la partition swap (**sdb4**) par le nouveau dans `/etc/fstab` : + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Exemple: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Assurez-vous de remplacer l'UUID approprié. Dans notre exemple ci-dessus, l'UUID à remplacer est `d6af33cf-fc15-4060-a43c-cb3b5537f58a` par le nouveau `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Assurez-vous de remplacer le bon UUID. + +Ensuite, nous nous assurons que tout est correctement monté : + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Rechargez le système avec la commande suivante : + +```sh +root@rescue12-customer-eu:/# systemctl daemon-reload +``` + +Activez la partition swap avec la commande suivante : + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +Quittez l'environnement Chroot avec `exit` et démontez tous les disques : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +Nous avons maintenant terminé avec succès la reconstruction du RAID sur le serveur et nous pouvons maintenant le redémarrer en mode normal. + + ## Aller plus loin [Remplacement à chaud - RAID logiciel](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) @@ -385,4 +669,10 @@ mount /dev/md4 /home [Remplacement à chaud - RAID Matériel](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +Pour des prestations spécialisées (référencement, développement, etc), contactez les [partenaires OVHcloud](/links/partner). + +Si vous souhaitez bénéficier d'une assistance à l'usage et à la configuration de vos solutions OVHcloud, nous vous proposons de consulter nos différentes [offres de support](/links/support). + +Si vous avez besoin d'une formation ou d'une assistance technique pour la mise en oeuvre de nos solutions, contactez votre commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander une analyse personnalisée de votre projet à nos experts de l’équipe Professional Services. + Échangez avec notre [communauté d'utilisateurs](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.it-it.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.it-it.md index 40d97a4274c..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.it-it.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.it-it.md @@ -1,34 +1,74 @@ --- -title: Configurazione e ricostruzione del RAID software -excerpt: "Come verificare lo stato del RAID software del tuo server e ricostruirlo dopo la sostituzione del disco" -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Questa traduzione è stata generata automaticamente dal nostro partner SYSTRAN. I contenuti potrebbero presentare imprecisioni, ad esempio la nomenclatura dei pulsanti o alcuni dettagli tecnici. In caso di dubbi consigliamo di fare riferimento alla versione inglese o francese della guida. Per aiutarci a migliorare questa traduzione, utilizza il pulsante "Contribuisci" di questa pagina. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + +## Requirements + +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions + +## Instructions -## Obiettivo +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 and prepare yourself in case it ever happens. -Il RAID (Redundant Array of Independent Disks) consiste in un insieme di tecniche che consentono di limitare la perdita delle informazioni presenti su un server grazie alla replica dei dati su più dischi. +### Content overview -Il livello RAID implementato di default sui server OVHcloud è RAID 1, un sistema che raddoppia lo spazio occupato dai dati dimezzando quindi quello utile. +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -**Questa guida ti mostra come configurare il volume RAID del tuo server nel caso in cui sia necessario ricostruirlo in seguito alla corruzione o guasto del disco.** + -## Prerequisiti +### Basic Information -- Disporre di un [server dedicato](/links/bare-metal/bare-metal) con configurazione RAID software -- Avere accesso al server via SSH con l’utente root +In a command line session, type the following code to determine the current RAID status: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` -## Procedura +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. -### Rimozione del disco +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. -Per verificare lo stato corrente del RAID è necessario eseguire questo comando: +If you have a server with SATA disks, you would get the following results: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -42,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Il comando mostra due volumi RAID configurati. La partizione più grande è “md4” ed è composta dai due dischi “sda4” e “ sdb4”. [UU] indica che i dischi funzionano normalmente: in caso di disco difettoso sarebbe infatti presente una “`_`”. - -In questo modo è possibile visualizzare i volumi RAID, ma non la dimensione delle partizioni. È possibile ottenere questa informazione utilizzando un altro comando: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -89,75 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -Il comando `fdisk -l` ti permette anche di identificare il tuo tipo di partizione. È un'informazione importante da conoscere quando si tratta di ricostruire il tuo RAID in caso di guasto di un disco. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -Per le partizioni **GPT**, il comando restituisce: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -Per le partizioni **MBR**, il comando restituisce: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Questo comando mostra che `/dev/md2` è composto da 888,8 GB e `/dev/md4` contiene 973,5 GB. Eseguire il comando "mount" mostra la disposizione del disco. - -Per visualizzare lo stato del disco utilizza il comando “mount”: - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` - -In alternativa, il comando `lsblk` offre una vista differente delle partizioni: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -177,90 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Al momento i dischi sono montati di default. Per rimuovere un disco dal RAID è necessario effettuarne l’unmount, indicarlo come difettoso e infine eliminarlo. Ad esempio, per rimuovere `/dev/sda4` dal RAID esegui il comando: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Se sei connesso come utente `root`, puoi ottenere questo messaggio quando cerchi di smontare la partizione (nel nostro caso, la partizione md4 è montata in /home): -> -> 
umount: /home: target is busy
-> -> In questo caso, dovrai disconnetterti come utente root e connetterti come utente locale (nel nostro caso, `debian`) utilizzando il comando: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Se non disponi di un utente locale, [è necessario crearne un](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -Il risultato restituito sarà di questo tipo: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -A questo punto la partizione `/dev/md4` non è più montata, ma il RAID è ancora attivo. Per rimuovere il disco è necessario indicarlo come difettoso con il comando: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -In questo modo abbiamo simulato un malfunzionamento del RAID. Lo step successivo consiste nella rimozione della partizione dal RAID: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Per verificare che l’operazione sia stata effettuata correttamente, utilizza il comando: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Per verificare la corretta rimozione della partizione esegui il comando: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -292,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Ricostruzione del RAID + + +### Rebuilding the RAID + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Use the following command to monitor the RAID rebuild: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: + +```sh +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 +``` + +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Una volta sostituito il disco, copia la tabella delle partizioni da un disco funzionante (nell’esempio, “sdb”) in quello nuovo (“sda”) con il comando: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -**Per le partizioni GPT** +Example: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 ``` -L'ordine deve essere nel seguente formato: `sgdisk -R /dev/newdisk /dev/healthydisk`. +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 coorect UUID. -Una volta effettuata questa operazione, lo step successivo consiste nel rendere aleatoria la guida del nuovo disco per evitare qualsiasi conflitto di GUID con gli altri dischi: +Next, we verify that everything is properly mounted with the following command: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -**Per le partizioni MBR** +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` -Una volta sostituito il disco, copia la tabella delle partizioni da un disco funzionante (nell’esempio, “sdb”) in quello nuovo (“sda”) con il comando: +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -L'ordine deve essere nel seguente formato: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -A questo punto è possibile ricostruire il volume RAID. Il codice seguente mostra come ricostruire la partizione `/dev/md4` tramite la tabella di “sda” copiata precedentemente: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Per verificare i dettagli del RAID, utilizza il comando: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -368,24 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -Una volta che il RAID è stato ricostruito, effettua il mount della partizione (nell’esempio, `/dev/md4`) con il comando: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` -## Per saperne di più +Example: -[Hot Swap – RAID Software](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) [OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[Hot Swap - RAID Hardware](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). -[Gestire il RAID Hardware](/pages/bare_metal_cloud/dedicated_servers/raid_hard) (in inglese) +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Contatta la nostra Community di utenti all’indirizzo . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pl-pl.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pl-pl.md index 003629b1631..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pl-pl.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pl-pl.md @@ -1,34 +1,74 @@ --- -title: Konfiguracja i rekonstrukcja programowej macierzy RAID -excerpt: "Dowiedz się, jak sprawdzić stan programowej macierzy RAID Twojego serwera i odtworzyć ją po wymianie dysku" -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Tłumaczenie zostało wygenerowane automatycznie przez system naszego partnera SYSTRAN. W niektórych przypadkach mogą wystąpić nieprecyzyjne sformułowania, na przykład w tłumaczeniu nazw przycisków lub szczegółów technicznych. W przypadku jakichkolwiek wątpliwości zalecamy zapoznanie się z angielską/francuską wersją przewodnika. Jeśli chcesz przyczynić się do ulepszenia tłumaczenia, kliknij przycisk "Zgłóś propozycję modyfikacji" na tej stronie. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** -## Wprowadzenie +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). -RAID (Redundant Array of Independent Disks) to narzędzie pozwalające zminimalizować ryzyko utraty danych zapisanych na serwerze poprzez ich replikację na wielu dyskach. +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` -Domyślny poziom RAID dla serwerów OVHcloud to RAID 1. Dzięki temu przestrzeń zajmowana przez dane zwiększa się dwukrotnie, natomiast wielkość użytkowanej przestrzeni dyskowej zmniejsza się o połowę. +## Requirements -**W tym przewodniku wyjaśniamy, jak skonfigurować macierz RAID Twojego serwera w przypadku, gdy musi ona zostać odtworzona z powodu awarii lub uszkodzenia dysku.** +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions -## Wymagania początkowe +## Instructions -- Posiadanie [serwera dedykowanego](/links/bare-metal/bare-metal) ze skonfigurowaną programową macierzą RAID -- Dostęp do serwera przez SSH przy użyciu uprawnień administratora (sudo) +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 and prepare yourself in case it ever happens. -## W praktyce +### Content overview -### Usuwanie dysku +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -Weryfikacja aktualnego stanu RAID za pomocą polecenia: + + +### Basic Information + +In a command line session, type the following code to determine the current RAID status: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -42,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Polecenie wskazuje dwie aktualnie skonfigurowane macierze RAID, przy czym “md4” jest największą partycją. Partycja składa się z dwóch dysków o nazwach: “sda4” i “sdb4”. [UU] oznacza, że wszystkie dyski działają prawidłowo. “`_`” wskazuje wadliwy dysk. - -W poleceniu ukazane są wielkości macierzy RAID, nie podane są jednak rozmiary samych partycji. Informację tę można uzyskać za pomocą polecenia: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -89,73 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -Komenda `fdisk -l` pozwala również na zidentyfikowanie partycji. Pamiętaj, że w przypadku awarii dysku możesz odtworzyć RAID. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -W przypadku partycji **GPT** komenda zwróci: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -W przypadku partycji **MBR** polecenie zwróci: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Polecenie pokazuje, że `/dev/md2` ma wielkość 888,8 GB, a `/dev/md4` 973,5 GB. Zastosuj polecenie “mount”, aby zobaczyć stan dysku. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` - -Komenda `lsblk` oferuje inny widok na partycje: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -175,91 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Aktualnie dyski są zamontowane domyślnie. Aby usunąć dysk z macierzy RAID, najpierw odmontuj dysk, po czym wykonaj symulację błędu, aby ostatecznie go usunąć. -Następnie usuń `/dev/sda4` z macierzy RAID za pomocą polecenia: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. ```sh -umount /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: ``` -> [!warning] -> Pamiętaj, że jeśli jesteś zalogowany jako użytkownik `root`, możesz uzyskać następujący komunikat podczas próby odmontowania partycji (w naszym przypadku, kiedy nasza partycja md4 jest zamontowana w /home): -> -> 
umount: /home: target is busy
-> -> W tym przypadku należy wylogować się jako użytkownik root i zalogować się jako użytkownik lokalny (w naszym przypadku, `debian`) i użyć następującej komendy: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Jeśli nie posiadasz lokalnego użytkownika, [musisz go utworzyć](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -Wynik będzie następujący: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -Wpis `/dev/md4` nie jest już zamontowany. Jednak macierz RAID jest nadal aktywna. Konieczna jest zatem symulacja błędu umożliwiająca usunięcie dysku. W tym celu zastosuj polecenie: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -Symulacja błędu RAID została wykonana. Następny krok to usunięcie partycji z macierzy RAID za pomocą polecenia: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Możesz sprawdzić, czy partycja została usunięta, stosując polecenie: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Poniższe polecenie pozwala upewnić się, czy partycja została usunięta: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -291,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Rekonstrukcja RAID + + +### Rebuilding the RAID + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Use the following command to monitor the RAID rebuild: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: -Po wymianie dysku skopiuj tablicę partycji ze zdrowego dysku, (w tym przykładzie dysk “sdb”) do nowego dysku “sda” za pomocą następującego polecenia: +```sh +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 +``` -**Dla partycji GPT** +Next, retrieve the UUIDs of both swap partitions: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -Polecenie musi mieć następujący format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -Po wykonaniu tej operacji kolejny krok polega na losowym odwzorowaniu GUID nowego dysku, aby uniknąć konfliktu GUID z innymi dyskami: +Example: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 ``` -**Dla partycji MBR** +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 coorect UUID. -Po wymianie dysku skopiuj tablicę partycji ze zdrowego dysku, (w tym przykładzie dysk “sdb”) do nowego dysku “sda” za pomocą następującego polecenia: +Next, we verify that everything is properly mounted with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -Polecenie musi mieć następujący format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` -Teraz możesz odtworzyć macierz RAID. Poniższy fragment kodu pokazuje, jak odtworzyć układ partycji `/dev/md4` za pomocą skopiowanej tablicy partycji “sda”: +Then reload the system with the following command: ```sh -mdadm —add /dev/md4 /dev/sda4 -cat /proc/mdstat +[user@server_ip ~]# sudo systemctl daemon-reload +``` -Personalities: [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2: active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 stron [4KB], 65536KB chunk +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. -md4: active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] - bitmap: 0/8 stron [0KB], 65536KB chunk +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` + +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk unused devices: ``` -Sprawdź szczegóły dotyczące RAID za pomocą polecenia: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -367,22 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: + +```sh +root@rescue12-customer-eu:/# nano etc/fstab +``` + +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -Macierz RAID została odtworzona. Zamontuj partycję (w tym przykładzie `/dev/md4`) za pomocą polecenia: +Activate the swap partition the following command: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 ``` -## Sprawdź również +We exit the `chroot` environment with exit and reload the system: -[Wymiana dysku bez wyłączania serwera – Programowa macierz RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) [OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[Sprzętowa macierz RAID (EN)](/pages/bare_metal_cloud/dedicated_servers/raid_hard) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Przyłącz się do społeczności naszych użytkowników na stronie . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pt-pt.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pt-pt.md index 81cd9e6eaf2..2a20f7e415d 100644 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pt-pt.md +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/guide.pt-pt.md @@ -1,34 +1,74 @@ --- -title: Configuração e reconstrução do software RAID -excerpt: "Descubra como verificar o estado do RAID software do seu servidor e reconstruí-lo após uma substituição de disco" -updated: 2023-08-21 +title: Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on your server in legacy boot (BIOS) mode +updated: 2025-12-11 --- -> [!primary] -> Esta tradução foi automaticamente gerada pelo nosso parceiro SYSTRAN. Em certos casos, poderão ocorrer formulações imprecisas, como por exemplo nomes de botões ou detalhes técnicos. Recomendamos que consulte a versão inglesa ou francesa do manual, caso tenha alguma dúvida. Se nos quiser ajudar a melhorar esta tradução, clique em "Contribuir" nesta página. -> +## 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 a software RAID in the event of a disk replacement on your server in legacy boot mode (BIOS).** + +Before we begin, please note that this guide focuses on Dedicated servers that use legacy boot (BIOS) mode. If your server uses the UEFI mode (newer motherboards), refer to this guide [Managing and rebuilding software RAID on servers in UEFI boot mode](/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi). + +To check whether a server runs on legacy BIOS or UEFI mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + +## Requirements + +- A [Dedicated server](/links/bare-metal/bare-metal) with a software RAID configuration +- Administrative (sudo) access to the server via SSH +- Understanding of RAID and partitions + +## Instructions -## Objetivo +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 and prepare yourself in case it ever happens. -O RAID (Redundant Array of Independent Disks) é um conjunto de técnicas concebidas para atenuar a perda de dados num servidor através da replicação dos dados em vários discos. +### Content overview -O nível de RAID predefinido nos servidores da OVHcloud é RAID 1, ou seja, o dobro do espaço ocupado pelos dados, reduzindo assim para metade o espaço de disco utilizável. +- [Basic Information](#basicinformation) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID in rescue mode](#rescuemode) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) -**Este manual explica-lhe como configurar a matriz RAID de um servidor em caso de ter de ser reconstruída por motivos de corrupção ou de avaria de disco.** + -## Requisitos +### Basic Information -- Dispor de um [servidor dedicado](/links/bare-metal/bare-metal) com uma configuração RAID por software. -- Ter acesso ao servidor através de SSH enquanto administrador (sudo). +In a command line session, type the following code to determine the current RAID status: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 nvme0n1p2[1] nvme0n1p20] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 nvme0n1p4[0] nvme1n1p4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` -## Instruções +This command shows us that we have two software RAID devices currently set up, with **md4** being the largest one. The **md4** RAID device consists of two partitions, which are known as **nvme1n1p4** and **nvme0n1p4**. -### Retirada do disco +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. -A verificação do estado atual do RAID pode ser efetuado através do seguinte comando: +If you have a server with SATA disks, you would get the following results: ```sh -cat /proc/mdstat +[user@server_ip ~]# cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] md2 : active raid1 sda2[1] sdb2[0] @@ -42,12 +82,10 @@ md4 : active raid1 sda4[0] sdb4[1] unused devices: ``` -Este comando mostra as duas matrizes RAID que estão configuradas, sendo que “md4” é a maior partição. Uma partição é composta dois discos, chamados “sda4” e ”sdb4”. `[UU]` significa que todos os discos funcionam normalmente. Um “`_`” indicará um disco defeituoso. - -Embora este comando mostre os volumes RAID, este não indica o tamanho das próprias partições. Para obter esta informação, utilize o seguinte comando: +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: ```sh -fdisk -l +[user@server_ip ~]# sudo fdisk -l Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors Disk model: HGST HUS724020AL @@ -89,73 +127,16 @@ Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes ``` -O comando `fdisk -l` permite-lhe também identificar o seu tipo de partição. Esta é uma informação importante para saber quando se trata de reconstruir o seu RAID em caso de falha de um disco. +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. -Para as partições **GPT**, o comando voltará: `Disklabel type: gpt`. +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. This information can only been seen when the server is in normal mode. -```sh -Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors -Disk model: HGST HUS724020AL -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: gpt' -Disk identifier: F92B6C5B-2518-4B2D-8FF9-A311DED5845F -``` +Still going by the results of `fdisk -l`, we can see that `/dev/md2` consists of 888.8GB and `/dev/md4` contains 973.5GB. -Para as partições **MBR**, o comando voltará: `Disklabel type: dos`. +Alternatively, the `lsblk` command offers a different view of the partitions: ```sh -Disk /dev/sda: 2.5 GiB, 2621440000 bytes, 5120000 sectors -Disk model: QEMU HARDDISK -Units: sectors of 1 * 512 = 512 bytes -Sector size (logical/physical): 512 bytes / 512 bytes -I/O size (minimum/optimal): 512 bytes / 512 bytes -'Disklabel type: dos' -Disk identifier: 0x150f6797 -``` - -Este comando mostra que `/dev/md2` é composto por 888,8 GB e `/dev/md4` contém 973,5 GB. Para mostrar a disposição do disco, execute o comando “mount”. - -```sh -mount - -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -/dev/md4 on /home type ext3 (rw,relatime) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) -``` - -Alternativamente, a encomenda `lsblk` oferece uma visão diferente das partições: - -```sh -lsblk +[user@server_ip ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 1.8T 0 disk @@ -175,91 +156,151 @@ sdb 8:16 0 1.8T 0 disk └─md4 9:4 0 973.5G 0 raid1 /home ``` -Os discos estão montados por predefinição. Para retirar um disco, em primeiro lugar deve desmontar o disco e, a seguir, simular uma falha para o poder eliminar. -De seguida, elimine `/dev/sda4` do RAID com o seguinte comando: +We take note of the devices, partitions and their mount points. From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md4`. +- Four partitions are part of the RAID with the mount points: `/` and `/home`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this example, we will fail the disk `sda`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1] sdb2[0] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0] sdb4[1] + 1020767232 blocks super 1.2 [2/2] [UU] + bitmap: 0/8 pages [0KB], 65536KB chunk + +unused devices: +``` + +From the above output, sda consists of two partitions in RAID which are **sda2** and **sda4**. + + + +#### Removing the failed disk + +First we mark the partitions **sda2** and **sda4** as failed. ```sh -umount /dev/md4 +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2 +# mdadm: set /dev/sda2 faulty in /dev/md2 ``` -> [!warning] -> Atenção: se estiver conectado como utilizador `root`, pode obter a seguinte mensagem quando estiver a tentar desmontar a partição (no nosso caso, em que a nossa partição md4 está montada em /home): -> -> 
umount: /home: target is busy
-> -> Neste caso, deve desligar-se enquanto utilizador root e ligar-se como utilizador local (no nosso caso, `debian`) e utilizar o seguinte comando: -> -> 
debian@ns000000:/$ sudo umount /dev/md4
-> -> Se não dispõe de um utilizador local, [deve criar um](/pages/bare_metal_cloud/dedicated_servers/changing_root_password_linux_ds). +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4 +# mdadm: set /dev/sda4 faulty in /dev/md4 +``` + +We have now simulated a failure of the RAID, when we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[1](F) sdb2[0] + 931954688 blocks super 1.2 [2/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/2] [_U] + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +As we can see 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. + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2 +# mdadm: hot removed /dev/sda2 from /dev/md2 +``` + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4 +# mdadm: hot removed /dev/sda4 from /dev/md4 +``` -O resultado deverá ser este: +To make sure that we get a disk that is similar to an empty disk, we use the following command. Replace **sda** with your own values: ```sh -sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) -proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) -udev on /dev type devtmpfs (rw,nosuid,relatime,size=16315920k,nr_inodes=4078980,mode=755) -devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000) -tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=3266556k,mode=755) -/dev/md2 on / type ext4 (rw,relatime) -securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime) -tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) -tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) -tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755) -cgroup2 on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) -cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,name=systemd) -pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime) -bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700) -cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,pids) -cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) -cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) -cgroup on /sys/fs/cgroup/rdma type cgroup (rw,nosuid,nodev,noexec,relatime,rdma) -cgroup on /sys/fs/cgroup/net_cls,net_prio type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls,net_prio) -cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct) -cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) -cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) -cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) -cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) -debugfs on /sys/kernel/debug type debugfs (rw,relatime) -hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M) -mqueue on /dev/mqueue type mqueue (rw,relatime) -systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=10340) -tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=3266552k,mode=700,uid=1000,gid=1000) +shred -s10M -n1 /dev/sda1 +shred -s10M -n1 /dev/sda2 +shred -s10M -n1 /dev/sda3 +shred -s10M -n1 /dev/sda4 +shred -s10M -n1 /dev/sda ``` -A entrada de `/dev/md4` já não está montada. No entanto, o RAID ainda está ativo. Assim, é necessário simular uma falha para retirar o disco, o que pode ser efetuado graças ao seguinte comando: +The disk now appears as a new, empty drive: ```sh -sudo mdadm --fail /dev/md4 /dev/sda4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +sda 8:0 0 1.8T 0 disk +sdb 8:16 0 1.8T 0 disk +├─sdb1 8:17 0 1M 0 part +├─sdb2 8:18 0 888.9G 0 part +│ └─md2 9:2 0 888.8G 0 raid1 / +├─sdb3 8:19 0 512M 0 part [SWAP] +└─sdb4 8:20 0 973.6G 0 part + └─md4 9:4 0 973.5G 0 raid1 /home ``` -Uma vez simulada a falha no RAID, pode eliminar a partição com o seguinte comando: +If we run the following command, we see that our disk has been successfully "wiped": ```sh -sudo mdadm --remove /dev/md4 /dev/sda4 +parted /dev/sda +GNU Parted 3.5 +Using /dev/sda +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/sda: unrecognised disk label +Model: HGST HUS724020AL (SATA) +Disk /dev/sda: 1.8T +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: ``` -Poderá verificar que a partição foi eliminada com o seguinte comando: +Our RAID status should now look like this: ```sh -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] - 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 4/7 pages [16KB], 65536KB chunk +md2 : active raid1 sdb2[0] + 931954688 blocks super 1.2 [1/2] [_U] + bitmap: 2/7 pages [8KB], 65536KB chunk md4 : active raid1 sdb4[1] - 1020767232 blocks super 1.2 [2/1] [_U] + 1020767232 blocks super 1.2 [1/2] [_U] bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -O comando abaixo verifica que a partição foi eliminada: +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **sda** and we can now proceed with the disk replacement. + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement) + +If you run the following command, you can have more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -291,56 +332,225 @@ Consistency Policy : bitmap 1 8 20 1 active sync /dev/sdb4 ``` -### Reconstrução do RAID + + +### Rebuilding the RAID + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) to rebuild the RAID. However, if the server is not able to boot in normal mode, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> + + + +#### Rebuilding the RAID in normal mode + +The following steps are performed in normal mode. In our example, we have replaced the disk **sda**. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sdb) to the new one (sda). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> sudo sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk`. +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdX +>> ``` +>> +>> If you receive the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can 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. +>> +> **For MBR partitions** +>> +>> ```sh +>> [user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +>> + +Next, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/sda2 +# mdadm: added /dev/sda2 + +[user@server_ip ~]# sudo mdadm --add /dev/md4 /dev/sda4 +# mdadm: re-added /dev/sda4 +``` + +Use the following command to monitor the RAID rebuild: + +```sh +[user@server_ip ~]# cat /proc/mdstat + +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md2 : active raid1 sda2[0] sdb2[1] + 931954688 blocks super 1.2 [2/2] [UU] + bitmap: 4/4 pages [16KB], 65536KB chunk + +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec + bitmap: 0/8 pages [0KB], 65536KB chunk +unused devices: +``` + +Lastly, we add a label and mount the [SWAP] partition (if applicable). + +To add a label the SWAP partition: + +```sh +[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4 +``` + +Next, retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s UUID /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -S UUID /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` -Uma vez substituído o disco, copie a tabela de partição a partir de um disco são (“sdb” neste exemplo) para a nova (“sda”), com o seguinte comando: +We replace the old UUID of the swap partition (**sda4**) with the new one in `/etc/fstab`. -**Para as partições GPT** +Example: ```sh -sgdisk -R /dev/sda /dev/sdb +[user@server_ip ~]# sudo nano etc/fstab + +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=BIOS /boot vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 ``` -O comando deve ter o seguinte formato: `sgdisk -R /dev/newdisk /dev/healthydisk`. +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 coorect UUID. -Uma vez efetuada esta operação, o passo seguinte consiste em tornar aleatório o GUID do novo disco, a fim de evitar qualquer conflito do GUID com os outros discos: +Next, we verify that everything is properly mounted with the following command: ```sh -sgdisk -G /dev/sda +[user@server_ip ~]# sudo mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored ``` -**Para as partições MBR** +Run the following command to enable the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +``` -Uma vez substituído o disco, copie a tabela de partição a partir de um disco são (“sdb” neste exemplo) para a nova (“sda”), com o seguinte comando: +Then reload the system with the following command: ```sh -sfdisk -d /dev/sdb | sfdisk /dev/sda +[user@server_ip ~]# sudo systemctl daemon-reload ``` -O comando deve ter o seguinte formato: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk`. +We have now successfully completed the RAID rebuild. + + + +/// details | **Rebuilding the RAID in rescue mode** + +If you server is unable to reboot in normal mode after a disk replacement, it will be rebooted in rescue mode. + +In this example, we are replacing the disk `sdb`. + +Once the disk has been replaced, we need to copy the partition table from the healthy disk (in this example, sda) to the new one (sdb). + +> [!tabs] +> **For GPT partitions** +>> +>> ```sh +>> root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX +>> ``` +>> +>> The command should be in this format: `sgdisk -R /dev/newdisk /dev/healthydisk` +>> +>> Example: +>> +>> ```sh +>> sudo sgdisk -R /dev/sdb /dev/sda +>> ``` +>> +>> Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: +>> +>> ```sh +>> sudo sgdisk -G /dev/sdb +>> ``` +>> +>> If you the following message: +>> +>> ```console +>> Warning: The kernel is still using the old partition table. +>> The new table will be used at the next reboot or after you +>> run partprobe(8) or kpartx(8) +>> The operation has completed successfully. +>> ``` +>> +>> You can simply run the `partprobe` command. +>> +> **For MBR partitions** +>> +>> ```sh +>> sudo sfdisk -d /dev/sda | sfdisk /dev/sdb +>> ``` +>> +>> The command should be in this format: `sfdisk -d /dev/healthydisk | sfdisk /dev/newdisk` +>> + +We can now rebuild the RAID array. The following code snippet shows how we can add the new partitions (sdb2 and sdb4) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md2 /dev/sdb2 +# mdadm: added /dev/sdb2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --add /dev/md4 /dev/sdb4 +# mdadm: re-added /dev/sdb4 +``` -Já pode reconstruir a matriz RAID. O seguinte extrato do código mostra como reconstruir a disposição da partição `/dev/md4` com a tabela de partição “sda” que acaba de copiar: +Use the `cat /proc/mdstat` command to monitor the RAID rebuild: ```sh -mdadm --add /dev/md4 /dev/sda4 -cat /proc/mdstat +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] -md2 : active raid1 sda2[1] sdb2[0] +md2 : active raid1 sda2[0] sdb2[1] 931954688 blocks super 1.2 [2/2] [UU] - bitmap: 1/7 pages [4KB], 65536KB chunk + bitmap: 4/4 pages [16KB], 65536KB chunk -md4 : active raid1 sda4[0] sdb4[1] - 1020767232 blocks super 1.2 [2/2] [UU] +md4 : active raid1 sda4[0](F) sdb4[1] + 1020767232 blocks super 1.2 [2/1] [UU] + [============>........] recovery = 64.8% (822969856/1020767232) finish=7.2min speed=401664K/sec bitmap: 0/8 pages [0KB], 65536KB chunk - unused devices: ``` -Verifique os detalhes do RAID com o seguinte comando: +For more details on the RAID array(s): ```sh -mdadm --detail /dev/md4 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4 /dev/md4: Version : 1.2 @@ -367,24 +577,132 @@ mdadm --detail /dev/md4 Events : 0.95 Number Major Minor RaidDevice State - 0 8 2 0 spare rebuilding /dev/sda4 - 1 8 18 1 active sync /dev/sdb4 + 0 8 2 0 active sync /dev/sda4 + 1 8 18 1 spare rebuilding /dev/sdb4 +``` + + + +#### Adding the label to the SWAP partition (if applicable) + +Once the RAID rebuild is complete, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is `md4`. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md4 /mnt +``` + +We add the label to our swap partition with the command: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/sdb4 -L swap-sdb4 +mkswap: /dev/sdb4: warning: wiping old swap signature. +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-sdb4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Next, we mount the following directories to make sure any manipulation we make in the chroot environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we access the `chroot` environment: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUIDs of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4 +root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4 +``` + +Example: + +```sh +blkid /dev/sda4 +/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +blkid /dev/sdb4 +/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" ``` -O RAID foi reconstruído. Para montar a partição (`/dev/md4`, no exemplo), utilize o seguinte comando: +Next, we replace the old UUID of the swap partition (**sdb4**) with the new one in `/etc/fstab`: ```sh -mount /dev/md4 /home +root@rescue12-customer-eu:/# nano etc/fstab ``` -## Quer saber mais? +Example: -[Hot Swap – RAID por hardware (EN)](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /home ext4 defaults 0 0 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Make sure you replace the proper UUID. In our example above, the UUID to replace is `d6af33cf-fc15-4060-a43c-cb3b5537f58a` with the new one `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Make sure you replace the correct UUID. + +Next, we make sure everything is properly mounted: + +```sh +root@rescue12-customer-eu:/# mount -av +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Activate the swap partition the following command: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/sda4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sda4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sda4 +swapon: /dev/sdb4: found signature [pagesize=4096, signature=swap] +swapon: /dev/sdb4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/sdb4 +``` + +We exit the `chroot` environment with exit and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) [OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) -[Substituir um disco a quente num servidor com RAID por software](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). -[RAID por hardware (EN)](/pages/bare_metal_cloud/dedicated_servers/raid_hard) +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) to get a quote and ask our Professional Services experts for assisting you on your specific use case of your project. -Fale com a nossa comunidade de utilizadores em . +Join our [community of users](/links/community). diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft/meta.yaml b/pages/bare_metal_cloud/dedicated_servers/raid_soft/meta.yaml index be427964bb9..b14684e9fd2 100755 --- a/pages/bare_metal_cloud/dedicated_servers/raid_soft/meta.yaml +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft/meta.yaml @@ -1,2 +1,3 @@ id: 415bbcf2-436c-4b1c-966f-903832fc0f8d -full_slug: dedicated-servers-raid-soft \ No newline at end of file +full_slug: dedicated-servers-raid-soft +translation_banner: true \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.en-gb.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.en-gb.md new file mode 100644 index 00000000000..808bbff24e4 --- /dev/null +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.en-gb.md @@ -0,0 +1,1064 @@ +--- +title: Managing and rebuilding software RAID on servers using UEFI boot mode +excerpt: Find out how to manage and rebuild software RAID after a disk replacement on a server using UEFI boot mode +updated: 2025-12-11 +--- + +## 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](/pages/bare_metal_cloud/dedicated_servers/raid_soft_bios). + +To check whether a server runs on legacy BIOS mode or UEFI boot mode, run the following command: + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + +For more information on UEFI, consult the following [article](https://uefi.org/about). + +## Requirements + +- A [dedicated server](/links/bare-metal/bare-metal) 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 and prepare yourself in case it ever happens. + +### Content overview + +- [Basic Information](#basicinformation) +- [Understanding the EFI System Partition (ESP)](#efisystemparition) +- [Simulating a disk failure](#diskfailure) + - [Removing the failed disk](#diskremove) +- [Rebuilding the RAID](#raidrebuild) + - [Rebuilding the RAID after the main disk is replaced (rescue mode)](#rescuemode) + - [Recreating the EFI System Partition](#recreateesp) + - [Rebuilding RAID when EFI partitions are not synchronized after major system updates (e.g GRUB)](efiraodgrub) + - [Adding the label to the SWAP partition (if applicable)](#swap-partition) + - [Rebuilding the RAID in normal mode](#normalmode) + + + +### Basic Information + +In a command line session, type the following code to determine the current RAID status: + +```sh +[user@server_ip ~]# cat /proc/mdstat +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md3 : active raid1 nvme1n1p3[1] nvme0n1p3[0] + 497875968 blocks super 1.2 [2/2] [UU] + bitmap: 2/4 pages [8KB], 65536KB chunk + +md2 : active raid1 nvme1n1p2[1] nvme0n1p2[0] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +This command shows us that 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 **nvme1n1p3** and **nvme0n1p3**. + +The [UU] means that all the disks are working normally. A `_` would indicate a failed disk. + +If you have a server with SATA disks, you would get the following results: + +```sh +[user@server_ip ~]# cat /proc/mdstat +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md3 : active raid1 sda3[0] sdb3[1] + 3904786432 blocks super 1.2 [2/2] [UU] + bitmap: 2/30 pages [8KB], 65536KB chunk + +md2 : active raid1 sda2[0] sdb2[1] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +Although this command returns our RAID volumes, it doesn't tell us the size of the partitions themselves. We can find this information with the following command: + +```sh +[user@server_ip ~]# sudo fdisk -l + +Disk /dev/nvme1n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors +Disk model: WDC CL SN720 SDAQNTW-512G-2000 +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: gpt +Disk identifier: A11EDAA3-A984-424B-A6FE-386550A92435 + +Device Start End Sectors Size Type +/dev/nvme1n1p1 2048 1048575 1046528 511M EFI System +/dev/nvme1n1p2 1048576 3145727 2097152 1G Linux RAID +/dev/nvme1n1p3 3145728 999161855 996016128 474.9G Linux RAID +/dev/nvme1n1p4 999161856 1000210431 1048576 512M Linux files + + +Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors +Disk model: WDC CL SN720 SDAQNTW-512G-2000 +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: gpt +Disk identifier: F03AC3C3-D7B7-43F9-88DB-9F12D7281D94 + +Device Start End Sectors Size Type +/dev/nvme0n1p1 2048 1048575 1046528 511M EFI System +/dev/nvme0n1p2 1048576 3145727 2097152 1G Linux RAID +/dev/nvme0n1p3 3145728 999161855 996016128 474.9G Linux RAID +/dev/nvme0n1p4 999161856 1000210431 1048576 512M Linux file +/dev/nvme0n1p5 1000211120 1000215182 4063 2M Linux file + + +Disk /dev/md2: 1022 MiB, 1071644672 bytes, 2093056 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes + + +Disk /dev/md3: 474.81 GiB, 509824991232 bytes, 995751936 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +``` + +The `fdisk -l` command also allows you to identify your partition type. This is an important information when it comes to rebuilding your RAID in case of a disk failure. + +For **GPT** partitions, line 6 will display: `Disklabel type: gpt`. + +Still going by the results of `fdisk -l`, we can 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: + +```sh +[user@server_ip ~]# lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:7 0 511M 0 part +├─nvme1n1p2 259:8 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 /boot +├─nvme1n1p3 259:9 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 / +└─nvme1n1p4 259:10 0 512M 0 part [SWAP] +nvme0n1 259:1 0 476.9G 0 disk +├─nvme0n1p1 259:2 0 511M 0 part /boot/efi +├─nvme0n1p2 259:3 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 /boot +├─nvme0n1p3 259:4 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 / +├─nvme0n1p4 259:5 0 512M 0 part [SWAP] +└─nvme0n1p5 259:6 0 2M 0 part +``` + +Furthermore, if we run `lsblk -f`, we obtain more information about these partitions, such as the LABEL and UUID: + +```sh +[user@server_ip ~]# sudo lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART B493-9DFA +├─nvme1n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme1n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +└─nvme1n1p4 swap 1 swap-nvme1n1p4 483b9b41-ada3-4143-8cac-5bff7afb73c7 [SWAP] +nvme0n1 +├─nvme0n1p1 vfat FAT16 EFI_SYSPART B486-9781 504.9M 1% /boot/efi +├─nvme0n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme0n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +├─nvme0n1p4 swap 1 swap-nvme0n1p4 51e7172b-adb0-4729-b0f8-613e5dede38b [SWAP] +└─nvme0n1p5 iso9660 Joliet Extension config-2 2025-08-05-14-55-41-00 +``` + +Take note of the devices, partitions, and their mount points; this is important, especially after replacing a disk. + +From the above commands and results, we have: + +- Two RAID arrays: `/dev/md2` and `/dev/md3`. +- Four partitions are part of the RAID: **nvme0n1p2**, **nvme0n1p3**, **nvme1n1p2**, **nvme0n1p3** with the mount points `/boot` and `/`. +- Two partitions not part of the RAID, with mount points: `/boot/efi` and [SWAP]. +- One partition does not have a mount point: **nvme1n1p1** + +The `nvme0n1p5` partition is a configuration partition, i.e. a read-only volume connected to the server that provides it with the initial configuration data. + + + +### Understanding the EFI System Partition (ESP) + +***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?*** + +No, as of August 2025, when the OS installation is performed by OVHcloud, the ESP is not included in the RAID. When you use our OS templates to install your server with software RAID, several EFI System Partitions are created: one per disk. However, only one EFI partition is mounted at once. All ESPs created at the time of installation contain the same files. + +The EFI System Partition is mounted at `/boot/efi` and the disk on which it is mounted is selected by Linux at boot. + +Example: + +```sh +[user@server_ip ~]# sudo lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART B493-9DFA +├─nvme1n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme1n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +└─nvme1n1p4 swap 1 swap-nvme1n1p4 483b9b41-ada3-4143-8cac-5bff7afb73c7 [SWAP] +nvme0n1 +├─nvme0n1p1 vfat FAT16 EFI_SYSPART B486-9781 504.9M 1% /boot/efi +├─nvme0n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme0n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +├─nvme0n1p4 swap 1 swap-nvme0n1p4 51e7172b-adb0-4729-b0f8-613e5dede38b [SWAP] +└─nvme0n1p5 iso9660 Joliet Extension config-2 2025-08-05-14-55-41-00 +``` + +From the output above, we see that we have two identical EFI System Partitions (nvme0n1p1 and nvme1n1p1) but only **nvme0n1p1** is mounted on `/boot/efi`. Both partitions have the LABEL: `EFI_SYSPART` (this naming is specific to OVHcloud). + +***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, 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 mounted on `boot/efi` fails?*** + +> [!primary] +> Please note that we explore the most common cases below, but there are several other reasons why a server may not start in normal mode after a disk replacement. +> + +**Case study 1** - There have been no changes or major system 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, the server is rebooted into rescue mode, where you can rebuild the RAID and recreate the EFI partition on the new disk. + +**Case study 2** - There have been major system updates (e.g GRUB) to the OS and the ESPs have been synchronised + +- The server is able to boot in normal mode because all the ESPs contain up-to-date information and the RAID rebuild can be carried out in normal mode. +- The server is unable to boot in normal mode, the server is rebooted into rescue mode, where you can 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 ESPs partitions have not been synchronised + +- The server is unable to boot in normal mode, the server is rebooted in rescue mode, where you can rebuild the RAID, recreate the EFI System partition on the new disk and reinstall the bootloader (e.g. GRUB) on it. +- The server is able to boot in normal mode (this can occur when an operating system is updated to a newer version, but the version of GRUB remains unchanged) and you can proceed with the RAID rebuild. + +Indeed, in some cases, booting from an out-of-date ESP may not work. For instance, a major GRUB update could cause the old GRUB binary present in the ESP to be incompatible with newer GRUB modules installed in the `/boot` partition. + +***How can I synchronise my EFI System Partitions, and how often should I synchronise them?*** + +> [!primary] +> Please note that depending on your operating system, the process might be different. Ubuntu for example is able to keep several EFI System Partitions synchronized at every GRUB update. However, it is the only operating system doing so. We recommend that you consult the official documentation of your operating system to understand how to manage ESPs. +> +> In this guide, the operating system used is Debian. + +We recommend that you synchronise your ESPs regularly or after each major system update. By default, all the EFI System partitions contain the same files after installation. However, if a major system update is involved, synchronising the ESPs is essential to keep the content up-to-date. + + + +#### Script + +Below is a script that you can use to manually synchronise them. You can also run an automated script to synchronise the partitions daily or whenever the service boots up. + +Before you execute the script, make sure `rsync` is installed on your system: + +**Debian/Ubuntu** + +```sh +sudo apt install rsync +``` + +**CentOS, Red Hat and Fedora** + +```sh +sudo yum install rsync +``` + +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-name` with the name of your choice + +```sh +sudo touch script-name.sh +``` + +- Open the file with a text editor and include the following lines + +```sh +sudo nano script-name.sh +``` + +```sh +#!/bin/bash + +set -euo pipefail + +MOUNTPOINT="/var/lib/grub/esp" +MAIN_PARTITION=$(findmnt -n -o SOURCE /boot/efi) + +echo "${MAIN_PARTITION} is the main partition" + +mkdir -p "${MOUNTPOINT}" + +while read -r partition; do + if [[ "${partition}" == "${MAIN_PARTITION}" ]]; then + continue + fi + echo "Working on ${partition}" + mount "${partition}" "${MOUNTPOINT}" + rsync -ax "/boot/efi/" "${MOUNTPOINT}/" + umount "${MOUNTPOINT}" +done < <(blkid -o device -t LABEL=EFI_SYSPART) +``` + +Save and exit the file. + +- Make the script executable + +```sh +sudo chmod +x script-name.sh +``` + +- Run the script + +```sh +sudo ./script-name.sh +``` + +- If you are not in the folder + +```sh +./path/to/folder/script-name.sh +``` + +When the script is executed, the contents of the mounted EFI partition will be synchronised with the others. To access the contents, you can mount any of these unmounted EFI partitions on the mount point: `/var/lib/grub/esp`. + + + +### Simulating a disk failure + +Now that we have all the necessary information, we can simulate a disk failure and proceed with the tests. In this first example, we will fail the primary disk `nvme0n1`. + +The preferred way to do this is via the OVHcloud rescue mode environment. + +First reboot the server in rescue mode and log in with the provided credentials. + +To remove a disk from the RAID, the first step is to mark it as **Failed** and remove the partitions from their respective RAID arrays. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[0] nvme1n1p3[1] + 497875968 blocks super 1.2 [2/2] [UU] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2] nvme1n1p2[1] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +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. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/nvme0n1p2 +# mdadm: set /dev/nvme0n1p2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md3 --fail /dev/nvme0n1p3 +# mdadm: set /dev/nvme0n1p3 faulty in /dev/md3 +``` + +When we run the `cat /proc/mdstat` command, we have the following output: + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[0](F) nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2](F) nvme1n1p2[1] + 1046528 blocks super 1.2 [2/1] [_U] + +unused devices: +``` + +As we can see 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 completely remove the disk from RAID. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --remove /dev/nvme0n1p2 +# mdadm: hot removed /dev/nvme0n1p2 from /dev/md2 +``` + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md3 --remove /dev/nvme0n1p3 +# mdadm: hot removed /dev/nvme0n1p3 from /dev/md3 +``` + +Our RAID status should now look like this: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme1n1p2[1] + 1046528 blocks super 1.2 [2/1] [_U] + +unused devices: +``` + +From the results above, we can see that only two partitions now appear in the RAID arrays. We have successfully failed the disk **nvme0n1**. + +To make sure that we get a disk that is similar to an empty disk, we use the following command on each partition, then on the disk: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +shred -s10M -n1 /dev/nvme0n1p1 +shred -s10M -n1 /dev/nvme0n1p2 +shred -s10M -n1 /dev/nvme0n1p3 +shred -s10M -n1 /dev/nvme0n1p4 +shred -s10M -n1 /dev/nvme0n1p5 +shred -s10M -n1 /dev/nvme0n1 +``` + +The disk now appears as a new, empty drive: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk + +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:1 0 511M 0 part +├─nvme1n1p2 259:2 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 +├─nvme1n1p3 259:3 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 +└─nvme1n1p4 259:4 0 512M 0 part +nvme0n1 259:5 0 476.9G 0 disk +``` + +If we run the following command, we see that our disk has been successfully "wiped": + +```sh +parted /dev/nvme0n1 +GNU Parted 3.5 +Using /dev/nvme0n1 +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/nvme0n1: unrecognised disk label +Model: WDC CL SN720 SDAQNTW-512G-2000 (nvme) +Disk /dev/nvme0n1: 512GB +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: +``` + +For more information on how to prepare and request for a disk replacement, consult this [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement). + +If you run the following command, you can have more details on the RAID arrays: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md3 + +/dev/md3: + Version : 1.2 + Creation Time : Fri Aug 1 14:51:13 2025 + Raid Level : raid1 + Array Size : 497875968 (474.81 GiB 509.82 GB) + Used Dev Size : 497875968 (474.81 GiB 509.82 GB) + Raid Devices : 2 + Total Devices : 1 + Persistence : Superblock is persistent + + Intent Bitmap : Internal + + Update Time : Fri Aug 1 15:56:17 2025 + State : clean, degraded + Active Devices : 1 + Working Devices : 1 + Failed Devices : 0 + Spare Devices : 0 + +Consistency Policy : bitmap + + Name : md3 + UUID : b383c3d5:7fb1bb5e:6b7c4d96:6ea817ff + Events : 215 + + Number Major Minor RaidDevice State + - 0 0 0 removed + 1 259 4 1 active sync /dev/nvme1n1p3 +``` + +We can now proceed with the disk replacement. + + + +### Rebuilding the RAID + +> [!primary] +> 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. +> + +> [!warning] +> +> For most servers in software RAID, after a disk replacement, the server is able to boot in normal mode (on the healthy disk) and the rebuild can be done in normal mode. However, if the server is not able to boot in normal mode after a disk replacement, it will be rebooted in rescue mode to proceed with the RAID rebuild. +> +> If your server is able to boot in normal mode after the disk replacement, simply proceed with the steps from [this section](#rebuilding-the-raid-in-normal-mode). + + + +#### Rebuilding the RAID in rescue mode + +Once the disk has been replaced, the next 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: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/nvme0n1 /dev/nvme1n1 +``` + +Run `lsblk` to make sure the partition tables have been properly copied: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk + +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:1 0 511M 0 part +├─nvme1n1p2 259:2 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 +├─nvme1n1p3 259:3 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 +└─nvme1n1p4 259:4 0 512M 0 part +nvme0n1 259:5 0 476.9G 0 disk +├─nvme0n1p1 259:10 0 511M 0 part +├─nvme0n1p2 259:11 0 1G 0 part +├─nvme0n1p3 259:12 0 474.9G 0 part +└─nvme0n1p4 259:13 0 512M 0 part +``` + +Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -G /dev/nvme0n1 +``` + +If you receive the message below: + +```console +Warning: The kernel is still using the old partition table. +The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) +The operation has completed successfully. +``` + +Simply run the `partprobe` command. + +We can now rebuild the RAID array. The following code snippet shows how to add the new partitions (nvme0n1p2 and nvme0n1p3) back in the RAID array. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --add /dev/md2 /dev/nvme0n1p2 +# mdadm: added /dev/nvme0n1p2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --add /dev/md3 /dev/nvme0n1p3 +# mdadm: re-added /dev/nvme0n1p3 +``` + +To check the rebuild process: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[2] nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + [>....................] recovery = 0.1% (801920/497875968) finish=41.3min speed=200480K/sec + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2] nvme1n1p2[1] + 1046528 blocks super 1.2 [2/2] [UU] +``` + +Once the RAID rebuild is complete, run the following command to make sure that the partitions have been properly added to the RAID: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART 4629-D183 +├─nvme1n1p2 linux_raid_member 1.2 md2 83719c5c-2a27-2a56-5268-7d49d8a1d84f +│ └─md2 ext4 1.0 boot 4de80ae0-dd90-4256-9135-1735e7be4b4d +├─nvme1n1p3 linux_raid_member 1.2 md3 b383c3d5-7fb1-bb5e-6b7c-4d966ea817ff +│ └─md3 ext4 1.0 root 9bf386b6-9523-46bf-b8e5-4b8cc7c5786f +└─nvme1n1p4 swap 1 swap-nvme1n1p4 9bf292e8-0145-4d2f-b891-4cef93c0d209 +nvme0n1 +├─nvme0n1p1 +├─nvme0n1p2 linux_raid_member 1.2 md2 83719c5c-2a27-2a56-5268-7d49d8a1d84f +│ └─md2 ext4 1.0 boot 4de80ae0-dd90-4256-9135-1735e7be4b4d +├─nvme0n1p3 linux_raid_member 1.2 md3 b383c3d5-7fb1-bb5e-6b7c-4d966ea817ff +│ └─md3 ext4 1.0 root 9bf386b6-9523-46bf-b8e5-4b8cc7c5786f +└─nvme0n1p4 +``` + +Based on the above results, 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 as they are not included in the RAID. + +> [!warning] +> 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](#go-further) section of this guide. +> + + + +#### Recreating the EFI System Partition + +To recreate the EFI system partition, 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. + +> [!warning] +> If there was a major system update such as kernel or grub and both partitions were not synchronised, consult this [section](#rebuilding-raid-when-efi-partitions-are-not-synchronized-after-major-system-updates-eg-grub) once you are done creating the new EFI System Partition. +> + +First, we format the partition: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkfs.vfat /dev/nvme0n1p1 +``` + +Next, we label the partition as `EFI_SYSPART` (this naming is specific to OVHcloud): + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # fatlabel /dev/nvme0n1p1 EFI_SYSPART +``` + +Next, we duplicate the contents of nvme1n1p1 to nvme0n1p1. We start by creating two folders, We start by creating two folders, which we name "old" and "new" in our example: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkdir old new +``` + +Next, we mount **nvme1n1p1** in the 'old' folder and **nvme0n1p1** in the 'new' folder to make the distinction: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/nvme1n1p1 old +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/nvme0n1p1 new +``` + +Next, we copy the files from the 'old' folder to 'new' one: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # rsync -axv old/ new/ +sending incremental file list +EFI/ +EFI/debian/ +EFI/debian/BOOTX64.CSV +EFI/debian/fbx64.efi +EFI/debian/grub.cfg +EFI/debian/grubx64.efi +EFI/debian/mmx64.efi +EFI/debian/shimx64.efi + +sent 6,099,848 bytes received 165 bytes 12,200,026.00 bytes/sec +total size is 6,097,843 speedup is 1.00 +``` + +Once this is done, we unmount both partitions: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount /dev/nvme0n1p1 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount /dev/nvme1n1p1 +``` + +Next, we mount the partition containing the root of our operating system on `/mnt`. In our example, that partition is **md3**. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md3 /mnt +``` + +We mount the following directories to make sure any manipulation we make in the `chroot` environment works properly: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Next, we use the `chroot` command to access the mount point and make sure the new EFI System Partition has been properly created and the system recongnises both ESPs: + +```sh +root@rescue12-customer-eu:/# chroot /mnt +``` + +To view the ESP partitions, we run the command `blkid -t LABEL=EFI_SYSPART`: + +```sh +root@rescue12-customer-eu:/# blkid -t LABEL=EFI_SYSPART +/dev/nvme1n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="4629-D183" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="889f241b-49c3-4031-b5c9-60df0746f98f" +/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="521F-300B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="02bf2b2d-7ada-4461-ba50-07683519f65d" +``` + +The above results show that the new EFI partition has been created correctly and that the LABEL has been applied correctly. + + + +#### Rebuilding RAID when EFI partitions are not synchronized after major system updates (GRUB) + +/// details | Unfold this section + +> [!warning] +> Please only follow the steps in this section if it applies to your case. +> + +When EFI system partitions are not synchronised after major system updates that modify/affect the GRUB, and the primary disk on which the partition is mounted is replaced, booting from a secondary disk containing an out-of-date ESP may not work. + +In this case, in addition to rebuilding the RAID and recreating the EFI system partition in rescue mode, you must also reinstall GRUB on it. + +So once we have recreated the EFI partition and made sure the system recognises both partitions (previous steps in `chroot`), we create the `/boot/efi` folder in order to mount the new EFI System Partition **nvme0n1p1**: + +```sh +root@rescue12-customer-eu:/# mount /boot +root@rescue12-customer-eu:/# mount /dev/nvme0n1p1 /boot/efi +``` + +Next, we reinstall the GRUB bootloader: + +```sh +root@rescue12-customer-eu:/# grub-install --efi-directory=/boot/efi /dev/nvme0n1p1 +``` + +Once done, run the following command: + +```sh +root@rescue12-customer-eu:/# update-grub +``` +/// + + + +#### Adding the label to the SWAP partition (if applicable) + +Once we are done with the EFI partition, we move to the SWAP partition. + +We exit the `chroot` environment with `exit` in order to recreate our [SWAP] partition **nvme0n1p4** and add the label `swap-nvmenxxx`: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/nvme0n1p4 -L swap-nvme0n1p4 +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-nvme0n1p4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +We verify that the label has been properly applied: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS +nvme1n1 + +├─nvme1n1p1 +│ vfat FAT16 EFI_SYSPART +│ BA77-E844 504.9M 1% /root/old +├─nvme1n1p2 +│ linux_ 1.2 md2 53409058-480a-bc65-4e1d-6acc848fe233 +│ └─md2 +│ ext4 1.0 boot f925a033-0087-40ec-817e-44efab0351ac +├─nvme1n1p3 +│ linux_ 1.2 md3 a3b8816c-a5c3-7f01-ee17-e1aa9685c35c +│ └─md3 +│ ext4 1.0 root 6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 441.2G 0% /mnt +└─nvme1n1p4 + swap 1 swap-nvme1n1p4 + d6af33cf-fc15-4060-a43c-cb3b5537f58a +nvme0n1 + +├─nvme0n1p1 +│ vfat FAT16 EFI_SYSPART +│ 477D-6658 +├─nvme0n1p2 +│ linux_ 1.2 md2 53409058-480a-bc65-4e1d-6acc848fe233 +│ └─md2 +│ ext4 1.0 boot f925a033-0087-40ec-817e-44efab0351ac +├─nvme0n1p3 +│ linux_ 1.2 md3 a3b8816c-a5c3-7f01-ee17-e1aa9685c35c +│ └─md3 +│ ext4 1.0 root 6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 441.2G 0% /mnt +└─nvme0n1p4 + swap 1 swap-nvme0n1p4 + b3c9e03a-52f5-4683-81b6-cc10091fcd15 +``` + +We then access the `chroot` environment again: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +We retrieve the UUID of both swap partitions: + +```sh +root@rescue12-customer-eu:/# blkid -s UUID blkid /dev/nvme0n1p4 +/dev/nvme0n1p4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" + +root@rescue12-customer-eu:/# blkid -s UUID blkid /dev/nvme1n1p4 +/dev/nvme1n1p4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Next, we replace the old UUID of the swap partition (**nvme0n1p4**) with the new one in the `/etc/fstab` file: + +```sh +root@rescue12-customer-eu:/# nano /etc/fstab +``` + +Example: + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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, we verify that everything is properly mounted with the following command: + +```sh +root@rescue12-customer-eu:/# mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +We activate the swap partition: + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/nvme0n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme0n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme0n1p4 +swapon: /dev/nvme1n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme1n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme1n1p4 +``` + +We exit the chroot environment with `exit` and reload the system: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +We umount all the disks: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -Rl /mnt +``` + +We have now successfully completed the RAID rebuild on the server and we can now reboot it in normal mode. + + + +#### Rebuilding the RAID in normal mode + +/// details | Unfold this section + +If your server is able to boot in normal mode after a disk replacement, you can proceed with the following steps to rebuild the RAID. + +Once the disk has been replaced, we copy the partition table from the healthy disk (in this example, nvme1n1) to the new one (nvme0n1). + +**For GPT partitions** + +```sh +sgdisk -R /dev/nvme0n1 /dev/nvme1n1 +``` + +The command should be in this format: `sgdisk -R /dev/new disk /dev/healthy disk`. + +Once this is done, the next step is to randomize the GUID of the new disk to prevent GUID conflicts with other disks: + +```sh +sgdisk -G /dev/nvme0n1 +``` + +If you receive the following message: + +```console +Warning: The kernel is still using the old partition table. +The new table will be used at the next reboot or after you +run partprobe(8) or kpartx(8) +The operation has completed successfully. +``` + +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, we add the partitions to the RAID: + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/nvme0n1p2 + +# mdadm: added /dev/nvme0n1p2 + +[user@server_ip ~]# sudo mdadm --add /dev/md3 /dev/nvme0n1p3 + +# mdadm: re-added /dev/nvme0n1p3 +``` + +Use the following command to follow the RAID rebuild: `cat /proc/mdstat`. + +**Recreating the EFI System Partition on the disk** + +First, we install the necessary tools: + +**Debian and Ubuntu** + +```sh +[user@server_ip ~]# sudo apt install dosfstools +``` + +**CentOS** + +```sh +[user@server_ip ~]# sudo yum install dosfstools +``` + +Next, we format the partition. In our example `nvme0n1p1`: + +```sh +[user@server_ip ~]# sudo mkfs.vfat /dev/nvme0n1p1 +``` + +Next, we label the partition as `EFI_SYSPART` (this naming is specific to OVHcloud) + +```sh +[user@server_ip ~]# sudo fatlabel /dev/nvme0n1p1 EFI_SYSPART +``` + +Once done, you can synchronize both partitions using the script we provided [here](#script). + +We verify that the new EFI System Partition has been properly created and the system recongnises it: + +```sh +[user@server_ip ~]# sudo blkid -t LABEL=EFI_SYSPART +/dev/nvme1n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="4629-D183" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="889f241b-49c3-4031-b5c9-60df0746f98f" +/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="521F-300B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="02bf2b2d-7ada-4461-ba50-07683519f65d" +``` + +Lastly, we activate the [SWAP] partition (if applicable): + + +- We create and add the label: + +```sh +[user@server_ip ~]# sudo mkswap /dev/nvme0n1p4 -L swap-nvme0n1p4 +``` + +- We retrieve the UUIDs of both swap partitions: + +```sh +[user@server_ip ~]# sudo blkid -s /dev/nvme0n1p4 +/dev/nvme0n1p4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -s /dev/nvme1n1p4 +/dev/nvme1n1p4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +- We replace the old UUID of the swap partition (**nvme0n1p4)** with the new one in `/etc/fstab`: + +```sh +[user@server_ip ~]# sudo nano /etc/fstab +``` + +Example: + +```sh +[user@server_ip ~]# sudo nano /etc/fstab +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +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, we run the following command to activate the swap partition: + +```sh +[user@server_ip ~]# sudo swapon -av +swapon: /dev/nvme0n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme0n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme0n1p4 +swapon: /dev/nvme1n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme1n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme1n1p4 +``` + +Next, we reload the system: + +```sh +[user@server_ip ~]# sudo systemctl daemon-reload +``` + +We have now successfully completed the RAID rebuild. + +## Go Further + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) + +[OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) + +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +For specialised services (SEO, development, etc.), contact [OVHcloud partners](/links/partner). + +If you would like assistance using and configuring your OVHcloud solutions, please refer to our [support offers](/links/support). + +If you need training or technical assistance to implement our solutions, contact your sales representative or click on [this link](/links/professional-services) 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](/links/community). \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.fr-fr.md b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.fr-fr.md new file mode 100644 index 00000000000..e958d4c3c0a --- /dev/null +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/guide.fr-fr.md @@ -0,0 +1,1063 @@ +--- +title: "Gestion et reconstruction d'un RAID logiciel sur les serveurs utilisant le mode de démarrage UEFI" +excerpt: Découvrez comment gérer et reconstruire un RAID logiciel après un remplacement de disque sur un serveur utilisant le mode de démarrage UEFI +updated: 2025-12-11 +--- + +## Objectif + +Un Redundant Array of Independent Disks (RAID) est une technologie qui atténue la perte de données sur un serveur en répliquant les données sur deux disques ou plus. + +Le niveau RAID par défaut pour les installations de serveurs OVHcloud est le RAID 1, qui double l'espace occupé par vos données, réduisant ainsi l'espace disque utilisable de moitié. + +**Ce guide explique comment gérer et reconstruire un RAID logiciel après un remplacement de disque sur votre serveur en mode EFI** + +Avant de commencer, veuillez noter que ce guide se concentre sur les serveurs dédiés qui utilisent le mode UEFI comme mode de démarrage. C'est le cas des cartes mères modernes. Si votre serveur utilise le mode de démarrage legacy (BIOS), veuillez consulter ce guide : [Gestion et reconstruction d'un RAID logiciel sur des serveurs en mode de démarrage legacy (BIOS)](/pages/bare_metal_cloud/dedicated_servers/raid_soft_bios). + +Pour vérifier si un serveur fonctionne en mode BIOS legacy ou en mode UEFI, exécutez la commande suivante : + +```sh +[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS +``` + +Pour plus d'informations sur l'UEFI, consultez l'article suivant : [https://uefi.org/about](https://uefi.org/about). + +## Prérequis + +- Un [serveur dédié](/links/bare-metal/bare-metal) avec une configuration RAID logiciel +- Un accès administrateur (sudo) au serveur via SSH +- Une compréhension du RAID, des partitions et de GRUB + +Au cours de ce guide, nous utilisons les termes **disque principal** et **disque secondaire**. Dans ce contexte : + +- Le disque principal est le disque dont l'ESP (EFI System Partition) est monté par Linux +- Les disques secondaires sont tous les autres disques du RAID + +## En pratique + +Lorsque vous achetez un nouveau serveur, vous pouvez ressentir le besoin d'effectuer une série de tests et d'actions. Un tel test pourrait être de simuler une panne de disque afin de comprendre le processus de reconstruction du RAID et de vous préparer en cas de problème. + +### Aperçu du contenu + +- [Informations de base](#basicinformation) +- [Compréhension de la partition système EFI (ESP)](#efisystemparition) +- [Simulation d'une panne de disque](#diskfailure) + - [Suppression du disque défectueux](#diskremove) +- [Reconstruction du RAID](#raidrebuild) + - [Reconstruction du RAID après le remplacement du disque principal (mode de secours)](#rescuemode) + - [Recréation de la partition système EFI](#recreateesp) + - [Reconstruction du RAID lorsque les partitions EFI ne sont pas synchronisées après des mises à jour majeures du système (ex. GRUB)](efiraodgrub) + - [Ajout de l'étiquette à la partition SWAP (si applicable)](#swap-partition) + - [Reconstruction du RAID en mode normal](#normalmode) + + + +### Informations de base + +Dans une session de ligne de commande, tapez la commande suivante pour déterminer l'état actuel du RAID : + +```sh +[user@server_ip ~]# cat /proc/mdstat +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md3 : active raid1 nvme1n1p3[1] nvme0n1p3[0] + 497875968 blocks super 1.2 [2/2] [UU] + bitmap: 2/4 pages [8KB], 65536KB chunk + +md2 : active raid1 nvme1n1p2[1] nvme0n1p2[0] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +Cette commande nous montre que nous avons actuellement deux volumes RAID logiciels configurés, **md2** et **md3**, avec **md3** étant le plus grand des deux. **md3** se compose de deux partitions, appelées **nvme1n1p3** et **nvme0n1p3**. + +Le [UU] signifie que tous les disques fonctionnent normalement. Un `_` indiquerait un disque défectueux. + +Si vous avez un serveur avec des disques SATA, vous obtiendrez les résultats suivants : + +```sh +[user@server_ip ~]# cat /proc/mdstat +Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] +md3 : active raid1 sda3[0] sdb3[1] + 3904786432 blocks super 1.2 [2/2] [UU] + bitmap: 2/30 pages [8KB], 65536KB chunk + +md2 : active raid1 sda2[0] sdb2[1] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +Bien que cette commande retourne nos volumes RAID, elle ne nous indique pas la taille des partitions elles-mêmes. Nous pouvons trouver cette information avec la commande suivante : + +```sh +[user@server_ip ~]# sudo fdisk -l + +Disk /dev/nvme1n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors +Disk model: WDC CL SN720 SDAQNTW-512G-2000 +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: gpt +Disk identifier: A11EDAA3-A984-424B-A6FE-386550A92435 + +Device Start End Sectors Size Type +/dev/nvme1n1p1 2048 1048575 1046528 511M EFI System +/dev/nvme1n1p2 1048576 3145727 2097152 1G Linux RAID +/dev/nvme1n1p3 3145728 999161855 996016128 474.9G Linux RAID +/dev/nvme1n1p4 999161856 1000210431 1048576 512M Linux files + + +Disk /dev/nvme0n1: 476.94 GiB, 512110190592 bytes, 1000215216 sectors +Disk model: WDC CL SN720 SDAQNTW-512G-2000 +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +Disklabel type: gpt +Disk identifier: F03AC3C3-D7B7-43F9-88DB-9F12D7281D94 + +Device Start End Sectors Size Type +/dev/nvme0n1p1 2048 1048575 1046528 511M EFI System +/dev/nvme0n1p2 1048576 3145727 2097152 1G Linux RAID +/dev/nvme0n1p3 3145728 999161855 996016128 474.9G Linux RAID +/dev/nvme0n1p4 999161856 1000210431 1048576 512M Linux file +/dev/nvme0n1p5 1000211120 1000215182 4063 2M Linux file + + +Disk /dev/md2: 1022 MiB, 1071644672 bytes, 2093056 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes + + +Disk /dev/md3: 474.81 GiB, 509824991232 bytes, 995751936 sectors +Units: sectors of 1 * 512 = 512 bytes +Sector size (logical/physical): 512 bytes / 512 bytes +I/O size (minimum/optimal): 512 bytes / 512 bytes +``` + +La commande `fdisk -l` permet également d'identifier le type de vos partitions. C'est une information importante lors de la reconstruction de votre RAID en cas de panne de disque. + +Pour les partitions **GPT**, la ligne 6 affichera : `Disklabel type: gpt`. + +Toujours en se basant sur les résultats de `fdisk -l`, nous pouvons voir que `/dev/md2` se compose de 1022 MiB et `/dev/md3` contient 474,81 GiB. Si nous exécutons la commande `mount`, nous pouvons également trouver la disposition des disques. + +En alternative, la commande `lsblk` offre une vue différente des partitions : + +```sh +[user@server_ip ~]# lsblk +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:7 0 511M 0 part +├─nvme1n1p2 259:8 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 /boot +├─nvme1n1p3 259:9 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 / +└─nvme1n1p4 259:10 0 512M 0 part [SWAP] +nvme0n1 259:1 0 476.9G 0 disk +├─nvme0n1p1 259:2 0 511M 0 part /boot/efi +├─nvme0n1p2 259:3 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 /boot +├─nvme0n1p3 259:4 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 / +├─nvme0n1p4 259:5 0 512M 0 part [SWAP] +└─nvme0n1p5 259:6 0 2M 0 part +``` + +De plus, si nous exécutons `lsblk -f`, nous obtenons davantage d'informations sur ces partitions, telles que le LABEL et l'UUID : + +```sh +[user@server_ip ~]# sudo lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART B493-9DFA +├─nvme1n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme1n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +└─nvme1n1p4 swap 1 swap-nvme1n1p4 483b9b41-ada3-4143-8cac-5bff7afb73c7 [SWAP] +nvme0n1 +├─nvme0n1p1 vfat FAT16 EFI_SYSPART B486-9781 504.9M 1% /boot/efi +├─nvme0n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme0n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +├─nvme0n1p4 swap 1 swap-nvme0n1p4 51e7172b-adb0-4729-b0f8-613e5dede38b [SWAP] +└─nvme0n1p5 iso9660 Joliet Extension config-2 2025-08-05-14-55-41-00 +``` + +Prenez note des dispositifs, des partitions et de leurs points de montage ; c'est important, surtout après le remplacement d'un disque. + +À partir des commandes et résultats ci-dessus, nous avons : + +- Deux matrices RAID : `/dev/md2` et `/dev/md3`. +- Quatre partitions qui font partie du RAID : **nvme0n1p2**, **nvme0n1p3**, **nvme1n1p2**, **nvme0n1p3** avec les points de montage `/boot` et `/`. +- Deux partitions non incluses dans le RAID, avec les points de montage : `/boot/efi` et [SWAP]. +- Une partition qui ne possède pas de point de montage : **nvme1n1p1** + +La partition `nvme0n1p5` est une partition de configuration, c'est-à-dire un volume en lecture seule connecté au serveur qui lui fournit les données de configuration initiale. + + + +### Comprendre la partition système EFI (ESP) + +***Qu'est-ce qu'une partition système EFI ?*** + +Une partition système EFI est une partition sur laquelle le serveur demarre. Elle contient les fichiers de démarrage, mais aussi les gestionnaires de démarrage ou les images de noyau d'un système d'exploitation installé. Elle peut également contenir des programmes utilitaires conçus pour être exécutés avant que le système d'exploitation ne démarre, ainsi que des fichiers de données tels que des journaux d'erreurs. + +***La partition système EFI est-elle incluse dans le RAID ?*** + +Non, à partir d'août 2025, lorsqu'une installation du système d'exploitation est effectuée par OVHcloud, la partition ESP n'est pas incluse dans le RAID. Lorsque vous utilisez nos modèles d'OS pour installer votre serveur avec un RAID logiciel, plusieurs partitions système EFI sont créées : une par disque. Cependant, seule une partition EFI est montée à la fois. Toutes les ESP créées contiennent les mêmes fichiers. Tous les ESP créés au moment de l'installation contiennent les mêmes fichiers. + +La partition système EFI est montée à `/boot/efi` et le disque sur lequel elle est montée est sélectionné par Linux au démarrage. + +Exemple : + +```sh +[user@server_ip ~]# sudo lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART B493-9DFA +├─nvme1n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme1n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +└─nvme1n1p4 swap 1 swap-nvme1n1p4 483b9b41-ada3-4143-8cac-5bff7afb73c7 [SWAP] +nvme0n1 +├─nvme0n1p1 vfat FAT16 EFI_SYSPART B486-9781 504.9M 1% /boot/efi +├─nvme0n1p2 linux_raid_member 1.2 md2 baae988b-bef3-fc07-615f-6f9043cfd5ea +│ └─md2 ext4 1.0 boot 96850c4e-e2b5-4048-8c39-525194e441aa 851.8M 7% /boot +├─nvme0n1p3 linux_raid_member 1.2 md3 ce0c7fac-0032-054c-eef7-7463b2245519 +│ └─md3 ext4 1.0 root 6fea39e9-6297-4ea3-82f1-bf1a3e88106a 441.3G 0% / +├─nvme0n1p4 swap 1 swap-nvme0n1p4 51e7172b-adb0-4729-b0f8-613e5dede38b [SWAP] +└─nvme0n1p5 iso9660 Joliet Extension config-2 2025-08-05-14-55-41-00 +``` + +D'après les résultats ci-dessus, nous voyons que nous avons deux partitions système EFI identiques (nvme0n1p1 et nvme1n1p1), mais seule **nvme0n1p1** est montée sur `/boot/efi`. Les deux partitions ont le LABEL : `EFI_SYSPART` (ce nommage est spécifique à OVHcloud). + +***Le contenu de la partition système EFI change-t-il régulièrement ?*** + +En général, le contenu de cette partition ne change pas beaucoup, son contenu ne devrait changer que lors des mises à jour du chargeur d'amorçage (*bootloader*). + +Cependant, nous recommandons d'exécuter un script automatique ou manuel pour synchroniser tous les ESP, afin qu'ils contiennent tous les mêmes fichiers à jour. De cette façon, si le disque sur lequel cette partition est montée tombe en panne, le serveur pourra redémarrer sur l'ESP de l'un des autres disques. + +***Que se passe-t-il si le disque principal monté sur `boot/efi` tombe en panne ?*** + +> [!primary] +> Veuillez noter que nous explorons ci-dessous les cas les plus courants, mais il existe plusieurs autres raisons pour lesquelles un serveur ne pourrait pas démarrer en mode normal après un remplacement de disque. +> + +**Étude de cas 1** - Il n'y a eu aucun changement ou mise à jour majeure du système (par exemple GRUB) + +- Le serveur est capable de démarrer en mode normal et vous pouvez procéder à la reconstruction du RAID. +- Le serveur n'est pas capable de démarrer en mode normal, le serveur est redémarré en mode rescue, où vous pouvez reconstruire le RAID et recréer la partition EFI sur le nouveau disque. + +**Étude de cas 2** - Il y a eu des mises à jour majeures du système (par exemple GRUB) et les ESP ont été synchronisées + +- Le serveur est capable de démarrer en mode normal car toutes les ESP contiennent des informations à jour et la reconstruction du RAID peut être effectuée en mode normal. +- Le serveur n'est pas capable de démarrer en mode normal, le serveur est redémarré en mode rescue, où vous pouvez reconstruire le RAID et recréer la partition système EFI sur le nouveau disque. + +**Étude de cas 3** - Il y a eu des mises à jour majeures du système (par exemple GRUB) et les partitions ESP n'ont pas été synchronisées + +- Le serveur n'est pas capable de démarrer en mode normal, le serveur est redémarré en mode rescue, où vous pouvez reconstruire le RAID, recréer la partition système EFI sur le nouveau disque et réinstaller le chargeur de démarrage (bootloader) sur celui-ci. +- Le serveur est capable de démarrer en mode normal (cela pourrait arriver dans le cas où un système d'exploitation est mis à jour vers une version plus récente mais que la version de GRUB reste inchangée) et vous pouvez procéder à la reconstruction du RAID. + +En effet, dans certains cas, le démarrage à partir d'une ESP obsolète ne fonctionne pas. Par exemple, une mise à jour majeure de GRUB pourrait rendre l'ancienne version de GRUB présente dans l'ESP incompatible avec les modules GRUB plus récents installés dans la partition `/boot`. + +***Comment puis-je synchroniser mes partitions système EFI, et à quelle fréquence devrais-je les synchroniser ?*** + +> [!primary] +> Veuillez noter que selon votre système d'exploitation, le processus peut être différent. Par exemple, Ubuntu est capable de garder plusieurs partitions système EFI synchronisées à chaque mise à jour de GRUB. Cependant, c'est le seul système d'exploitation qui le fait. Nous vous recommandons de consulter la documentation officielle de votre système d'exploitation pour comprendre comment gérer les ESP. +> +> Dans ce guide, le système d'exploitation utilisé est Debian. + +Nous vous recommandons de synchroniser vos ESP régulièrement ou après chaque mise à jour majeure du système. Par défaut, toutes les partitions système EFI contiennent les mêmes fichiers après l'installation. Cependant, si une mise à jour majeure du système est impliquée, la synchronisation des ESP est essentielle pour garder le contenu à jour. + + + +#### Script + +Voici un script que vous pouvez utiliser pour les synchroniser manuellement. Vous pouvez également exécuter un script automatisé pour synchroniser les partitions quotidiennement ou chaque fois que le service démarre. + +Avant d'exécuter le script, assurez-vous que `rsync` est installé sur votre système : + +**Debian/Ubuntu** + +```sh +sudo apt install rsync +``` + +**CentOS, Red Hat et Fedora** + +```sh +sudo yum install rsync +``` + +Pour exécuter un script sous Linux, vous avez besoin d'un fichier exécutable : + +- Commencez par créer un fichier .sh dans le répertoire de votre choix, en remplaçant `nom-du-script` par le nom de votre choix. + +```sh +sudo touch nom-du-script.sh +``` + +- Ouvrez le fichier avec un éditeur de texte et ajoutez les lignes suivantes : + +```sh +sudo nano nom-du-script.sh +``` + +```sh +#!/bin/bash + +set -euo pipefail + +MOUNTPOINT="/var/lib/grub/esp" +MAIN_PARTITION=$(findmnt -n -o SOURCE /boot/efi) + +echo "${MAIN_PARTITION} est la partition principale" + +mkdir -p "${MOUNTPOINT}" + +while read -r partition; do + if [[ "${partition}" == "${MAIN_PARTITION}" ]]; then + continue + fi + echo "Travail sur ${partition}" + mount "${partition}" "${MOUNTPOINT}" + rsync -ax "/boot/efi/" "${MOUNTPOINT}/" + umount "${MOUNTPOINT}" +done < <(blkid -o device -t LABEL=EFI_SYSPART) +``` + +Enregistrez et fermez le fichier. + +- Rendez le script exécutable + +```sh +sudo chmod +x nom-du-script.sh +``` + +- Exécutez le script + +```sh +sudo ./nom-du-script.sh +``` + +- Si vous n'êtes pas dans le dossier + +```sh +./chemin/vers/dossier/nom-du-script.sh +``` + +Lorsque le script est exécuté, le contenu de la partition EFI montée sera synchronisé avec les autres. Pour accéder au contenu, vous pouvez monter l'une de ces partitions EFI non montées sur le point de montage : `/var/lib/grub/esp`. + + + +### Simulation d'une panne de disque + +Maintenant que nous avons toutes les informations nécessaires, nous pouvons simuler une panne de disque et procéder aux tests. Dans ce premier exemple, nous allons provoquer une défaillance du disque principal `nvme0n1`. + +La méthode préférée pour le faire est via le mode rescue d'OVHcloud. + +Redémarrez d'abord le serveur en mode rescue et connectez-vous avec les identifiants fournis. + +Pour retirer un disque du RAID, la première étape est de le marquer comme **Failed** et de retirer les partitions de leurs tableaux RAID respectifs. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[0] nvme1n1p3[1] + 497875968 blocks super 1.2 [2/2] [UU] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2] nvme1n1p2[1] + 1046528 blocks super 1.2 [2/2] [UU] + +unused devices: +``` + +À partir du résultat ci-dessus, nvme0n1 comporte deux partitions en RAID qui sont **nvme0n1p2** et **nvme0n1p3**. + + + +#### Retrait du disque défectueux + +Tout d'abord, nous marquons les partitions **nvme0n1p2** et **nvme0n1p3** comme défectueuses. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/nvme0n1p2 +# mdadm: set /dev/nvme0n1p2 faulty in /dev/md2 +``` + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md3 --fail /dev/nvme0n1p3 +# mdadm: set /dev/nvme0n1p3 faulty in /dev/md3 +``` + +Lorsque nous exécutons la commande `cat /proc/mdstat`, nous obtenons : + +```sh +root@rescue12-customer-ca (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[0](F) nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2](F) nvme1n1p2[1] + 1046528 blocks super 1.2 [2/1] [_U] + +unused devices: +``` + +Comme nous pouvons le voir ci-dessus, le [F] à côté des partitions indique que le disque est défectueux ou en panne. + +Ensuite, nous retirons ces partitions des tableaux RAID pour supprimer complètement le disque du RAID. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --remove /dev/nvme0n1p2 +# mdadm: hot removed /dev/nvme0n1p2 from /dev/md2 +``` + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md3 --remove /dev/nvme0n1p3 +# mdadm: hot removed /dev/nvme0n1p3 from /dev/md3 +``` + +L'état de notre RAID devrait maintenant ressembler à ceci : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme1n1p2[1] + 1046528 blocks super 1.2 [2/1] [_U] + +unused devices: +``` + +D'après les résultats ci-dessus, nous pouvons voir qu'il n'y a désormais que deux partitions dans les tableaux RAID. Nous avons réussi à dégrader le disque **nvme0n1**. + +Pour nous assurer d'obtenir un disque similaire à un disque vide, nous utilisons la commande suivante sur chaque partition, puis sur le disque lui-même : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +shred -s10M -n1 /dev/nvme0n1p1 +shred -s10M -n1 /dev/nvme0n1p2 +shred -s10M -n1 /dev/nvme0n1p3 +shred -s10M -n1 /dev/nvme0n1p4 +shred -s10M -n1 /dev/nvme0n1p5 +shred -s10M -n1 /dev/nvme0n1 +``` + +Le disque apparaît désormais comme un disque neuf et vide : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk + +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:1 0 511M 0 part +├─nvme1n1p2 259:2 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 +├─nvme1n1p3 259:3 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 +└─nvme1n1p4 259:4 0 512M 0 part +nvme0n1 259:5 0 476.9G 0 disk +``` + +Si nous exécutons la commande suivante, nous constatons que notre disque a été correctement "effacé" : + +```sh +parted /dev/nvme0n1 +GNU Parted 3.5 +Using /dev/nvme0n1 +Welcome to GNU Parted! Type 'help' to view a list of commands. +(parted) p +Error: /dev/nvme0n1: unrecognised disk label +Model: WDC CL SN720 SDAQNTW-512G-2000 (nvme) +Disk /dev/nvme0n1: 512GB +Sector size (logical/physical): 512B/512B +Partition Table: unknown +Disk Flags: +``` + +Pour plus d'informations sur la préparation et la demande de remplacement d'un disque, consultez ce [guide](/pages/bare_metal_cloud/dedicated_servers/disk_replacement). + +Si vous exécutez la commande suivante, vous pouvez obtenir davantage de détails sur les tableaux RAID : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md3 + +/dev/md3: + Version : 1.2 + Creation Time : Fri Aug 1 14:51:13 2025 + Raid Level : raid1 + Array Size : 497875968 (474.81 GiB 509.82 GB) + Used Dev Size : 497875968 (474.81 GiB 509.82 GB) + Raid Devices : 2 + Total Devices : 1 + Persistence : Superblock is persistent + + Intent Bitmap : Internal + + Update Time : Fri Aug 1 15:56:17 2025 + State : clean, degraded + Active Devices : 1 + Working Devices : 1 + Failed Devices : 0 + Spare Devices : 0 + +Consistency Policy : bitmap + + Name : md3 + UUID : b383c3d5:7fb1bb5e:6b7c4d96:6ea817ff + Events : 215 + + Number Major Minor RaidDevice State + - 0 0 0 removed + 1 259 4 1 active sync /dev/nvme1n1p3 +``` + +Nous pouvons maintenant procéder au remplacement du disque. + + + +### Reconstruction du RAID + +> [!primary] +> Ce processus peut varier selon le système d'exploitation installé sur votre serveur. Nous vous recommandons de consulter la documentation officielle de votre système d'exploitation pour obtenir les commandes appropriées. +> + +> [!warning] +> +> Sur la plupart des serveurs en RAID logiciel, après un remplacement de disque, le serveur est capable de démarrer en mode normal (sur le disque sain) et la reconstruction peut être effectuée en mode normal. Cependant, si le serveur ne parvient pas à démarrer en mode normal après le remplacement du disque, il redémarrera en mode rescue pour procéder à la reconstruction du RAID. +> +> Si votre serveur est capable de démarrer en mode normal après le remplacement du disque, suivez simplement les étapes de [cette section](#rebuilding-the-raid-in-normal-mode). + + + +#### Reconstruction du RAID en mode rescue + +Une fois le disque remplacé, l'étape suivante consiste à copier la table de partitions du disque sain (dans cet exemple, nvme1n1) sur le nouveau (nvme0n1). + +**Pour les partitions GPT** + +La commande doit être dans ce format : `sgdisk -R /dev/nouveau disque /dev/disque sain` + +Dans notre exemple : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/nvme0n1 /dev/nvme1n1 +``` + +Exécutez `lsblk` pour vous assurer que les tables de partitions ont été correctement copiées : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk + +NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS +nvme1n1 259:0 0 476.9G 0 disk +├─nvme1n1p1 259:1 0 511M 0 part +├─nvme1n1p2 259:2 0 1G 0 part +│ └─md2 9:2 0 1022M 0 raid1 +├─nvme1n1p3 259:3 0 474.9G 0 part +│ └─md3 9:3 0 474.8G 0 raid1 +└─nvme1n1p4 259:4 0 512M 0 part +nvme0n1 259:5 0 476.9G 0 disk +├─nvme0n1p1 259:10 0 511M 0 part +├─nvme0n1p2 259:11 0 1G 0 part +├─nvme0n1p3 259:12 0 474.9G 0 part +└─nvme0n1p4 259:13 0 512M 0 part +``` + +Une fois cela fait, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque afin d'éviter les conflits de GUID avec d'autres disques : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -G /dev/nvme0n1 +``` + +Si vous recevez le message suivant : + +```console +Warning: The kernel is still using the old partition table. +The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) +The operation has completed successfully. +``` + +Exécutez simplement la commande `partprobe`. + +Nous pouvons maintenant reconstruire la matrice RAID. L'extrait de code suivant montre comment ajouter à nouveau les nouvelles partitions (nvme0n1p2 et nvme0n1p3) à la matrice RAID. + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --add /dev/md2 /dev/nvme0n1p2 +# mdadm: added /dev/nvme0n1p2 + +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --add /dev/md3 /dev/nvme0n1p3 +# mdadm: re-added /dev/nvme0n1p3 +``` + +Pour vérifier le processus de reconstruction : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat +Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty] +md3 : active raid1 nvme0n1p3[2] nvme1n1p3[1] + 497875968 blocks super 1.2 [2/1] [_U] + [>....................] recovery = 0.1% (801920/497875968) finish=41.3min speed=200480K/sec + bitmap: 0/4 pages [0KB], 65536KB chunk + +md2 : active raid1 nvme0n1p2[2] nvme1n1p2[1] + 1046528 blocks super 1.2 [2/2] [UU] +``` + +Une fois la reconstruction du RAID terminée, exécutez la commande suivante pour vous assurer que les partitions ont été correctement ajoutées au RAID : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS +nvme1n1 +├─nvme1n1p1 vfat FAT16 EFI_SYSPART 4629-D183 +├─nvme1n1p2 linux_raid_member 1.2 md2 83719c5c-2a27-2a56-5268-7d49d8a1d84f +│ └─md2 ext4 1.0 boot 4de80ae0-dd90-4256-9135-1735e7be4b4d +├─nvme1n1p3 linux_raid_member 1.2 md3 b383c3d5-7fb1-bb5e-6b7c-4d966ea817ff +│ └─md3 ext4 1.0 root 9bf386b6-9523-46bf-b8e5-4b8cc7c5786f +└─nvme1n1p4 swap 1 swap-nvme1n1p4 9bf292e8-0145-4d2f-b891-4cef93c0d209 +nvme0n1 +├─nvme0n1p1 +├─nvme0n1p2 linux_raid_member 1.2 md2 83719c5c-2a27-2a56-5268-7d49d8a1d84f +│ └─md2 ext4 1.0 boot 4de80ae0-dd90-4256-9135-1735e7be4b4d +├─nvme0n1p3 linux_raid_member 1.2 md3 b383c3d5-7fb1-bb5e-6b7c-4d966ea817ff +│ └─md3 ext4 1.0 root 9bf386b6-9523-46bf-b8e5-4b8cc7c5786f +└─nvme0n1p4 +``` + +D'après les résultats ci-dessus, les partitions du nouveau disque ont été correctement ajoutées au RAID. Toutefois, la partition EFI System et la partition SWAP (dans certains cas) n'ont pas été dupliquées, ce qui est normal car elles ne font pas partie du RAID. + +> [!warning] +> Les exemples ci-dessus illustrent simplement les étapes nécessaires sur la base d'une configuration de serveur par défaut. Les résultats de chaque commande dépendent du type de matériel installé sur votre serveur et de la structure de ses partitions. En cas de doute, consultez la documentation de votre système d'exploitation. +> +> Si vous avez besoin d'une assistance professionnelle pour l'administration de votre serveur, consultez les détails de la section [Aller plus loin](#go-further) de ce guide. +> + + + +#### Recréation de la partition EFI System + +Pour recréer la partition EFI System, nous devons formater **nvme0n1p1** et répliquer le contenu de la partition EFI System saine (dans notre exemple : nvme1n1p1) sur celle-ci. + +Ici, nous supposons que les deux partitions ont été synchronisées et contiennent des fichiers à jour ou n'ont tout simplement pas subi de mises à jour système ayant un impact sur le *bootloader*. + +> [!warning] +> Si une mise à jour majeure du système, telle qu'une mise à jour du noyau ou de GRUB, a eu lieu et que les deux partitions n'ont pas été synchronisées, consultez cette [section](#rebuilding-raid-when-efi-partitions-are-not-synchronized-after-major-system-updates-eg-grub) une fois que vous avez terminé la création de la nouvelle partition EFI System. +> + +Tout d'abord, nous formatons la partition : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkfs.vfat /dev/nvme0n1p1 +``` + +Ensuite, nous attribuons l'étiquette `EFI_SYSPART` à la partition. (ce nommage est spécifique à OVHcloud) : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # fatlabel /dev/nvme0n1p1 EFI_SYSPART +``` + +Ensuite, nous dupliquons le contenu de nvme1n1p1 vers nvme0n1p1. Nous commençons par créer deux dossiers, que nous nommons « old » et « new » dans notre exemple : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkdir old new +``` + +Ensuite, nous montons **nvme1n1p1** dans le dossier « old » et **nvme0n1p1** dans le dossier « new » pour faire la distinction : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/nvme1n1p1 old +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/nvme0n1p1 new +``` + +Ensuite, nous copions les fichiers du dossier 'old' vers 'new' : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # rsync -axv old/ new/ +sending incremental file list +EFI/ +EFI/debian/ +EFI/debian/BOOTX64.CSV +EFI/debian/fbx64.efi +EFI/debian/grub.cfg +EFI/debian/grubx64.efi +EFI/debian/mmx64.efi +EFI/debian/shimx64.efi + +sent 6,099,848 bytes received 165 bytes 12,200,026.00 bytes/sec +total size is 6,097,843 speedup is 1.00 +``` + +Une fois cela fait, nous démontons les deux partitions : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount /dev/nvme0n1p1 +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount /dev/nvme1n1p1 +``` + +Ensuite, nous montons la partition contenant la racine de notre système d'exploitation sur `/mnt`. Dans notre exemple, cette partition est **md3**: + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md3 /mnt +``` + +Nous montons les répertoires suivants pour nous assurer que toute manipulation que nous effectuons dans l'environnement `chroot` fonctionne correctement : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # +mount --types proc /proc /mnt/proc +mount --rbind /sys /mnt/sys +mount --make-rslave /mnt/sys +mount --rbind /dev /mnt/dev +mount --make-rslave /mnt/dev +mount --bind /run /mnt/run +mount --make-slave /mnt/run +``` + +Ensuite, nous utilisons la commande `chroot` pour accéder au point de montage et nous assurer que la nouvelle partition système EFI a été correctement créée et que le système reconnaît les deux ESP : + +```sh +root@rescue12-customer-eu:/# chroot /mnt +``` + +Pour afficher les partitions ESP, nous exécutons la commande `blkid -t LABEL=EFI_SYSPART` : + +```sh +root@rescue12-customer-eu:/# blkid -t LABEL=EFI_SYSPART +/dev/nvme1n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="4629-D183" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="889f241b-49c3-4031-b5c9-60df0746f98f" +/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="521F-300B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="02bf2b2d-7ada-4461-ba50-07683519f65d" +``` + +Les résultats ci-dessus montrent que la nouvelle partition EFI a été créée correctement et que le LABEL a été appliqué correctement. + + + +#### Reconstruction du RAID lorsque les partitions EFI ne sont pas synchronisées après des mises à jour majeures du système (GRUB) + +/// details | Développez cette section + +> [!warning] +> Veuillez suivre les étapes de cette section uniquement si cela s'applique à votre cas. +> + +Lorsque les partitions système EFI ne sont pas synchronisées après des mises à jour majeures du système qui modifient/affectent le GRUB, et que le disque principal sur lequel la partition est montée est remplacé, le démarrage à partir d'un disque secondaire contenant une ESP obsolète peut ne pas fonctionner. + +Dans ce cas, en plus de reconstruire le RAID et de recréer la partition système EFI en mode rescue, vous devez également réinstaller le GRUB sur celle-ci. + +Une fois que nous avons recréé la partition EFI et nous sommes assurés que le système reconnaît les deux partitions (étapes précédentes dans `chroot`), nous créons le dossier `/boot/efi` afin de monter la nouvelle partition système EFI **nvme0n1p1** : + +```sh +root@rescue12-customer-eu:/# mount /boot +root@rescue12-customer-eu:/# mount /dev/nvme0n1p1 /boot/efi +``` + +Ensuite, nous réinstallons le chargeur de démarrage GRUB (*bootloader*) : + +```sh +root@rescue12-customer-eu:/# grub-install --efi-directory=/boot/efi /dev/nvme0n1p1 +``` + +Une fois fait, exécutez la commande suivante : + +```sh +root@rescue12-customer-eu:/# update-grub +``` +/// + + + +#### Ajout de l'étiquette à la partition SWAP (si applicable) + +Une fois que nous avons terminé avec la partition EFI, nous passons à la partition SWAP. + +Nous sortons de l'environnement `chroot` avec `exit` afin de recréer notre partition [SWAP] **nvme0n1p4** et ajouter l'étiquette `swap-nvme0n1p4` : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkswap /dev/nvme0n1p4 -L swap-nvme0n1p4 +Setting up swapspace version 1, size = 512 MiB (536866816 bytes) +LABEL=swap-nvme0n1p4, UUID=b3c9e03a-52f5-4683-81b6-cc10091fcd +``` + +Nous vérifions que l'étiquette a été correctement appliquée : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk -f +NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS +nvme1n1 + +├─nvme1n1p1 +│ vfat FAT16 EFI_SYSPART +│ BA77-E844 504.9M 1% /root/old +├─nvme1n1p2 +│ linux_ 1.2 md2 53409058-480a-bc65-4e1d-6acc848fe233 +│ └─md2 +│ ext4 1.0 boot f925a033-0087-40ec-817e-44efab0351ac +├─nvme1n1p3 +│ linux_ 1.2 md3 a3b8816c-a5c3-7f01-ee17-e1aa9685c35c +│ └─md3 +│ ext4 1.0 root 6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 441.2G 0% /mnt +└─nvme1n1p4 + swap 1 swap-nvme1n1p4 + d6af33cf-fc15-4060-a43c-cb3b5537f58a +nvme0n1 + +├─nvme0n1p1 +│ vfat FAT16 EFI_SYSPART +│ 477D-6658 +├─nvme0n1p2 +│ linux_ 1.2 md2 53409058-480a-bc65-4e1d-6acc848fe233 +│ └─md2 +│ ext4 1.0 boot f925a033-0087-40ec-817e-44efab0351ac +├─nvme0n1p3 +│ linux_ 1.2 md3 a3b8816c-a5c3-7f01-ee17-e1aa9685c35c +│ └─md3 +│ ext4 1.0 root 6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 441.2G 0% /mnt +└─nvme0n1p4 + swap 1 swap-nvme0n1p4 + b3c9e03a-52f5-4683-81b6-cc10091fcd15 +``` + +Nous accédons ensuite à nouveau à l'environnement `chroot` : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt +``` + +Nous récupérons l'UUID des deux partitions swap : + +```sh +root@rescue12-customer-eu:/# blkid -s UUID blkid /dev/nvme0n1p4 +/dev/nvme0n1p4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" + +root@rescue12-customer-eu:/# blkid -s UUID blkid /dev/nvme1n1p4 +/dev/nvme1n1p4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +Ensuite, nous remplaçons l'ancien UUID de la partition swap (**nvme0n1p4**) par le nouveau dans le fichier `/etc/fstab` : + +```sh +root@rescue12-customer-eu:/# nano /etc/fstab +``` + +Exemple : + +```sh +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +Sur la base des résultats ci-dessus, l'ancien UUID est `b7b5dd38-9b51-4282-8f2d-26c65e8d58ec` et doit être remplacé par le nouveau `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. Assurez-vous de remplacer le bon UUID. + +Ensuite, nous vérifions que tout est correctement monté avec la commande suivante : + +```sh +root@rescue12-customer-eu:/# mount -av +/ : ignored +/boot : successfully mounted +/boot/efi : successfully mounted +swap : ignored +swap : ignored +``` + +Nous activons la partition swap : + +```sh +root@rescue12-customer-eu:/# swapon -av + +swapon: /dev/nvme0n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme0n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme0n1p4 +swapon: /dev/nvme1n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme1n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme1n1p4 +``` + +Nous sortons de l'environnement chroot avec `exit` et rechargeons le système : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload +``` + +Nous démontons tous les disques : + +```sh +root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -Rl /mnt +``` + +Nous avons maintenant terminé avec succès la reconstruction RAID sur le serveur et nous pouvons désormais le redémarrer en mode normal. + + + +#### Reconstruction du RAID en mode normal + +/// details | Développez cette section + +Si votre serveur est capable de démarrer en mode normal après un remplacement de disque, vous pouvez suivre les étapes ci-dessous pour reconstruire le RAID. + +Une fois le disque remplacé, nous copions la table de partition du disque sain (dans cet exemple, nvme1n1) vers le nouveau (nvme0n1). + +**Pour les partitions GPT** + +```sh +sgdisk -R /dev/nvme0n1 /dev/nvme1n1 +``` + +La commande doit être dans ce format : `sgdisk -R /dev/nouveau disque /dev/disque sain`. + +Une fois cela fait, l'étape suivante consiste à attribuer un GUID aléatoire au nouveau disque pour éviter les conflits de GUID avec d'autres disques : + +```sh +sgdisk -G /dev/nvme0n1 +``` + +Si vous recevez le message suivant : + +```console +Warning: The kernel is still using the old partition table. +The new table will be used at the next reboot or after you +run partprobe(8) or kpartx(8) +The operation has completed successfully. +``` + +Exécutez simplement la commande `partprobe`. Si vous ne voyez toujours pas les nouvelles partitions créées (ex. avec `lsblk`), vous devez redémarrer le serveur avant de continuer. + +Ensuite, nous ajoutons les partitions au RAID : + +```sh +[user@server_ip ~]# sudo mdadm --add /dev/md2 /dev/nvme0n1p2 + +# mdadm: added /dev/nvme0n1p2 + +[user@server_ip ~]# sudo mdadm --add /dev/md3 /dev/nvme0n1p3 + +# mdadm: re-added /dev/nvme0n1p3 +``` + +Utilisez la commande suivante pour suivre la reconstruction du RAID : `cat /proc/mdstat`. + +**Recreation de la partition EFI System sur le disque** + +Tout d'abord, nous installons les outils nécessaires : + +**Debian et Ubuntu** + +```sh +[user@server_ip ~]# sudo apt install dosfstools +``` + +**CentOS** + +```sh +[user@server_ip ~]# sudo yum install dosfstools +``` + +Ensuite, nous formatons la partition. Dans notre exemple `nvme0n1p1` : + +```sh +[user@server_ip ~]# sudo mkfs.vfat /dev/nvme0n1p1 +``` + +Ensuite, nous attribuons l'étiquette `EFI_SYSPART` à la partition. (ce nommage est spécifique à OVHcloud): + +```sh +[user@server_ip ~]# sudo fatlabel /dev/nvme0n1p1 EFI_SYSPART +``` + +Une fois cela fait, vous pouvez synchroniser les deux partitions à l'aide du script que nous avons fourni [ici](#script). + +Nous vérifions que la nouvelle partition EFI System a été correctement créée et que le système la reconnaît : + +```sh +[user@server_ip ~]# sudo blkid -t LABEL=EFI_SYSPART +/dev/nvme1n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="4629-D183" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="889f241b-49c3-4031-b5c9-60df0746f98f" +/dev/nvme0n1p1: SEC_TYPE="msdos" LABEL_FATBOOT="EFI_SYSPART" LABEL="EFI_SYSPART" UUID="521F-300B" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="primary" PARTUUID="02bf2b2d-7ada-4461-ba50-07683519f65d" +``` + +Enfin, nous activons la partition [SWAP] (si applicable) : + +- Nous créons et ajoutons l'étiquette : + +```sh +[user@server_ip ~]# sudo mkswap /dev/nvme0n1p4 -L swap-nvme0n1p4 +``` + +- Nous récupérons les UUID des deux partitions swap : + +```sh +[user@server_ip ~]# sudo blkid -s /dev/nvme0n1p4 +/dev/nvme0n1p4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15" +[user@server_ip ~]# sudo blkid -s /dev/nvme1n1p4 +/dev/nvme1n1p4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a" +``` + +- Nous remplaçons l'ancien UUID de la partition swap (**nvme0n1p4)** par le nouveau dans `/etc/fstab` : + +```sh +[user@server_ip ~]# sudo nano /etc/fstab +``` + +Exemple : + +```sh +[user@server_ip ~]# sudo nano /etc/fstab +UUID=6abfaa3b-e630-457a-bbe0-e00e5b4b59e5 / ext4 defaults 0 1 +UUID=f925a033-0087-40ec-817e-44efab0351ac /boot ext4 defaults 0 0 +LABEL=EFI_SYSPART /boot/efi vfat defaults 0 1 +UUID=b7b5dd38-9b51-4282-8f2d-26c65e8d58ec swap swap defaults 0 0 +UUID=d6af33cf-fc15-4060-a43c-cb3b5537f58a swap swap defaults 0 0 +``` + +D'après les résultats ci-dessus, l'ancien UUID est `b7b5dd38-9b51-4282-8f2d-26c65e8d58ec` et doit être remplacé par le nouveau `b3c9e03a-52f5-4683-81b6-cc10091fcd15`. + +Assurez-vous de remplacer le bon UUID. + +Ensuite, nous exécutons la commande suivante pour activer la partition swap : + +```sh +[user@server_ip ~]# sudo swapon -av +swapon: /dev/nvme0n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme0n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme0n1p4 +swapon: /dev/nvme1n1p4: found signature [pagesize=4096, signature=swap] +swapon: /dev/nvme1n1p4: pagesize=4096, swapsize=536870912, devsize=536870912 +swapon /dev/nvme1n1p4 +``` + +Ensuite, nous rechargeons le système : + +```sh +[user@server_ip ~]# sudo systemctl daemon-reload +``` + +Nous avons maintenant terminé avec succès la reconstruction RAID. + +## Aller plus loin + +[Hot Swap - Software RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_soft) + +[OVHcloud API and Storage](/pages/bare_metal_cloud/dedicated_servers/partitioning_ovh) + +[Managing hardware RAID](/pages/bare_metal_cloud/dedicated_servers/raid_hard) + +[Hot Swap - Hardware RAID](/pages/bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + +Pour les services spécialisés (SEO, développement, etc.), contactez [les partenaires OVHcloud](/links/partner). + +Si vous avez besoin d'une assistance pour utiliser et configurer vos solutions OVHcloud, veuillez consulter nos [offres de support](/links/support). + +Si vous avez besoin de formation ou d'une assistance technique pour mettre en place nos solutions, contactez votre représentant commercial ou cliquez sur [ce lien](/links/professional-services) pour obtenir un devis et demander à nos experts de l'équipe Professional Services d'intervenir sur votre cas d'utilisation spécifique. + +Rejoignez notre [communauté d'utilisateurs](/links/community). \ No newline at end of file diff --git a/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/meta.yaml b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/meta.yaml new file mode 100644 index 00000000000..5a256dae3a2 --- /dev/null +++ b/pages/bare_metal_cloud/dedicated_servers/raid_soft_uefi/meta.yaml @@ -0,0 +1,3 @@ +id: 026d2da0-e852-4c24-b78c-39660ef19c06 +full_slug: dedicated-servers-raid-soft-uefi +translation_banner: true \ No newline at end of file diff --git a/pages/index.md b/pages/index.md index 94e8de20140..d7fbb892efe 100644 --- a/pages/index.md +++ b/pages/index.md @@ -164,7 +164,8 @@ + [How to assign a tag to a Bare Metal server](bare_metal_cloud/dedicated_servers/resource-tag-assign) + [How to install VMware ESXi 8 on a dedicated server](bare_metal_cloud/dedicated_servers/esxi-partitioning) + [Storage](bare-metal-cloud-dedicated-servers-configuration-storage) - + [How to configure and rebuild software RAID](bare_metal_cloud/dedicated_servers/raid_soft) + + [Managing and rebuilding software RAID on servers using legacy boot (BIOS) mode](bare_metal_cloud/dedicated_servers/raid_soft) + + [Managing and rebuilding software RAID on servers using UEFI boot mode](bare_metal_cloud/dedicated_servers/raid_soft_uefi) + [Managing hardware RAID](bare_metal_cloud/dedicated_servers/raid_hard) + [Hot swap - Hardware RAID](bare_metal_cloud/dedicated_servers/hotswap_raid_hard) + [Hot swap - Software RAID](bare_metal_cloud/dedicated_servers/hotswap_raid_soft)