Zarządzanie i odbudowa oprogramowania RAID na serwerach w trybie UEFI

Wprowadzenie

Redundant Array of Independent Disks (RAID) to technologia, która zmniejsza utratę danych na serwerze, replikując dane na dwóch lub więcej dyskach.

Domyślny poziom RAID dla instalacji serwerów OVHcloud to RAID 1, który podwaja zajęte przez dane miejsce, skutecznie zmniejszając dostępne miejsce na dysku o połowę.

Ten przewodnik wyjaśnia, jak zarządzać i odbudować oprogramowanie RAID po wymianie dysku na serwerze w trybie uruchamiania UEFI.

Zanim zaczniemy, zwróć uwagę, że ten przewodnik skupia się na Serwerach dedykowanych, które używają UEFI jako trybu uruchamiania. Jest to typowe dla nowoczesnych płyt głównych. Jeśli Twój serwer używa trybu uruchamiania zgodnego (BIOS), odwiedź ten przewodnik: Zarządzanie i odbudowa oprogramowania RAID na serwerach w trybie uruchamiania zgodnym (BIOS).

Aby sprawdzić, czy serwer działa w trybie zgodnym BIOS czy trybie uruchamiania UEFI, uruchom następującą komendę:

[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

Aby uzyskać więcej informacji na temat UEFI, zapoznaj się z poniższym artykułem.

Wymagania początkowe

Serwer dedykowany z konfiguracją oprogramowania RAID
Dostęp administracyjny (sudo) do serwera przez SSH
Zrozumienie RAID, partycji i GRUB

W całym przewodniku używamy pojęć główny dysk i dysk pomocniczy. W tym kontekście:

Główny dysk to dysk, którego ESP (EFI System Partition) jest zamontowany przez system Linux.
Dyski pomocnicze to wszystkie inne dyski w RAID.

W praktyce

Kiedy zakupisz nowy serwer, możesz poczuć potrzebę wykonania szeregu testów i działań. Jednym z takich testów może być symulacja awarii dysku, aby zrozumieć proces odbudowy RAID.

Omówienie treści

Podstawowe informacje
Zrozumienie partycji systemu EFI (ESP)
Symulowanie awarii dysku
- Usuwanie uszkodzonego dysku
Odbudowa macierzy RAID (z ESP bez dublowania)
Odbudowa macierzy RAID (z dublowaniem ESP)
Dodanie etykiety do partycji SWAP (jeśli dotyczy)

Podstawowe informacje

W sesji linii poleceń wpisz następujące polecenie, aby określić bieżący stan RAID:

[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: <none>

Z wyników wynika, że obecnie skonfigurowano dwa urządzenia RAID oprogramieniowe, md2 i md3, z md3 będącym większym z nich. md3 składa się z dwóch partycji, nazywanych nvme0n1p3 i nvme1n1p3.

[UU] oznacza, że wszystkie dyski działają normalnie. _ wskazywałby na awaryjny dysk.

W innych przypadkach otrzymasz następujące wyniki:

Personalities : [raid1]
md3 : active raid1 nvme0n1p3[1] nvme1n1p3[0]
      497875968 blocks super 1.2 [2/2] [UU]
      bitmap: 2/4 pages [8KB], 65536KB chunk

md1 : active raid1 nvme0n1p1[1] nvme1n1p1[0]
      523200 blocks [2/2] [UU]

md2 : active raid1 nvme1n1p2[0] nvme0n1p2[1]
      1046528 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Wyniki pokazują trzy skonfigurowane urządzenia RAID oprogramieniowe, md1, md2 i md3, z md3 będącym największym z nich. md3 składa się z dwóch partycji, nazywanych nvme0n1p3 i nvme1n1p3.

Jeśli masz serwer z dyskami SATA, otrzymasz następujące wyniki:

[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: <none>

Ta komenda pokazuje nasze volume RAID, ale nie pokazuje rozmiarów partycji. Możemy znaleźć tę informację używając fdisk -l:

fdisk -l

[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

Ta komenda może również być używana do zidentyfikowania typu partycji.

Dla partycji GPT, linia 6 pokazuje: Disklabel type: gpt. Tę informację można zobaczyć tylko wtedy, gdy serwer działa w normalnym trybie.

Kontynuując wyniki, widzimy, że /dev/md2 składa się z 1022 MiB, a /dev/md3 zawiera 474,81 GiB. Jeśli uruchomimy komendę mount, możemy również zrozumieć układ dysk.

Alternatywnie, polecenie lsblk oferuje inny widok partycji:

[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

Ponadto, jeśli uruchomimy lsblk -f, otrzymamy więcej informacji o tych partycjach, takich jak Etykieta i UUID:

[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

Zwróć uwagę na urządzenia, partycje i punkty montażu, ponieważ jest to ważne, zwłaszcza po wymianie dysku. Pozwoli to sprawdzić, czy partycje są poprawnie zamontowane w odpowiednich punktach montażu na nowym dysk.

W naszym przykładzie mamy:

Dwie tablice RAID: /dev/md2 i /dev/md3.
Partycje należące do RAID: nvme0n1p2, nvme0n1p3, nvme1n1p2 i nvme0n1p3 z punktami montażu /boot i /.
Partycje nie należące do RAID: nvme0n1p1, nvme0n1p4 i nvme1n1p4 z punktami montażu /boot/efi i [SWAP].
Jedna partycja nie ma punktu montażu: nvme1n1p1.

Partycja nvme0n1p5 jest partycją konfiguracyjną, czyli tylko do odczytu, połączoną z serwerem, która dostarcza mu początkowe dane konfiguracyjne.

Zrozumienie partycji systemu EFI (ESP)

Rozwiń tę sekcję

Co to jest partycja systemu EFI?

Partycja systemu EFI to partycja, która może zawierać programy uruchamiające system operacyjny, menedżery uruchamiające, lub obrazy jądra. Może również zawierać programy narzędziowe systemowe zaprojektowane do uruchamiania przed uruchomieniem systemu operacyjnego, a także pliki danych, takie jak dzienniki błędów.

Czy partycja systemu EFI jest zwierciadlona w RAID?

Od grudnia 2025 tylko następujące wersje systemów operacyjnych zwierciadlują partycję systemu EFI w RAID dla nowych instalacji lub reinstalacji:

Debian 13
Proxmox 9
Ubuntu 25.10
AlmaLinux i Rocky Linux 10
Fedora 43

Dla wcześniejszych wersji partycja systemu EFI nie jest zwierciadlona w RAID; tworzone są wiele ESP, po jednym na dysk. Jednak tylko jedno ESP jest zamontowane w danym momencie. ESP jest zamontowane w /boot/efi, a dysk, na którym znajduje się, jest wybierany przez system Linux przy uruchamianiu.

Możesz użyć komendy lsblk, aby potwierdzić, czy Twoja partycja jest częścią konfiguracji RAID.

ESP nie jest dublowane

ESP dublowanie

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:6    0   511M  0 part
├─nvme0n1p2 259:7    0     1G  0 part
│ └─md2       9:2    0  1022M  0 raid1 /boot
├─nvme0n1p3 259:8    0 474.9G  0 part
│ └─md3       9:3    0 474.8G  0 raid1 /
├─nvme0n1p4 259:9    0   512M  0 part  [SWAP]
└─nvme0n1p5 259:10   0     2M  0 part
nvme1n1     259:1    0 476.9G  0 disk
├─nvme1n1p1 259:2    0   511M  0 part  /boot/efi
├─nvme1n1p2 259:3    0     1G  0 part
│ └─md2       9:2    0  1022M  0 raid1 /boot
├─nvme1n1p3 259:4    0 474.9G  0 part
│ └─md3       9:3    0 474.8G  0 raid1 /
└─nvme1n1p4 259:5    0   512M  0 part  [SWAP]

Z powyższych wyników wynika, że tylko jedna partycja systemowa EFI jest zamontowana w /boot/efi. Dlatego też partycje ESP nie jest dublowane.

lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1     259:0    0 476.9G  0 disk
├─nvme0n1p1 259:1    0   511M  0 part
│ └─md1       9:1    0 510.9M  0 raid1 /boot/efi
├─nvme0n1p2 259:2    0     1G  0 part
│ └─md2       9:2    0  1022M  0 raid1 /boot
├─nvme0n1p3 259:3    0 474.9G  0 part
│ └─md3       9:3    0 474.8G  0 raid1 /
└─nvme0n1p4 259:4    0   512M  0 part  [SWAP]
nvme1n1     259:5    0 476.9G  0 disk
├─nvme1n1p1 259:6    0   511M  0 part
│ └─md1       9:1    0 510.9M  0 raid1 /boot/efi
├─nvme1n1p2 259:7    0     1G  0 part
│ └─md2       9:2    0  1022M  0 raid1 /boot
├─nvme1n1p3 259:8    0 474.9G  0 part
│ └─md3       9:3    0 474.8G  0 raid1 /
├─nvme1n1p4 259:9    0   512M  0 part  [SWAP]
└─nvme1n1p5 259:10   0     2M  0 part

Z powyższych wyników wynika, że obie partycje systemu EFI są zamontowane w katalogu /boot/efi. Są one zatem dublowane w macierzy RAID.

Czy zawartość partycji systemu EFI zmienia się regularnie?

Zazwyczaj zawartość tej partycji nie zmienia się znacząco, jej zawartość powinna zmieniać się tylko przy aktualizacjach programu uruchamiającego (np. GRUB).

Jednak jeśli Twoja partycja systemu EFI nie jest zwierciadlona, zalecamy uruchamianie skryptu automatycznego lub ręcznego, aby zsynchronizować wszystkie ESP, tak aby zawierały te same aktualne pliki. Dzięki temu, jeśli dysk, na którym znajduje się ta partycja, ulegnie awarii, serwer będzie mógł uruchomić się z ESP jednego z innych dysków.

Co się stanie, jeśli główny dysk (z zamontowaną partycją systemu EFI) ulegnie awarii?

Jeśli twój ESP nie jest dublowany, mogą wystąpić następujące problemy:

Info

Proszę zauważyć, że choć poniżej omawiamy najczęściej spotykane przypadki, istnieje wiele innych powodów, dla których serwer może nie uruchomić się w normalnym trybie po wymianie dysku.

Przypadek 1 – Nie było żadnych zmian ani dużych aktualizacji (np. GRUB) w systemie operacyjnym.

Serwer może uruchomić się w normalnym trybie i można kontynuować odbudowę RAID.
Serwer nie może uruchomić się w normalnym trybie, użyj środowiska trybu rescue, aby odbudować RAID i zrekonfigurować partycję systemu EFI na nowym dysku.

Przypadek 2 – Były duże aktualizacje systemu (np. GRUB), a partycje ESP są zsynchronizowane.

Serwer może uruchomić się w normalnym trybie, ponieważ wszystkie ESP są aktualne, a odbudowa RAID może zostać wykonana w normalnym trybie.
Serwer nie może uruchomić się w normalnym trybie, użyj środowiska trybu rescue, aby odbudować RAID i zrekonfigurować partycję systemu EFI na nowym dysku.

Przypadek 3 – Były duże aktualizacje systemu (np. GRUB) i partycje ESP nie zostały zsynchronizowane.

Serwer nie może uruchomić się w normalnym trybie, użyj środowiska trybu rescue, aby odbudować RAID, zrekonfigurować partycję systemu EFI na nowym dysku i zainstalować ponownie program uruchamiający (np. GRUB).
Serwer może uruchomić się w normalnym trybie (np. gdy system operacyjny został uaktualniony, ale wersja GRUB nie zmieniła się), pozwalając kontynuować odbudowę RAID.

W niektórych przypadkach uruchomienie z nieaktualnego ESP może się nie powieść; np. duża aktualizacja GRUB może sprawić, że binarna wersja GRUB w ESP będzie niekompatybilna z nowszymi modułami GRUB w partycji /boot.

Jak mogę zsynchronizować moje partycje systemu EFI i jak często je synchronizować?

Jeśli obszar ESP nie jest dublowany, należy rozważyć następujące kwestie:

Info

Proszę zauważyć, że w zależności od systemu operacyjnego proces może się różnić. Na przykład Ubuntu może utrzymywać wiele partycji systemu EFI zsynchronizowanych przy każdej aktualizacji GRUB, ale jest to jedyny system operacyjny, który to robi. Zalecamy zapoznanie się z oficjalną dokumentacją swojego systemu operacyjnego, aby zrozumieć, jak zarządzać ESP.

W tym przewodniku używany jest system operacyjny Debian.

Zalecamy regularne synchronizowanie swoich partycji ESP lub po każdej dużej aktualizacji systemu. Domyślnie wszystkie partycje systemu EFI zawierają te same pliki po instalacji. Jednak po dużej aktualizacji systemu synchronizacja partycji ESP jest konieczna, aby zapewnić, że zawartość pozostaje aktualna.

Uruchamianie skryptu to skuteczny sposób na regularne synchronizowanie partycji. Poniżej znajduje się skrypt, który możesz użyć do ręcznego zsynchronizowania swoich partycji ESP. Alternatywnie możesz skonfigurować automatyczny skrypt, który będzie je synchronizować codziennie lub za każdym razem, gdy system się uruchomi.

Przed wykonaniem skryptu upewnij się, że rsync jest zainstalowany na Twoim systemie:

Debian/Ubuntu

sudo apt install rsync

CentOS, Red Hat i Fedora

sudo yum install rsync

Aby uruchomić skrypt w systemie Linux, potrzebujesz pliku wykonywalnego:

Zacznij od utworzenia pliku .sh w wybranym katalogu, zastępując script-name wybraną przez Ciebie nazwą:

sudo touch script-name.sh

Otwórz plik za pomocą edytora tekstu i dodaj poniższe linie:

sudo nano script-name.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)

Zapisz i zamknij plik.

Ustaw skrypt jako wykonywalny:

sudo chmod +x script-name.sh

Uruchom skrypt:

sudo ./script-name.sh

Jeśli nie jesteś w katalogu:

./path/to/folder/script-name.sh

Po wykonaniu skryptu zawartość zamontowanej partycji ESP zostanie zsynchronizowana z innymi. Następnie możesz zamontować każdą niezamontowaną partycję EFI w punkcie montażu: /var/lib/grub/esp, aby uzyskać dostęp do jej zawartości.

Symulowanie awarii dysku

Teraz, gdy mamy niezbędne informacje, możemy zasymulować awarię dysku. W tym przykładzie zasymulujemy awarię głównego dysku nvme0n1 (zwróć uwagę, że to dysk z zamontowanym ESP).

Preferowany sposób to wykonanie tej czynności za pomocą środowiska trybu rescue OVHcloud.

Uruchom serwer w trybie ratunkowym i zaloguj się przy użyciu dostarczonych poświadczeń.

Aby usunąć dysk z RAID, najpierw oznacz go jako Failed (uszkodzony), a następnie usuń jego partycje z tablic RAID.

Uwaga: To tylko ilustracja; dostosuj komendy do swojej konfiguracji.

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: <none>

Z powyższego wyniku wynika, że nvme0n1 składa się z dwóch partycji w RAID, które to nvme0n1p2 i nvme0n1p3.

Usuwanie uszkodzonego dysku

Najpierw oznacz partycje nvme0n1p2 i nvme0n1p3 jako zepsute (Failed).

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

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

Następnie uruchom komendę cat /proc/mdstat:

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](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: <none>

Jak widać powyżej, [F] obok partycji wskazuje, że dysk uległ awarii lub jest uszkodzony.

Następnie usuń te partycje z tablic RAID, aby całkowicie usunąć dysk z RAID.

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

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

Stan RAID powinien teraz wyglądać następująco:

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: <none>

Teraz w tablicach RAID widoczne są tylko dwie partycje. Pomyślnie zakończyliśmy awarię dysku nvme0n1.

Aby uzyskać dysk podobny do pustego, uruchamiamy następujące polecenie na każdej partycji, a następnie na samym dysku:

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/nvme0n1

Dysk teraz wygląda jak nowy, pusty dysk:

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

Aby upewnić się, że dysk został pomyślnie "wyczyszczony":

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:

Aby uzyskać więcej informacji na temat przygotowania i złożenia wniosku o wymianę dysku, zapoznaj się z tym przewodnikiem.

Dodatkowo, jeśli uruchomisz poniższe polecenie, otrzymasz więcej szczegółów dotyczących tablic RAID:

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

Możemy teraz przystąpić do wymiany dysku i odbudowy macierzy RAID.

Odbudowa macierzy RAID (z ESP bez dublowania)

Info

Ten proces może się różnić w zależności od systemu operacyjnego zainstalowanego na Twoim serwerze. Zalecamy, abyś zapoznał się z oficjalną dokumentacją swojego systemu operacyjnego, aby uzyskać dostęp do odpowiednich poleceń.

Jeśli Twój serwer potrafi uruchomić się w trybie normalnym po wymianie dysku, po prostu wykonaj kroki z tej sekcji, jeśli Twoja partycja systemu EFI nie jest zwierciadlona lub tej sekcji, jeśli Twoja partycja systemu EFI jest zwierciadlona.

Odbudowanie tablicy RAID po wymianie głównego dysku (trybu Rescue)

Po wymianie dysku skopiuj tablicę partycji z dysku sprawnego (w tym przykładzie, nvme1n1) na nowy (nvme0n1).

Dla partycji GPT

Polecenie powinno mieć następującą postać: sgdisk -R /dev/nowy dysk /dev/prawidłowy dysk

Przykład:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/nvme0n1 /dev/nvme1n1

Uruchom lsblk, aby upewnić się, że tablice partycji zostały poprawnie skopiowane:

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

Następnie wygeneruj GUID nowego dysku, aby uniknąć konfliktów GUID z innymi dyskami:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -G /dev/nvme0n1

Jeśli otrzymasz poniższy komunikat:

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.

Po prostu uruchom polecenie partprobe.

Następnie odbudowujemy tablicę RAID. Poniższy fragment kodu pokazuje, jak dodać nowe partycje (nvme0n1p2 i nvme0n1p3) z powrotem do tablicy RAID.

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

Aby sprawdzić postęp odbudowy:

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]

Po zakończeniu odbudowy tablicy RAID uruchom poniższe polecenie, aby upewnić się, że partycje zostały poprawnie dodane do tablicy RAID:

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

Na podstawie powyższych wyników, partycje na nowym dysku zostały poprawnie dodane do tablicy RAID. Jednak partycja systemu EFI i partycja SWAP (w niektórych przypadkach) nie zostały zduplikowane, co jest normalne, ponieważ nie są one uwzględniane w tablicy RAID.

Warning

Powyższe przykłady ilustrują tylko niezbędne kroki na podstawie domyślnej konfiguracji serwera. Informacje w tabeli wyników zależą od sprzętu Twojego serwera i jego schematu partycji. W przypadku wątpliwości skonsultuj dokumentację swojego systemu operacyjnego.

Jeśli potrzebujesz profesjonalnej pomocy w administracji serwerem, zapoznaj się z sekcją Sprawdź również tego przewodnika.

Odbudowanie partycji systemu EFI

Aby odbudować partycję systemu EFI na nowym dysku, musimy sformatować nvme0n1p1 i następnie zrekompilować zawartość sprawnej partycji (w naszym przykładzie: nvme1n1p1) na nią.

Zakładamy, że obie partycje zostały zsynchronizowane i zawierają aktualne pliki.

Warning

Jeśli miało miejsce znaczące uaktualnienie systemu, takie jak jądro lub GRUB, i obie partycje nie zostały zsynchronizowane, skonsultuj tą sekcję po zakończeniu tworzenia nowej partycji systemu EFI.

Najpierw sformatuj partycję:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkfs.vfat /dev/nvme0n1p1

Następnie nadaj partycji etykietę EFI_SYSPART (ta nazwa jest specyficzna dla OVHcloud):

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # fatlabel /dev/nvme0n1p1 EFI_SYSPART

Następnie skopiuj zawartość nvme1n1p1 do nvme0n1p1.

Zacznij od utworzenia dwóch folderów, nazwanych "old" i "new" w tym przykładzie:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mkdir old new

Zamontuj nvme1n1p1 w folderze "old" i nvme0n1p1 w folderze "new", aby rozróżnić je:

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

Następnie kopiujemy pliki z katalogu "old" do "new":

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

Po wykonaniu tej czynności odinstaluj obie partycje:

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

Następnie zamontuj partycję zawierającą korzeń systemu operacyjnego na /mnt. W tym przykładzie jest to partycja md3.

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md3 /mnt

Zamontuj poniższe katalogi, aby upewnić się, że wszystkie zmiany wprowadzone w środowisku chroot będą działać poprawnie:

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

Następnie użyj polecenia chroot, aby uzyskać dostęp do punktu montażowego i sprawdzić, czy nowa partycja ESP została poprawnie utworzona i czy system rozpoznaje obie partycje ESP:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt

Aby wyświetlić partycje ESP, uruchom polecenie blkid -t LABEL=EFI_SYSPART:

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"

Wyniki pokazują, że nowa partycja ESP została poprawnie utworzona i etykieta została prawidłowo zastosowana.

Po wykonaniu tej czynności wyjdź z środowiska chroot:

root@rescue12-customer-eu:/# exit

Następnie skorzystaj z tej sekcji, aby odbudować partycję SWAP (jeśli dotyczy).

Odbudowanie tablicy RAID z niezsynchronizowanymi partycjami ESP po znaczących uaktualnieniach systemu (GRUB)

Rozwiń tę sekcję

Warning

Wykonuj kroki z tej sekcji tylko wtedy, gdy dotyczą one Twojego przypadku.

Jeśli główny dysk zostanie wymieniony, gdy zawiera partycje systemu EFI, które nie zostały zsynchronizowane po znaczących uaktualnieniach systemu, które zmodyfikowały GRUB, uruchomienie systemu z jednego z dysków pomocniczych z przestarzałą partycją ESP może się nie powieść.

W takim przypadku, oprócz odbudowania tablicy RAID i odbudowania partycji systemu EFI w trybie ratunkowym, musisz również ponownie zainstalować GRUB na niej.

Po utworzeniu partycji ESP (jak wyjaśniono powyżej) i gdy system rozpoznaje obie partycje, wciąż w środowisku chroot, utwórz katalog /boot/efi, aby zamontować nową partycję systemu EFI nvme0n1p1:

root@rescue12-customer-eu:/# mount /boot
root@rescue12-customer-eu:/# mount /dev/nvme0n1p1 /boot/efi

Następnie ponownie zainstaluj bootloader GRUB:

root@rescue12-customer-eu:/# grub-install --efi-directory=/boot/efi /dev/nvme0n1p1

Następnie uruchom poniższe polecenie:

root@rescue12-customer-eu:/# update-grub

Po wykonaniu tej czynności wyjdź z środowiska chroot:

root@rescue12-customer-eu:/# exit

Następnie skorzystaj z tej sekcji, aby odbudować partycję SWAP (jeśli dotyczy).

Odbudowanie tablicy RAID po wymianie głównego dysku (trybu normalny)

Rozwiń tę sekcję

Jeśli Twój serwer potrafi uruchomić się w trybie normalnym po wymianie głównego dysku, wykonaj poniższe kroki, aby odbudować tablicę RAID.

Po wymianie dysku skopiuj tablicę partycji z dysku sprawnego (w tym przykładzie, nvme1n1) na nowy dysk (nvme0n1).

Dla partycji GPT

sudo sgdisk -R /dev/nvme0n1 /dev/nvme1n1

Polecenie powinno mieć następującą postać: sgdisk -R /dev/nowy dysk /dev/prawidłowy dysk

Następnie wygeneruj GUID nowego dysku, aby uniknąć konfliktów GUID z innymi dyskami:

sudo sgdisk -G /dev/nvme0n1

Jeśli otrzymasz poniższy komunikat:

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.

Po prostu uruchom polecenie partprobe. Jeśli nadal nie widzisz nowo utworzonych partycji (przez uruchomienie lsblk), musisz ponownie uruchomić serwer, zanim przejdziesz dalej.

Następnie dodaj partycje do tablicy RAID:

[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

Użyj poniższego polecenia, aby monitorować odbudowę tablicy RAID:

[user@server_ip ~]# cat /proc/mdstat

Po zakończeniu odbudowy odbuduj partycję systemu EFI na nowym dysku.

Najpierw upewnij się, że zainstalowane są odpowiednie narzędzia:

Debian i Ubuntu

[user@server_ip ~]# sudo apt install dosfstools

CentOS

[user@server_ip ~]# sudo yum install dosfstools

Sformatuj partycję. W naszym przykładzie nvme0n1p1:

[user@server_ip ~]# sudo mkfs.vfat /dev/nvme0n1p1

Nadaj partycji etykietę EFI_SYSPART (ta nazwa jest specyficzna dla OVHcloud):

[user@server_ip ~]# sudo fatlabel /dev/nvme0n1p1 EFI_SYSPART

Po wykonaniu tej czynności zsynchronizuj obie partycje za pomocą skryptu dostarczonego w tym przewodniku.

Sprawdź, czy nowa partycja systemu EFI została poprawnie utworzona i system ją rozpoznaje:

[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"

Następnie skorzystaj z tej sekcji, aby odbudować partycję SWAP (jeśli dotyczy).

Odbudowa macierzy RAID (z dublowaniem ESP)

Rozwiń tę sekcję

W trybu Rescue

W trybu normalnym

Odbudowanie RAID z lustrowanymi wszystkimi partycjami jest łatwiejsze; po prostu skopiuj dane z dysku sprawnego na nowy dysk i odbuduj partycję [SWAP] (jeśli dotyczy).

Na podstawie powyższych ilustracji, status RAID powinien wyglądać tak po awarii dysku:

Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]
md3 : active raid1 nvme1n1p3[2] nvme0n1p3[0](F)
     497875968 blocks super 1.2 [2/1] [_U]
     bitmap: 0/4 pages [0KB], 65536KB chunk

md1 : active raid1 nvme0n1p1[2](F) nvme1n1p1[1]
     523200 blocks [2/1] [_U]

md2 : active raid1 nvme1n1p2[2] nvme0n1p2[0](F)
     1046528 blocks super 1.2 [2/1] [_U]

unused devices: <none>

Po wymianie dysku pierwszym krokiem jest skopiowanie tabeli partycji ze sprawnego dysku (w tym przykładzie, nvme1n1) na nowy (nvme0n1).

Dla partycji GPT

Komenda powinna mieć następującą postać: sgdisk -R /dev/nowy dysk /dev/prawidłowy dysk.

W naszym przykładzie:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/nvme0n1 /dev/nvme1n1

Uruchom lsblk, aby upewnić się, że tabele partycji zostały poprawnie skopiowane:

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
│ └─md1       9:1    0  510.9M 0 raid1
├─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

Następnie zasymuluj GUID nowego dysku, aby uniknąć konfliktów GUID z innymi dyskami:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -G /dev/nvme0n1

Jeśli otrzymasz poniższy komunikat:

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.

Po prostu uruchom komendę partprobe.

Możemy teraz odbudować tablicę RAID. Poniższy fragment kodu pokazuje, jak dodać nowe partycje (nvme0n1p1, nvme0n1p2 i nvme0n1p3) z powrotem do tablicy RAID.

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --add /dev/md1 /dev/nvme0n1p1
# mdadm: added /dev/nvme0n1p1

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: added /dev/nvme0n1p3

Aby sprawdzić proces odbudowy:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 nvme0n1p3[2] nvme1n1p3[0]
      497875968 blocks super 1.2 [2/1] [U_]
      [=========>...........]  recovery = 47.0% (234461184/497875968) finish=21.
      bitmap: 4/4 pages [16KB], 65536KB chunk

md1 : active raid1 nvme0n1p1[1] nvme1n1p1[0]
     523200 blocks [2/2] [UU]

md2 : active raid1 nvme0n1p2[2] nvme1n1p2[0]
     1046528 blocks super 1.2 [2/2] [UU]

Po zakończeniu odbudowy uruchom poniższą komendę, aby upewnić się, że partycje zostały poprawnie dodane do RAID:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # lsblk -f
NAME        FSTYPE            FSVER LABEL          UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
nvme1n1
├─nvme1n1p1 linux_raid_member 0.90.0                          2043a004-0743-7bc6-37f2-12c43604630c
│ └─md1     vfat              FAT16            EFI_SYSPART    D28D-6A4F
├─nvme1n1p2 linux_raid_member 1.2              md2            0772556e-3f45-a551-ab32-c96e502dab22
│ └─md2     xfs                                boot           0b22431a-7020-427c-aa31-324feec6ea84
├─nvme1n1p3 linux_raid_member 1.2              md3            071571aa-1b36-9ef7-15b3-190ffdcf3a8b
│ └─md3     xfs                                root           3a2cb95b-c142-4d72-835b-52fcce99a0c5
├─nvme1n1p4 swap              1                swap-nvme1n1p4 0d502997-853d-4986-b40a-407d5f187e82
└─nvme1n1p5
nvme0n1
├─nvme0n1p1 linux_raid_member 0.90.0                          2043a004-0743-7bc6-37f2-12c43604630c
│ └─md1     vfat              FAT16            EFI_SYSPART    D28D-6A4F
├─nvme0n1p2 linux_raid_member 1.2              md2            0772556e-3f45-a551-ab32-c96e502dab22
│ └─md2     xfs                                boot           0b22431a-7020-427c-aa31-324feec6ea84
├─nvme0n1p3 linux_raid_member 1.2              md3            071571aa-1b36-9ef7-15b3-190ffdcf3a8b
│ └─md3     xfs                                root           3a2cb95b-c142-4d72-835b-52fcce99a0c5
├─nvme0n1p4
└─nvme0n1p5 iso9660           Joliet Extension config-2       2025-12-16-15-40-00-00

Po zakończeniu, zapoznaj się z tą sekcją, aby odbudować partycję SWAP (jeśli dotyczy).

Na podstawie powyższych ilustracji, status RAID powinien wyglądać tak po awarii dysku:

Personalities : [raid1]
md3 : active raid1 nvme0n1p3[1](F) nvme1n1p3[0]
      497875968 blocks super 1.2 [2/1] [U_]
      bitmap: 4/4 pages [16KB], 65536KB chunk

md1 : active raid1 nvme0n1p1[2](F) nvme1n1p1[0]
      523200 blocks [2/1] [U_]

md2 : active raid1 nvme1n1p2[0] nvme0n1p2[1](F)
      1046528 blocks super 1.2 [2/1] [U_]

Po wymianie dysku skopiuj tabelę partycji z dysku prawidłowy (w tym przykładzie nvme1n1) na nowy dysk (nvme0n1).

Dla partycji GPT

sudo sgdisk -R /dev/nvme0n1 /dev/nvme1n1

Polecenie powinno mieć następujący format: sgdisk -R /dev/nowy dysk /dev/prawidłowy dysk.

Następnie zasymuluj GUID nowego dysku, aby uniknąć konfliktów GUID z innymi dyskami:

sudo sgdisk -G /dev/nvme0n1

Jeśli otrzymasz poniższy komunikat:

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.

Po prostu uruchom komendę partprobe. Jeśli nadal nie widzisz nowo utworzonych partycji (np. za pomocą lsblk), musisz ponownie uruchomić serwer, zanim przejdziesz dalej.

Następnie dodaj partycje do RAID:

[user@server_ip ~]# sudo mdadm --add /dev/md1 /dev/nvme0n1p1
# mdadm: added /dev/nvme0n1p1

[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: added /dev/nvme0n1p3

Użyj poniższej komendy, aby monitorować odbudowę RAID:

[user@server_ip ~]# cat /proc/mdstat

Po zakończeniu odbudowy RAID, zapoznaj się z tą sekcją, aby odbudować partycję SWAP (jeśli dotyczy).

Dodanie etykiety do partycji SWAP (jeśli dotyczy)

Rozwiń tę sekcję

Użycie trybu Rescue

Użycie trybu normalnym

Poza środowiskiem chroot, odbuduj partycję [SWAP] nvme0n1p4 i dodaj etykietę swap-nvmenxxx:

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

Sprawdź, czy etykieta została poprawnie zastosowana:

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    B27E-16D2
├─nvme1n1p2 linux_raid_member 1.2   md2            fb3c5180-526f-56ad-3a0a-3f7961f57684
│ └─md2     xfs                     boot           ed3a4730-b3eb-4aa5-a550-dd6cd188c3a4
├─nvme1n1p3 linux_raid_member 1.2   md3            a14af9ed-f791-46e5-4381-224e6d79088c
│ └─md3     xfs                     root           5041d916-abb3-4dc8-acdc-baeb3977ce6d  469.6G     1% /mnt
└─nvme1n1p4 swap              1     swap-nvme1n1p4 133ca9a3-1bd6-4519-9b5a-01b8ffa55ca4
nvme0n1
├─nvme0n1p1 vfat              FAT16 EFI_SYSPART    3557-B372
├─nvme0n1p2 linux_raid_member 1.2   md2            fb3c5180-526f-56ad-3a0a-3f7961f57684
│ └─md2     xfs                     boot           ed3a4730-b3eb-4aa5-a550-dd6cd188c3a4
├─nvme0n1p3 linux_raid_member 1.2   md3            a14af9ed-f791-46e5-4381-224e6d79088c
│ └─md3     xfs                     root           5041d916-abb3-4dc8-acdc-baeb3977ce6d  469.6G     1% /mnt
└─nvme0n1p4 swap              1     swap-nvme0n1p4 dedd4d49-7d40-40c8-b529-41f251a7ff81

Znów wejdź do środowiska chroot:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt

Pobierz UUID obu partycji SWAP:

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"

Następnie zastąp stary UUID partycji SWAP (nvme0n1p4) nowym w pliku /etc/fstab:

root@rescue12-customer-eu:/# nano /etc/fstab

Przykład:

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

Na podstawie powyższych wyników, stary UUID to b7b5dd38-9b51-4282-8f2d-26c65e8d58ec i powinien zostać zastąpiony nowym b3c9e03a-52f5-4683-81b6-cc10091fcd15. Upewnij się, że zastępujesz poprawny UUID.

Następnie sprawdź, czy wszystko zostało poprawnie zamontowane za pomocą poniższej komendy:

root@rescue12-customer-eu:/# mount -av
/                        : ignored
/boot                    : successfully mounted
/boot/efi                : successfully mounted
swap                     : ignored
swap                     : ignored

Aktywuj partycję SWAP:

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

Wyjdź z środowiska chroot za pomocą exit i przeładuj system:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload

Odinstaluj wszystkie dyski:

root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -Rl /mnt

Aby odbudować partycję SWAP, wykonaj poniższe kroki:

Najpierw odbuduj partycję na nvme0n1p4 i dodaj etykietę swap-nvme0n1p4:

[user@server_ip ~]# sudo mkswap /dev/nvme0n1p4 -L swap-nvme0n1p4

Pobierz UUID obu partycji SWAP:

[user@server_ip ~]# sudo blkid -s UUID blkid /dev/nvme0n1p4
/dev/nvme0n1p4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15"
[user@server_ip ~]# sudo blkid -s UUID blkid /dev/nvme1n1p4
/dev/nvme1n1p4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a"

Zastąp stary UUID partycji SWAP (nvme0n1p4) nowym w pliku /etc/fstab:

[user@server_ip ~]# sudo nano /etc/fstab

Przykład:

[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

Na podstawie powyższych wyników, stary UUID to b7b5dd38-9b51-4282-8f2d-26c65e8d58ec i powinien zostać zastąpiony nowym b3c9e03a-52f5-4683-81b6-cc10091fcd15.

Upewnij się, że zastępujesz poprawny UUID.

Następnie uruchom poniższą komendę, aby aktywować partycję SWAP:

[user@server_ip ~]# sudo swapon -av
swapon: /dev/nvme1n1p4: already active -- ignored
swapon: /dev/nvme0n1p4: found signature [pagesize=4096, signature=swap]
swapon: /dev/nvme0n1p4: pagesize=4096, swapsize=536870912, devsize=536870912
swapon /dev/nvme0n1p4

Następnie przeładuj system:

[user@server_ip ~]# sudo systemctl daemon-reload

Teraz zakończyliśmy odbudowę RAID.

Sprawdź również

Hot Swap - Software RAID

OVHcloud API i Storage

Zarządzanie hardware RAID

Hot Swap - Hardware RAID

Dla usług specjalistycznych (SEO, programowanie itp.), skontaktuj się z partnerami OVHcloud.

Jeśli potrzebujesz pomocy w użyciu i konfiguracji rozwiązań OVHcloud, zapoznaj się z naszymi ofertami wsparcia.

Jeśli potrzebujesz szkoleń lub pomocy technicznej w wdrożeniu naszych rozwiązań, skontaktuj się ze swoim przedstawicielem handlowym lub kliknij ten link, aby uzyskać wycenę i zapytać ekspertów z Professional Services o pomoc w konkretnym przypadku użycia projektu.

Dołącz do grona naszych użytkowników.

Czy ta strona była pomocna?

Zarządzanie i odbudowa oprogramowania RAID na serwerach w trybie UEFI

Wprowadzenie

Wymagania początkowe

W praktyce

Omówienie treści

Podstawowe informacje

Zrozumienie partycji systemu EFI (ESP)

Symulowanie awarii dysku

Usuwanie uszkodzonego dysku

Odbudowa macierzy RAID (z ESP bez dublowania)

Odbudowanie tablicy RAID po wymianie głównego dysku (trybu Rescue)

Odbudowanie partycji systemu EFI

Odbudowanie tablicy RAID z niezsynchronizowanymi partycjami ESP po znaczących uaktualnieniach systemu (GRUB)

Odbudowanie tablicy RAID po wymianie głównego dysku (trybu normalny)

Odbudowa macierzy RAID (z dublowaniem ESP)

Dodanie etykiety do partycji SWAP (jeśli dotyczy)

Sprawdź również

Podziel się opinią o nowej dokumentacji