Gestión y reconstrucción del RAID software en servidores en modo de arranque legacy (BIOS)

Bases de conocimiento

KB0043943

Gestión y reconstrucción del RAID software en servidores en modo de arranque legacy (BIOS)


Icons/System/eye-open Created with Sketch. 1076 visualizaciones 02.03.2026 Cloud / Servidor dedicado (bare metal)
Información sobre la traducción

Esta traducción ha sido generada de forma automática por nuestro partner SYSTRAN. En algunos casos puede contener términos imprecisos, como en las etiquetas de los botones o los detalles técnicos. En caso de duda, le recomendamos que consulte la versión inglesa o francesa de la guía. Si quiere ayudarnos a mejorar esta traducción, por favor, utilice el botón «Contribuir» de esta página.

Objetivo

El RAID (Redundant Array of Independent Disks) es un conjunto de técnicas diseñadas para mitigar la pérdida de datos en un servidor replicándolos en varios discos.

El nivel de RAID predeterminado para las instalaciones de servidores de OVHcloud es RAID 1, lo que duplica el espacio ocupado por sus datos, reduciendo así a la mitad el espacio de disco utilizable.

Esta guía explica cómo gestionar y reconstruir un RAID software en caso de reemplazar un disco en su servidor en modo de arranque legacy (BIOS).

Antes de comenzar, tenga en cuenta que esta guía se centra en los servidores dedicados que utilizan el modo de arranque legacy (BIOS). Si su servidor utiliza el modo UEFI (tarjetas madre más recientes), consulte esta guía Gestión y reconstrucción del RAID software en servidores en modo de arranque UEFI.

Para verificar si un servidor se ejecuta en modo BIOS o en modo UEFI, ejecute el siguiente comando:

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

Requisitos

  • Tener un servidor dedicado con una configuración de RAID software.
  • Tener acceso a su servidor mediante SSH como administrador (sudo).
  • Conocimiento del RAID y las particiones.

Procedimiento

Presentación del contenido

Información básica

En una sesión de línea de comandos, escriba el siguiente código para determinar el estado actual 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>

Este comando nos indica que dos dispositivos de RAID software están actualmente configurados, md4 siendo el más grande. El dispositivo de RAID md4 está compuesto por dos particiones, llamadas nvme0n1p4 y nvme1n1p4.

El [UU] significa que todos los discos funcionan normalmente. Un _ indica un disco defectuoso.

Si posee un servidor con discos SATA, obtendrá los siguientes resultados:

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

Aunque este comando devuelve nuestros volúmenes de RAID, no nos indica el tamaño de las particiones mismas. Podemos encontrar esta información con el siguiente comando:

