Zarządzanie i odbudowanie oprogramowania RAID na serwerach w trybie rozruchu legacy (BIOS)
Wprowadzenie
Redundantny zbiór niezależnych dysków (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 przestrzeń zajmowaną przez dane, skutecznie zmniejszając wykorzystywalną przestrzeń dyskową.
Ta instrukcja wyjaśnia, jak zarządzać i odbudować oprogramowanie RAID w przypadku wymiany dysku na serwerze w trybie rozruchu legacy (BIOS).
Zanim zaczniemy, zwróć uwagę, że ta instrukcja koncentruje się na Serwerach dedykowanych, które używają trybu rozruchu legacy (BIOS). Jeśli Twój serwer używa trybu UEFI (nowsze płyty główne), odwiedź tę instrukcję Zarządzanie i odbudowanie oprogramowania RAID na serwerach w trybie rozruchu UEFI.
Aby sprawdzić, czy serwer działa w trybie legacy BIOS czy UEFI, uruchom następujące polecenie:
[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
Wymagania początkowe
- Serwer Dedykowany z konfiguracją oprogramowania RAID
- Dostęp administracyjny (sudo) do serwera przez SSH
- Zrozumienie RAID i partycji
W praktyce
Kiedy zakupisz nowy serwer, możesz czuć potrzebę wykonania szeregu testów i działań. Jednym z takich testów może być symulacja awarii dysku, aby zrozumieć proces odbudowy RAID i przygotować się na wypadek, gdyby to się kiedykolwiek zdarzyło.
Omówienie treści
W sesji wiersza poleceń wpisz poniższe polecenie, aby określić bieżący stan RAID:
[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: <none>
To polecenie pokazuje nam, że mamy dwa urządzenia RAID oprogramowania obecnie skonfigurowane, z md4 będącym największym z nich. Urządzenie RAID md4 składa się z dwóch partycji, które są znane jako nvme0n1p4 i nvme1n1p4.
[UU] oznacza, że wszystkie dyski działają normalnie. _ wskazuje na uszkodzony dysk.
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]
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: <none>
Chociaż to polecenie zwraca nasze woluminy RAID, nie podaje ono rozmiaru samych partycji. Informacje te można znaleźć za pomocą polecenia fdisk -l:
[user@server_ip ~]# sudo fdisk -l
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
Device Start End Sectors Size Type
/dev/sdb1 2048 4095 2048 1M BIOS boot
/dev/sdb2 4096 1864177663 1864173568 888.9G Linux RAID
/dev/sdb3 1864177664 1865226239 1048576 512M Linux filesystem
/dev/sdb4 1865226240 3907024895 2041798656 973.6G Linux RAID
Disk /dev/sda: 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: 2E1DCCBA-8808-4D2B-BA33-9FEC3B96ADA8
Device Start End Sectors Size Type
/dev/sda1 2048 4095 2048 1M BIOS boot
/dev/sda2 4096 1864177663 1864173568 888.9G Linux RAID
/dev/sda3 1864177664 1865226239 1048576 512M Linux filesystem
/dev/sda4 1865226240 3907024895 2041798656 973.6G Linux RAID
/dev/sda5 3907025072 3907029134 4063 2M Linux filesystem
Disk /dev/md4: 973.5 GiB, 1045265645568 bytes, 2041534464 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/md2: 888.8 GiB, 954321600512 bytes, 1863909376 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
Polecenie fdisk -l pozwala również zidentyfikować typ partycji. Jest to ważna informacja, gdy chodzi o odbudowanie RAID w przypadku awarii dysku.
Dla partycji GPT, linia 6 będzie wyświetlać: Disklabel type: gpt. Ta informacja może być widoczna tylko, gdy serwer działa w trybie normalnym.
Zgodnie z wynikami fdisk -l, możemy stwierdzić, że /dev/md2 składa się z 888,8 GB, a /dev/md4 zawiera 973,5 GB.
Alternatywnie, polecenie lsblk oferuje inny widok partycji:
[user@server_ip ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 888.9G 0 part
│ └─md2 9:2 0 888.8G 0 raid1 /
├─sda3 8:3 0 512M 0 part [SWAP]
├─sda4 8:4 0 973.6G 0 part
│ └─md4 9:4 0 973.5G 0 raid1 /home
└─sda5 8:5 0 2M 0 part
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
Zwróć uwagę na urządzenia, partycje i punkty montowania, ponieważ jest to ważne, szczególnie po wymianie dysku. Pozwoli Ci to sprawdzić, czy partycje są prawidłowo zamontowane w odpowiednich punktach montowania na nowym dysku.
W naszym przykładzie mamy:
- Partycje tworzące md2 (
/): sda2 i sdb2.
- Partycje tworzące md4 (
/home): sda4 i sdb4.
- Partycje swap: sda3 i sdb3.
- Partycje rozruchowe BIOS: sda1 i sdb1.
Partycja sda5 jest config drive, tj. woluminem tylko do odczytu, który dostarcza serwerowi jego wstępnych danych konfiguracyjnych. Jest odczytywany tylko raz podczas pierwszego uruchomienia i może być usunięty po tym czasie.
Symulowanie awarii dysku
Teraz, gdy mamy wszystkie niezbędne informacje, możemy zasymulować awarię dysku. W tym przykładzie zasymulujemy awarię dysku sda.
Preferowany sposób to wykonanie tego za pośrednictwem środowiska ratunkowego OVHcloud.
Najpierw uruchom serwer w trybie ratunkowym i zaloguj się przy użyciu dostarczonych poświadczeń.
Aby usunąć dysk z RAID, pierwszym krokiem jest oznaczenie go jako Failed i usunięcie partycji z ich odpowiednich tablic RAID.
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: <none>
Z powyższego wyniku wynika, że sda składa się z dwóch partycji w RAID, które to sda2 i sda4.
Usuwanie uszkodzonego dysku
Najpierw oznaczamy partycje sda2 i sda4 jako Failed.
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md2 --fail /dev/sda2
# mdadm: set /dev/sda2 faulty in /dev/md2
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --manage /dev/md4 --fail /dev/sda4
# mdadm: set /dev/sda4 faulty in /dev/md4
Teraz zasymulowaliśmy awarię RAID, a po uruchomieniu polecenia cat /proc/mdstat mamy następujące dane wyjściowe:
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](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: <none>
Jak widać powyżej, [F] obok partycji wskazuje, że dysk uległ awarii lub jest uszkodzony.
Następnie usuwamy te partycje z tablic RAID.
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md2 --remove /dev/sda2
# mdadm: hot removed /dev/sda2 from /dev/md2
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sudo mdadm --manage /dev/md4 --remove /dev/sda4
# mdadm: hot removed /dev/sda4 from /dev/md4
Aby upewnić się, że otrzymamy dysk podobny do pustego dysku, używamy poniższego polecenia. Zamień sda na swoje własne wartości:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ #
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
Dysk pojawia się teraz jako nowy i "pusty":
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
Jeśli wykonamy następujące polecenie, zobaczymy, że nasz dysk został prawidłowo "wyczyszczony":
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:
Stan naszego RAID powinien teraz wyglądać następująco:
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 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 [1/2] [_U]
bitmap: 0/8 pages [0KB], 65536KB chunk
unused devices: <none>
Powyższe wyniki pokazują, że w macierzy RAID pojawiają się teraz tylko dwie partycje. Dysk sda nie powiódł się i możemy teraz wymienić dysk.
Więcej informacji na temat przygotowywania i żądania wymiany dysku można znaleźć w tym przewodniku.
Poniższe polecenie pozwala uzyskać więcej szczegółowych informacji na temat macierzy RAID:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mdadm --detail /dev/md4
/dev/md4:
Version : 1.2
Creation Time : Tue Jan 24 15:35:02 2023
Raid Level : raid1
Array Size : 1020767232 (973.48 GiB 1045.27 GB)
Used Dev Size : 1020767232 (973.48 GiB 1045.27 GB)
Raid Devices : 2
Total Devices : 1
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Tue Jan 24 16:28:03 2023
State : clean, degraded
Active Devices : 1
Working Devices : 1
Failed Devices : 0
Spare Devices : 0
Consistency Policy : bitmap
Name : md4
UUID : 7b5c1d80:0a7ab4c2:e769b5e5:9c6eaa0f
Events : 21
Number Major Minor RaidDevice State
- 0 0 0 removed
1 8 20 1 active sync /dev/sdb4
Odbudowa macierzy RAID
Info
Proces ten może się różnić w zależności od systemu operacyjnego zainstalowanego na serwerze. Zalecamy zapoznanie się z oficjalną dokumentacją systemu operacyjnego, aby uzyskać informacje na temat odpowiednich poleceń.
Warning
W przypadku większości serwerów z macierzą RAID oprogramowania po wymianie dysku serwer może uruchomić się w trybie normalnym (na sprawnym dysku) w celu odbudowy macierzy RAID. Jeśli jednak serwer nie uruchomi się w trybie normalnym, zostanie ponownie uruchomiony w trybie ratunkowym w celu odbudowy macierzy RAID.
Odbudowa macierzy RAID w trybie normalnym
W naszym przykładzie wymieniliśmy dysk sda.
Po wymianie dysku musimy skopiować tabelę partycji z dysku sprawnego (w tym przykładzie sdb) na nowy (sda).
sudo sgdisk -R /dev/sdX /dev/sdX
Polecenie musi mieć następujący format: sgdisk -R /dev/nowy_dysk /dev/zdrowy_dysk.
[user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX
Polecenie powinno mieć następujący format: sfdisk -d /dev/zdrowy_dysk | sfdisk /dev/nowy_dysk.
Po wykonaniu tej operacji następnym krokiem jest przypisanie losowego identyfikatora GUID do nowego dysku, aby uniknąć konfliktu z identyfikatorami GUID innych dysków:
Jeśli pojawi się następujący 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.
Możesz po prostu wykonać polecenie partprobe. Jeśli nadal nie widzisz nowo utworzonych partycji (na przykład za pomocą lsblk), musisz ponownie uruchomić serwer przed kontynuowaniem.
Następnie dodajemy partycje do macierzy RAID:
[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
Aby monitorować odbudowę RAID, użyj poniższego polecenia:
[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: <none>
Na koniec dodajemy etykietę i montujemy partycję [SWAP] (jeśli dotyczy).
Aby dodać etykietę do partycji SWAP:
[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4
Następnie pobierz UUID obu partycji SWAP:
[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"
Zastępujemy stary UUID partycji SWAP (sda4) nowym w pliku /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=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
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 sprawdzamy, czy wszystko zostało poprawnie zamontowane, używając następującego polecenia:
[user@server_ip ~]# sudo mount -av
/ : successfully mounted
/home : successfully mounted
swap : ignored
swap : ignored
Uruchom poniższe polecenie, aby włączyć partycję SWAP:
[user@server_ip ~]# sudo swapon -av
Następnie przeładuj system poniższym poleceniem:
[user@server_ip ~]# sudo systemctl daemon-reload
W ten sposób skończyliśmy pomyślnie odbudowę RAID.
Odbudowanie RAID w trybie rescue
Jeśli Twój serwer nie może uruchomić się w trybie normalnym po wymianie dysku, zostanie on uruchomiony w trybie ratunkowym przez nasz zespół centrum danych.
W tym przykładzie wymieniamy dysk sdb.
Po wymianie dysku musimy skopiować tablicę partycji z dysku sprawnego (w tym przykładzie sda) na nowy (sdb).
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX
Polecenie powinno mieć następujący format: sgdisk -R /dev/nowy_dysk /dev/zdrowy_dysk
Przykład:
sudo sgdisk -R /dev/sdb /dev/sda
sudo sfdisk -d /dev/sda | sfdisk /dev/sdb
Polecenie powinno mieć ten format: sfdisk -d /dev/zdrowy_dysk | sfdisk /dev/nowy_dysk
Przykład:
sudo sfdisk -d /dev/sda | sfdisk /dev/sdb
Po wykonaniu tego kroku następnym krokiem jest zrandomizowanie GUID nowego dysku, aby uniknąć konfliktów GUID z innymi dyskami:
Jeśli otrzymasz następującą wiadomość:
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.
Możesz po prostu uruchomić polecenie partprobe.
Teraz możemy odbudować tablicę RAID, dodając z powrotem nowe partycje (sdb2 i sdb4):
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
Użyj polecenia cat /proc/mdstat, aby monitorować odbudowę RAID:
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: <none>
Na koniec dodajemy etykietę i montujemy partycję [SWAP] (jeśli dotyczy).
Po zakończeniu odbudowy RAID montujemy partycję zawierającą korzeń naszego systemu operacyjnego na /mnt. W naszym przykładzie tą partycją jest md2.
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md2 /mnt
Dodajemy etykietę do naszej partycji SWAP za pomocą polecenia:
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
Następnie montujemy poniższe katalogi, aby upewnić się, że wszystkie operacje 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 wchodzimy do środowiska chroot:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt
Pobieramy UUID obu partycji SWAP:
root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4
root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4
Przykład:
blkid /dev/sda4
/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15"
blkid /dev/sdb4
/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a"
Następnie zastępujemy stary UUID partycji SWAP (sdb4) 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 /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
W powyższym przykładzie UUID do zastąpienia to d6af33cf-fc15-4060-a43c-cb3b5537f58a nowym b3c9e03a-52f5-4683-81b6-cc10091fcd15.
Upewnij się, że zastępujesz poprawny UUID.
Następnie upewniamy się, że wszystko zostało poprawnie zamontowane:
root@rescue12-customer-eu:/# mount -av
/ : successfully mounted
/home : successfully mounted
swap : ignored
swap : ignored
Włącz partycję SWAP poniższym poleceniem:
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
Wyjdź ze środowiska chroot za pomocą exit i przeładuj system:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload
Odmontuj wszystkie dyski:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt
W ten sposób pomyślnie zakończyliśmy odbudowę RAID na serwerze i teraz możemy go ponownie uruchomić w trybie normalnym.
Sprawdź również
Hot Swap - Software RAID
OVHcloud API i Storage
Zarządzanie hardware RAID
Hot Swap - Hardware RAID
Dla usług specjalistycznych (SEO, rozwój, itp.), skontaktuj się z partnerami OVHcloud.
Jeśli potrzebujesz pomocy w użyciu i konfiguracji rozwiązań OVHcloud, skorzystaj z naszych ofert wsparcia.
Jeśli potrzebujesz szkoleń lub pomocy technicznej w zakresie wdrażania naszych rozwiązań, skontaktuj się z przedstawicielem handlowym lub kliknij ten link, aby uzyskać wycenę i poprosić naszych ekspertów Professional Services o pomoc w Twoim konkretnym przypadku użycia.
Dołącz do grona naszych użytkowników.
