Gestione e ricostruzione del RAID software sui server in modalità legacy boot (BIOS)
Obiettivo
Il RAID (Redundant Array of Independent Disks) è un insieme di tecniche progettate per ridurre la perdita di dati su un server replicandoli su più dischi.
Il livello RAID predefinito per le installazioni dei server OVHcloud è RAID 1, che raddoppia lo spazio occupato dai vostri dati, riducendo quindi a metà lo spazio disco utilizzabile.
Questa guida spiega come gestire e ricostruire un RAID software in caso di sostituzione di un disco su un server in modalità legacy boot (BIOS).
Prima di iniziare, notate che questa guida si concentra sui server dedicati che utilizzano la modalità legacy boot (BIOS). Se il vostro server utilizza la modalità UEFI (schede madri più recenti), fate riferimento a questa guida Gestione e ricostruzione del RAID software sui server in modalità boot UEFI.
Per verificare se un server è in esecuzione in modalità BIOS o in modalità UEFI, eseguite il comando seguente:
[user@server_ip ~]# [ -d /sys/firmware/efi ] && echo UEFI || echo BIOS
Prerequisiti
- Possedere un server dedicato con una configurazione RAID software.
- Avere accesso al server tramite SSH come amministratore (sudo).
- Conoscenza del RAID e delle partizioni.
Procedura
Panoramica del contenuto
Nella sessione della riga di comando, digitate il codice seguente per determinare lo stato attuale del 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>
Questo comando ci indica che due dispositivi RAID software sono attualmente configurati, md4 essendo il più grande. Il dispositivo RAID md4 è composto da due partizioni, denominate nvme0n1p4 e nvme1n1p4.
Il [UU] significa che tutti i dischi funzionano normalmente. Un _ indica un disco guasto.
Se possedete un server con dischi SATA, otterrete i seguenti risultati:
[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>
Sebbene questo comando restituisca i nostri volumi RAID, non ci indica la dimensione delle partizioni stesse. Possiamo trovare questa informazione con il comando seguente:
[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
Il comando fdisk -l vi permette inoltre di identificare il tipo di partizione. Si tratta di un'informazione importante per ricostruire il vostro RAID in caso di guasto di un disco.
Per le partizioni GPT, la riga 6 mostrerà: Disklabel type: gpt. Queste informazioni sono visibili solo quando il server è in modalità normale.
Ancora in base ai risultati di fdisk -l, possiamo vedere che /dev/md2 è composto da 888.8GB e /dev/md4 contiene 973.5GB.
In alternativa, il comando lsblk offre una visione diversa delle partizioni:
[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
Prendete nota dei dispositivi, delle partizioni e dei punti di montaggio, poiché questo è importante, in particolare dopo la sostituzione di un disco. Questo vi permetterà di verificare che le partizioni siano correttamente montate sui rispettivi punti di montaggio sul nuovo disco.
Nel nostro esempio, abbiamo:
- Partizioni che fanno parte di md2 (
/) : sda2 e sdb2.
- Partizioni che fanno parte di md4 (
/home) : sda4 e sdb4.
- Partizioni swap : sda3 e sdb3.
- Partizioni BIOS boot : sda1 e sdb1.
La partizione sda5 è un config drive, ovvero un volume in sola lettura che fornisce al server i suoi dati di configurazione iniziale. Viene letta solo una volta al primo avvio e può essere eliminata in seguito.
Simulare un guasto del disco
Disponiamo di tutte le informazioni necessarie per simulare un guasto del disco. In questo esempio, faremo fallire il disco sda.
Il metodo preferito per farlo è l'ambiente in modalità rescue di OVHcloud.
Riavviate prima il server in modalità rescue e connettetevi con le credenziali fornite.
Per rimuovere un disco dal RAID, il primo passo consiste nel marcarlo come Failed e rimuovere le partizioni dai loro array RAID rispettivi.
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>
Dall'output sopra, sda è composto da due partizioni in RAID che sono sda2 e sda4.
Rimozione del disco guasto
Iniziamo marcando le partizioni sda2 e sda4 come 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
Ora abbiamo simulato un guasto al RAID, quando eseguiamo il comando cat /proc/mdstat, otteniamo il risultato seguente:
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>
Come possiamo vedere sopra, il [F] accanto alle partizioni indica che il disco è guasto o difettoso.
Successivamente, rimuoviamo queste partizioni dagli array 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
Per simulare un disco vuoto, utilizzate il comando seguente. Sostituite sda con i vostri valori:
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
Il disco appare ora come un disco nuovo e vuoto:
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
Se eseguiamo il seguente comando, vediamo che il nostro disco è stato correttamente "cancellato":
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:
Lo stato del nostro RAID dovrebbe ora apparire come segue:
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>
I risultati sopra riportati mostrano che nelle matrici RAID vengono visualizzate solo due partizioni. Il disco sda ha avuto esito negativo e ora è possibile procedere alla sostituzione del disco.
Per informazioni sulla preparazione e la richiesta di sostituzione di un disco, consultate questa guida.
Il comando seguente fornisce maggiori dettagli sulle matrici 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
Ricostruire il RAID
Info
Questo processo può variare a seconda del sistema operativo installato sul server. Si consiglia di consultare la documentazione ufficiale del sistema operativo per ottenere i comandi appropriati.
Warning
Per la maggior parte dei server con RAID software, dopo la sostituzione del disco, il server è in grado di avviarsi in modalità normale (sul disco sano) per ricostruire il RAID. Tuttavia, se il server non riesce ad avviarsi in modalità normale, verrà riavviato in modalità rescue per procedere alla ricostruzione del RAID.
Ricostruzione del RAID in modalità normale
Nel nostro esempio, abbiamo sostituito il disco sda.
Una volta sostituito il disco, dobbiamo copiare la tabella di partizione del disco sano (in questo esempio, sdb) su quello nuovo (sda).
sudo sgdisk -R /dev/sdX /dev/sdX
Il comando deve essere nel formato seguente: sgdisk -R /dev/nuovo_disco /dev/disco_sano.
[user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX
Il comando deve essere nel formato seguente: sfdisk -d /dev/disco_sano | sfdisk /dev/nuovo_disco.
Una volta effettuata questa operazione, il passaggio successivo consiste nell'assegnare un GUID casuale al nuovo disco per evitare qualsiasi conflitto con i GUID di altri dischi:
Se viene visualizzato il seguente messaggio:
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.
Eseguite partprobe. Se le partizioni appena create non sono ancora visibili (ad esempio con lsblk), è necessario riavviare il server prima di continuare.
Quindi, aggiungiamo le partizioni al 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
Utilizzate il seguente comando per monitorare la ricostruzione del RAID:
[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>
Infine, aggiungiamo un'etichetta e montiamo la partizione [SWAP] (se necessario).
Per aggiungere un'etichetta alla partizione SWAP:
[user@server_ip ~]# sudo mkswap /dev/sda4 -L swap-sda4
Successivamente, recuperiamo gli UUID delle due partizioni 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"
Sostituiamo il vecchio UUID della partizione SWAP (sda4) con quello nuovo nel file /etc/fstab.
Esempio:
[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
In base ai risultati sopra riportati, il vecchio UUID è b7b5dd38-9b51-4282-8f2d-26c65e8d58ec e deve essere sostituito con il nuovo b3c9e03a-52f5-4683-81b6-cc10091fcd15.
Assicuratevi di sostituire l'UUID corretto.
Quindi, verifichiamo che tutto sia montato correttamente utilizzando il seguente comando:
[user@server_ip ~]# sudo mount -av
/ : successfully mounted
/home : successfully mounted
swap : ignored
swap : ignored
Eseguite il comando seguente per attivare la partizione swap:
[user@server_ip ~]# sudo swapon -av
Successivamente, ricaricate il sistema con il comando seguente:
[user@server_ip ~]# sudo systemctl daemon-reload
La ricostruzione del RAID è ora completata.
Ricostruzione del RAID in modalità rescue
Se il vostro server non riesce a riavviarsi in modalità normale dopo la sostituzione del disco, verrà riavviato in modalità rescue dal nostro team del data center.
In questo esempio, abbiamo sostituito il disco sdb.
Una volta sostituito il disco, dobbiamo copiare la tabella delle partizioni del disco sano (in questo esempio, sda) verso il nuovo (sdb).
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX
Il comando deve essere nel formato seguente: sgdisk -R /dev/nuovo_disco /dev/disco_sano
Esempio:
sudo sgdisk -R /dev/sdb /dev/sda
sudo sfdisk -d /dev/sda | sfdisk /dev/sdb
Il comando deve essere nel formato seguente: sfdisk -d /dev/disco_sano | sfdisk /dev/nuovo_disco
Esempio:
sudo sfdisk -d /dev/sda | sfdisk /dev/sdb
Una volta completata questa operazione, il passo successivo consiste nell'assegnare un GUID casuale al nuovo disco per evitare conflitti con i GUID di altri dischi:
Se appare il seguente messaggio:
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.
Eseguite il comando partprobe.
Possiamo ora ricostruire l'array RAID aggiungendo le nuove partizioni (sdb2 e 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
Utilizzate il comando cat /proc/mdstat per monitorare la ricostruzione del 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>
Infine, aggiungiamo un'etichetta e montiamo la partizione [SWAP] (se necessario).
Una volta completata la ricostruzione del RAID, montiamo la partizione che contiene la radice del nostro sistema operativo su /mnt. Nell'esempio, questa partizione è md2.
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # mount /dev/md2 /mnt
Aggiungiamo l'etichetta alla nostra partizione swap con il comando:
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
Successivamente, montiamo le seguenti directory per assicurarci che qualsiasi modifica che effettuiamo nell'ambiente chroot funzioni correttamente:
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
Successivamente, accediamo all'ambiente chroot:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # chroot /mnt
Recuperiamo gli UUID delle due partizioni SWAP:
root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4
root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4
Esempio:
blkid /dev/sda4
/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15"
blkid /dev/sdb4
/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a"
Successivamente, sostituiamo l'UUID vecchio della partizione swap (sdb4) con il nuovo in /etc/fstab:
root@rescue12-customer-eu:/# nano /etc/fstab
Esempio:
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
Nell'esempio sopra, l'UUID da sostituire è d6af33cf-fc15-4060-a43c-cb3b5537f58a con il nuovo b3c9e03a-52f5-4683-81b6-cc10091fcd15.
Assicuratevi di sostituire l'UUID corretto.
Successivamente, verifichiamo che tutto sia correttamente montato:
root@rescue12-customer-eu:/# mount -av
/ : successfully mounted
/home : successfully mounted
swap : ignored
swap : ignored
Attivate la partizione swap con il comando seguente:
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
Usciamo dall'ambiente chroot con exit e ricarichiamo il sistema:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # systemctl daemon-reload
Smontiamo tutti i dischi:
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # umount -R /mnt
La ricostruzione del RAID è ora completata. Riavviate il server in modalità normale.
Per saperne di più
Hotswap - RAID software
API OVHcloud e Archiviazione
Gestione del RAID hardware
Hotswap - RAID hardware
Per servizi specializzati (posizionamento, sviluppo, ecc.), contatta i partner OVHcloud.
Se desideri ricevere un supporto sull'utilizzo e la configurazione delle tue soluzioni OVHcloud, consulta le nostre diverse offerte di supporto.
Se hai bisogno di un corso o di un supporto tecnico per l'implementazione delle nostre soluzioni, contatta il tuo commerciale o clicca su questo link per ottenere un preventivo e richiedere un'analisi personalizzata del tuo progetto ai nostri esperti del team Professional Services.
Contatta la nostra Community di utenti.