[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

El comando fdisk -l también le permite identificar el tipo de partición. Esta es una información importante para reconstruir su RAID en caso de fallo de un disco.

Para las particiones GPT, la línea 6 mostrará: Disklabel type: gpt. Esta información solo es visible cuando el servidor está en modo normal.

Siempre basándonos en los resultados de fdisk -l, podemos ver que /dev/md2 se compone de 888.8GB y /dev/md4 contiene 973.5GB.

Alternativamente, el comando lsblk ofrece una vista diferente de las particiones:

[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

Tenga en cuenta los dispositivos, las particiones y sus puntos de montaje, ya que esto es importante, especialmente tras la sustitución de un disco. Esto le permitirá verificar que las particiones están correctamente montadas en sus puntos de montaje respectivos en el nuevo disco.

En nuestro ejemplo, tenemos:

  • Particiones que forman parte de md2 (/): sda2 y sdb2.
  • Particiones que forman parte de md4 (/home): sda4 y sdb4.
  • Particiones de intercambio (swap): sda3 y sdb3.
  • Particiones de arranque BIOS: sda1 y sdb1.

La partición sda5 es un config drive, es decir, un volumen de solo lectura que proporciona al servidor sus datos de configuración iniciales. Solo se lee una vez durante el arranque inicial y puede eliminarse después.

Simular una falla de disco

Ahora que disponemos de toda la información necesaria, podemos simular una falla de disco. En este ejemplo, haremos que el disco sda falle.

El medio preferido para lograrlo es el entorno en modo rescue de OVHcloud.

Reinicie primero el servidor en modo rescue y conéctese con las credenciales proporcionadas.

Para retirar un disco del RAID, el primer paso es marcarlo como Failed y retirar las particiones de sus matrices RAID respectivas.

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>

A partir de la salida anterior, sda se compone de dos particiones en RAID que son sda2 y sda4.

Retirar el disco defectuoso

Comenzamos marcando las particiones sda2 y sda4 como 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

Hemos simulado ahora una falla del RAID, cuando ejecutamos el comando cat /proc/mdstat, obtenemos el siguiente resultado:

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>

Como podemos ver arriba, el [F] junto a las particiones indica que el disco está fallando o defectuoso.

A continuación, retiramos estas particiones de las matrices 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

Para asegurarnos de obtener un disco que sea similar a un disco vacío, utilizamos el siguiente comando. Reemplace sda por sus propios valores:

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

El disco aparecerá ahora como un disco nuevo y vacío:

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

Si ejecutamos el siguiente comando, vemos que nuestro disco ha sido correctamente "limpiado":

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:

El estado de nuestro RAID debería ser ahora similar al siguiente:

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>

Los resultados anteriores muestran que ahora solo aparecen dos particiones en las matrices RAID. Hemos conseguido que el disco sda falle y ahora podemos proceder a su sustitución.

Para obtener más información sobre cómo preparar y solicitar la sustitución de un disco, consulte esta guía.

El siguiente comando proporciona más detalles sobre la matriz o matrices 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

Reconstruir el RAID

Este proceso puede variar en función del sistema operativo instalado en su servidor. Le recomendamos que consulte la documentación oficial de su sistema operativo para obtener los comandos adecuados.

En la mayoría de los servidores con RAID por software, tras sustituir un disco, el servidor puede arrancar en modo normal (en el disco sano) para reconstruir el RAID. Sin embargo, si el servidor no puede arrancar en modo normal, se reiniciará en modo de rescate para proceder a la reconstrucción del RAID.

Reconstrucción del RAID en modo normal

En nuestro ejemplo, hemos sustituido el disco sda.

Una vez sustituido el disco, debemos copiar la tabla de particiones del disco sano (en este ejemplo, sdb) al nuevo (sda).

  • Para particiones GPT
  • Para particiones MBR
sudo sgdisk -R /dev/sdX /dev/sdX

El comando debe tener el siguiente formato: sgdisk -R /dev/nuevo_disco /dev/disco_sano.

[user@server_ip ~]# sudo sfdisk -d /dev/sdX | sfdisk /dev/sdX

El comando debe tener el siguiente formato: sfdisk -d /dev/disco_sano | sfdisk /dev/nuevo_disco.

Una vez realizada esta operación, el siguiente paso consiste en asignar un GUID aleatorio al nuevo disco para evitar cualquier conflicto con los GUID de otros discos:

sudo sgdisk -G /dev/sdX

Si aparece el siguiente mensaje:

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.

Simplemente ejecute el comando partprobe. Si sigue sin ver las particiones recién creadas (por ejemplo, con lsblk), debe reiniciar el servidor antes de continuar.

A continuación, añadimos las particiones 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

Use el siguiente comando para supervisar la reconstrucción 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>

Finalmente, añadimos una etiqueta y montamos la partición [SWAP] (si aplica).

Para añadir una etiqueta a la partición SWAP:

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

A continuación, obtenga los UUID de ambas particiones de intercambio:

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

Reemplazamos el antiguo UUID de la partición de intercambio (sda4) por el nuevo en /etc/fstab.

Ejemplo:

[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

Según los resultados anteriores, el UUID antiguo es b7b5dd38-9b51-4282-8f2d-26c65e8d58ec y debe sustituirse por el nuevo b3c9e03a-52f5-4683-81b6-cc10091fcd15.

Asegúrese de sustituir el UUID correcto.

A continuación, comprobamos que todo está correctamente montado con el siguiente comando:

[user@server_ip ~]# sudo mount -av
/                        : successfully mounted
/home                    : successfully mounted
swap                     : ignored
swap                     : ignored

Ejecute el siguiente comando para activar la partición de intercambio:

[user@server_ip ~]# sudo swapon -av

A continuación, recargue el sistema con el siguiente comando:

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

La reconstrucción del RAID ahora está terminada.

Reconstrucción del RAID en modo rescue

Si el servidor no consigue reiniciarse en modo normal tras una sustitución de disco, nuestro equipo lo reiniciará en modo de rescate en el datacenter.

En este ejemplo, hemos sustituido el disco sdb.

Una vez reemplazado el disco, debemos copiar la tabla de particiones del disco en buen estado (en este ejemplo, sda) al nuevo (sdb).

  • Para particiones GPT
  • Para particiones MBR
root@rescue12-customer-eu (nsxxxxx.ip-xx-xx-xx.eu) ~ # sgdisk -R /dev/sdX /dev/sdX

El comando debe tener el siguiente formato: sgdisk -R /dev/nuevo_disco /dev/disco_sano

Ejemplo:

sudo sgdisk -R /dev/sdb /dev/sda
sudo sfdisk -d /dev/sda | sfdisk /dev/sdb

El comando debe tener el siguiente formato: sfdisk -d /dev/disco_sano | sfdisk /dev/nuevo_disco

Ejemplo:

sudo sfdisk -d /dev/sda | sfdisk /dev/sdb

Una vez realizada esta operación, el siguiente paso consiste en asignar un GUID aleatorio al nuevo disco para evitar conflictos con los GUID de otros discos:

sudo sgdisk -G /dev/sdb

Si aparece el siguiente mensaje:

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.

Puede simplemente ejecutar el comando partprobe.

Ahora podemos reconstruir la matriz RAID añadiendo de nuevo las nuevas particiones (sdb2 y 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

Use el comando cat /proc/mdstat para supervisar la reconstrucción 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>

Por último, añadimos una etiqueta y montamos la partición [SWAP] (si procede).

Una vez finalizada la reconstrucción del RAID, montamos la partición que contiene la raíz de nuestro sistema operativo en /mnt. En nuestro ejemplo, esta partición es md2.

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

Añadimos la etiqueta a nuestra partición de intercambio con el siguiente 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

A continuación, montamos los siguientes directorios para asegurarnos de que cualquier manipulación que realicemos en el entorno chroot funcione correctamente:

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

A continuación, accedemos al entorno chroot:

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

Recuperamos los UUID de ambas particiones de intercambio:

root@rescue12-customer-eu:/# blkid -s UUID /dev/sda4
root@rescue12-customer-eu:/# blkid -s UUID /dev/sdb4

Ejemplo:

blkid /dev/sda4
/dev/sda4: UUID="b3c9e03a-52f5-4683-81b6-cc10091fcd15"
blkid /dev/sdb4
/dev/sdb4: UUID="d6af33cf-fc15-4060-a43c-cb3b5537f58a"

A continuación, reemplazamos el antiguo UUID de la partición de intercambio (sdb4) por el nuevo en /etc/fstab:

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

Ejemplo:

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

En nuestro ejemplo anterior, el UUID a reemplazar es d6af33cf-fc15-4060-a43c-cb3b5537f58a por el nuevo b3c9e03a-52f5-4683-81b6-cc10091fcd15.

Asegúrese de reemplazar el UUID correcto.

A continuación, nos aseguramos de que todo esté correctamente montado:

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

Active la partición de intercambio con el siguiente comando:

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

Salimos del entorno chroot con exit y volvemos a cargar el sistema:

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

Desmontamos todos los discos:

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

Hemos terminado con éxito la reconstrucción del RAID en el servidor y ahora podemos reiniciar el servidor en modo normal.

Más información

Reemplazo a caliente - RAID software

API OVHcloud y Almacenamiento

Gestión del RAID hardware

Reemplazo a caliente - RAID hardware

Para servicios especializados (posicionamiento, desarrollo, etc.), contacte con los socios OVHcloud.

Si desea beneficiarse de una asistencia en el uso y configuración de sus soluciones OVHcloud, le invitamos a consultar nuestras distintas ofertas de soporte.

Si necesita una formación o asistencia técnica para la implementación de nuestras soluciones, contacte con su comercial o haga clic en este enlace para obtener un presupuesto y solicitar un análisis personalizado de su proyecto a nuestros expertos del equipo Professional Services.

Interactúe con nuestra comunidad de usuarios.

Artículos relacionados