Gestione e ricostruzione del RAID software sui server in modalità legacy boot (BIOS)

Database di conoscenze

KB0043947

Gestione e ricostruzione del RAID software sui server in modalità legacy boot (BIOS)


Icons/System/eye-open Created with Sketch. 1656 viste 02.03.2026 Cloud / Server dedicato (bare metal)
Informazioni sulla traduzione

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.

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

Informazioni di base

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

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.

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).

  • Per le partizioni GPT
  • Per le partizioni MBR
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:

sudo sgdisk -G /dev/sdX

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).

  • Per le partizioni GPT
  • Per le partizioni MBR
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:

sudo sgdisk -G /dev/sdb

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.

Articoli correlati