SSD Nodes Learn 🎉 VPS desde $4.99/mes
Guías Matt ConnorPor Matt Connor · Actualizado 2026-08-07

RAID 10 para almacenamiento VPS: ventajas y límites

Compara qué fallos soportan RAID 1, 5, 6 y 10, el coste de una reconstrucción NVMe y cómo leer /proc/mdstat. RAID no sustituye las copias de seguridad.

Qué es RAID 10 y por qué lo usan los proveedores de VPS

RAID 10 es la distribución de almacenamiento que usan la mayoría de los proveedores de VPS sobre unidades NVMe (non-volatile memory express) virtualizadas. Replica cada unidad en una unidad asociada y después distribuye los datos entre esos pares replicados. Una unidad puede fallar sin que la matriz se detenga. La reparación consiste en copiar los datos desde la unidad asociada que sigue funcionando, en lugar de recalcularlos leyendo todas las demás unidades del conjunto.

RAID significa matriz redundante de discos independientes. Su única función es mantener el equipo operativo mientras un disco está averiado o se sustituye. Esa función es la disponibilidad, y la disponibilidad no equivale a seguridad.

RAID replica las escrituras. rm -rf /srv es una escritura. Las dos mitades de la réplica eliminan el directorio en el mismo milisegundo y la matriz sigue indicando que está en buen estado.

Conserve esa frase. El resto de esta página explica qué fallos soporta cada nivel y qué coste tiene cada uno en cada escritura. Las últimas secciones contienen los comandos para consultar el estado de una matriz en un equipo que administre y explican el fallo que RAID nunca ha cubierto.

Los niveles que realmente encuentra quien contrata hosting: 1, 5, 6 y 10

La página de un plan muestra un número y no explica nada más. Ese número responde a dos preguntas: cuántas unidades pueden fallar y cuánto cuesta cada escritura.

RAID 1 es un espejo. Dos unidades contienen bloques idénticos. Cada escritura se realiza en ambas. Cualquiera de las dos puede atender una lectura. Una unidad puede fallar sin pérdida de datos, y la mitad de la capacidad bruta queda disponible. No hay paridad que calcular, por lo que la ruta de escritura es corta.

RAID 5 distribuye los datos con un bloque de paridad por cada franja. Con n unidades, se obtiene la capacidad de n-1 unidades y el conjunto sobrevive exactamente a un fallo. La paridad no se almacena en una unidad dedicada. Se distribuye de forma rotatoria entre todas, por lo que cada unidad contiene datos y paridad.

RAID 6 añade un segundo bloque de paridad independiente a cada franja, normalmente identificado como P y Q. Sobrevive al fallo simultáneo de dos unidades cualesquiera. Esto es más importante de lo que parece, porque el segundo fallo suele producirse mientras se repara el primero.

RAID 10 es una franja de espejos. Las unidades se agrupan en pares duplicados y los datos se distribuyen entre esos pares. La capacidad disponible es la mitad del total bruto, igual que en RAID 1, con el paralelismo de la distribución adicional.

También se escribe RAID 1+0, que es la descripción exacta: primero se crean los espejos y después se distribuyen entre ellos. RAID 0+1 aplica el orden contrario: primero distribuye los datos y después duplica las dos franjas. Es peor, porque el fallo de una unidad deja fuera de servicio una franja completa y la reparación debe copiar todo el otro lado.

Linux es un caso especial que conviene conocer. El raid10 del kernel es una única personalidad, no dos capas superpuestas, por lo que funciona con un número impar de unidades y admite distribuciones (near, far, offset) que una configuración anidada no puede expresar. Por eso la línea de estado de un sistema Linux muestra 2 near-copies en lugar de indicar dos conjuntos.

ChartEight 1 TB drives: usable capacity and drives lost before data loss
The data behind this chart
[
  {
    "label": "RAID 1 (four mirrored pairs)",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  },
  {
    "label": "RAID 5",
    "usable_tb": 7,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 1
  },
  {
    "label": "RAID 6",
    "usable_tb": 6,
    "worst_case_drives_lost": 2,
    "best_case_drives_lost": 2
  },
  {
    "label": "RAID 10",
    "usable_tb": 4,
    "worst_case_drives_lost": 1,
    "best_case_drives_lost": 4
  }
]

Ocho unidades de 1 TB proporcionan 7 TB de espacio disponible con RAID 5 y 4 TB con RAID 10. Esa diferencia representa dinero real y explica por qué se sigue proponiendo la paridad. RAID 6 sobrevive a 2 fallos con cualquier combinación. RAID 10 sólo garantiza 1, porque el segundo fallo peligroso es el que afecta a la pareja de la unidad que ya había fallado. Puede sobrevivir hasta 4 fallos cuando ningún par sufre dos fallos, pero eso depende de la suerte y no es una propiedad del diseño.

Qué coste tiene cada nivel en cada escritura

Una escritura en un espejo son dos escrituras que se emiten al mismo tiempo en ambos miembros. Una escritura en una franja de paridad requiere más trabajo, porque el bloque de paridad de esa franja deja de ser válido y debe volver a calcularse.

El controlador no puede volver a calcular la paridad usando sólo el bloque nuevo. Primero necesita el bloque de datos antiguo y el bloque de paridad antiguo. Por eso, una escritura aleatoria pequeña en RAID 5 se convierte en leer, leer, escribir, escribir. RAID 6 debe mantener un segundo código de paridad, por lo que la misma escritura se convierte en leer, leer, leer, escribir, escribir, escribir.

ChartDevice operations per small random write, and drives read during a rebuild
The data behind this chart
[
  {
    "label": "RAID 1 (2 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  },
  {
    "label": "RAID 5 (8 drives)",
    "write_ops_per_host_write": 4,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 6 (8 drives)",
    "write_ops_per_host_write": 6,
    "drives_read_to_rebuild": 7
  },
  {
    "label": "RAID 10 (8 drives)",
    "write_ops_per_host_write": 2,
    "drives_read_to_rebuild": 1
  }
]

Una escritura aleatoria pequeña cuesta 6 operaciones de dispositivo en RAID 6 y 2 en RAID 10. Estas cifras subestiman la diferencia de latencia. Las dos escrituras del espejo se ejecutan en paralelo, por lo que el invitado espera a que termine la más lenta. En la ruta de paridad, una lectura debe terminar antes de poder calcular la paridad nueva, por lo que el invitado espera primero una lectura y después una escritura. En un host ocupado, esa lectura queda en cola detrás de las operaciones de E/S de los demás.

Hay una excepción importante. Una escritura lo bastante grande como para llenar una franja completa no necesita leer los datos antiguos, porque se reemplazan todos los bloques de la franja. La paridad se calcula a partir de los datos que ya están en memoria y el coste se reduce a una escritura adicional. Por eso RAID 5 ofrece buenos resultados en una prueba secuencial y se comporta mal con una carga mixta de escrituras pequeñas procedentes de muchos clientes. Pruebe el patrón que realmente ejecuta: cómo probar correctamente el disco de una VPS significa E/S aleatoria con una profundidad de cola realista, no un único dd grande.

Por qué la reconstrucción es la parte peligrosa

Una reconstrucción de paridad tiene que reconstruir la unidad que falta a partir de todas las demás, por lo que lee 7 unidades supervivientes desde el primer bloque hasta el último. Una reconstrucción de RAID 10 lee 1: la pareja espejo de la unidad averiada y nada más.

De ahí se derivan dos costes. El primero es el tiempo, porque la reconstrucción está limitada por la unidad superviviente más lenta y por los cálculos de paridad adicionales. El segundo es la carga. Todas las unidades de un conjunto de paridad están ocupadas durante toda la operación, por lo que todas las máquinas virtuales de ese nodo experimentan una latencia mayor hasta que termina. En RAID 10, una pareja está ocupada y las demás funcionan a su velocidad normal.

En esa misma ventana existe un riesgo para la integridad de los datos. Una matriz RAID 5 con una unidad averiada ya no tiene redundancia, por lo que un sector ilegible en cualquier unidad superviviente no se puede recuperar. Una reconstrucción es la única operación que lee todos los sectores, incluidos los que nadie ha utilizado en un año. Las cifras publicadas en las hojas de datos sitúan un disco duro de consumo cerca de un error de lectura irrecuperable por cada 10^14 bits leídos, y una unidad NVMe empresarial en uno por cada 10^17 o mejor. Son especificaciones de los fabricantes, no mediciones, pero la proporción explica por qué la antigua advertencia de que una reconstrucción de RAID 5 fallaría se refería a discos mecánicos grandes y por qué es mucho menos aplicable a NVMe. El argumento de la carga se mantiene con cualquier tipo de medio.

Detecte los errores latentes antes de que lo haga una reconstrucción mediante un scrub. Debian y Ubuntu incluyen un scrub periódico para las matrices md, pero el mecanismo cambia entre versiones. Compruebe cuál utiliza y, después, inicie una pasada manualmente.

systemctl list-timers --all | grep -i mdcheck
ls -l /etc/cron.d/mdadm
echo check | sudo tee /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

sync_action vuelve a idle cuando termina la pasada, y mismatch_cnt debería mostrar 0. Un número superior a cero en un espejo significa que las dos mitades no coinciden y que el kernel no puede determinar cuál es correcta, porque ninguna copia incluye una suma de comprobación. Algunos desajustes no son problemáticos; las particiones de swap son la fuente habitual. El kernel puede escribir una página que cambia mientras se comprueba. Un contador que aumenta en una matriz de datos indica que debe sustituir una unidad.

Por qué los proveedores de VPS estandarizan RAID 10 para NVMe

Un nodo de hipervisor no ejecuta una sola carga de trabajo. Ejecuta decenas de invitados independientes, y sus operaciones de E/S llegan intercaladas como un flujo de escrituras pequeñas sin localidad entre ellas. Ese es exactamente el patrón en el que el ciclo de lectura-modificación-escritura de la paridad tiene el mayor coste, y es el patrón que un nodo compartido soporta durante todo el día.

Si se añade el comportamiento durante la reconstrucción, la elección resulta evidente. Un disco averiado en un nodo con paridad ralentiza durante horas a todos los invitados del servidor. Un disco averiado en un nodo RAID 10 ralentiza un solo par, y la copia se ejecuta secuencialmente a la velocidad del disco. Los proveedores venden una latencia que no aumenta bruscamente, por lo que la compran con capacidad: la mitad de la capacidad bruta de NVMe se destina al espejo.

El tamaño de los discos también empuja en la misma dirección. A medida que los discos son más grandes, la ventana de reconstrucción se alarga; en un sistema con paridad, esa ventana es el periodo en el que todo funciona más lento y nada está protegido. Es la misma razón por la que las implementaciones de ZFS para virtualización usan pools de vdevs en espejo en lugar de raidz con muchos discos: un resilver de un espejo copia sólo los bloques que están realmente en uso, en un único par.

Esto no significa que RAID 10 sea siempre la opción correcta. Un destino de copias de seguridad recibe escrituras secuenciales largas y se lee con poca frecuencia, por lo que RAID 6 ofrece una mejor relación coste-beneficio. Tolera dos fallos y recupera la mayor parte de la capacidad. La carga de trabajo es la que decide, no el número. Para un plan que elija hoy, el medio suele importar más que la distribución que se configure sobre él, y el salto de SATA SSD a NVMe es mayor que cualquier diferencia de RAID en ambos casos.

Cómo leer /proc/mdstat

Ejecute estos comandos en una máquina cuyo array administre usted: un servidor dedicado, un equipo doméstico o un VPS con dos volúmenes conectados que haya ensamblado usted mismo. Lea su propia salida. Los bloques siguientes son ejemplos escritos para que pueda comparar la estructura con la que obtiene.

cat /proc/mdstat
sudo mdadm --detail /dev/md0
lsblk -o NAME,SIZE,TYPE,MOUNTPOINTS

Un RAID 10 saludable con cuatro unidades muestra algo parecido a esto.

Personalities : [raid1] [raid10]
md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/30 pages [0KB], 65536KB chunk

unused devices: <none>

Cada parte contiene información.

  • Personalities muestra los módulos md que el kernel en ejecución ha cargado. Que aparezca raid10 sólo significa que el código está disponible.
  • md0 : active raid10 es el dispositivo del array, su estado y su nivel.
  • Los nombres que aparecen después son los miembros. El número entre corchetes es el índice del dispositivo en los metadatos del array, no su posición en la línea ni siempre su ranura.
  • Después de sustituir una unidad, el nuevo miembro suele conservar un índice superior al de la ranura que ocupa. Por eso nvme4n1p3[4] puede estar en la ranura 2. mdadm --detail muestra la ranura real en su columna RaidDevice; use ese valor cuando la diferencia sea importante.
  • (F) después de un miembro significa que está defectuoso. (S) significa repuesto: está presente, inactivo y a la espera de que falle algo.
  • 3906764800 blocks super 1.2 es el tamaño utilizable en bloques de 1 KiB, seguido del formato de metadatos.
  • 512K chunks 2 near-copies es el tamaño del bloque de stripe y la distribución de RAID 10. En este caso, mantiene dos copias de cada bloque una junto a la otra.
  • [4/4] es el número de miembros que espera el array, seguido del número que está sincronizado actualmente.
  • [UUUU] contiene un carácter por ranura, en el orden de las ranuras. U es una ranura activa y sincronizada. _ es una ranura sin ningún dispositivo operativo.
  • bitmap: es el mapa de intención de escritura. Registra las regiones en las que se estaban realizando escrituras, de modo que un miembro que se desconecta y vuelve a conectarse resincroniza esas regiones en lugar de toda la unidad.

Qué significan [4/3] y [UU_U] cuando hay un problema

Un array degradado tiene este aspecto.

md0 : active raid10 nvme3n1p3[3] nvme2n1p3[2](F) nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]

Lea los dos corchetes conjuntamente. [4/3] indica que una de las cuatro ranuras no está contribuyendo. [UU_U] indica cuál, porque el guion bajo es el tercer carácter y las ranuras se numeran desde cero; por tanto, la ranura 2 está inactiva. El indicador (F) identifica el dispositivo sólo mientras la unidad defectuosa siga conectada. Si la extrae de la máquina, el nombre desaparece de la línea, pero el guion bajo permanece.

El array sigue atendiendo solicitudes durante todo este proceso. En RAID 10 suele hacerlo casi a velocidad completa, por lo que nadie lo nota a simple vista. Necesita un mecanismo que se lo comunique.

grep -i mailaddr /etc/mdadm/mdadm.conf
sudo mdadm --monitor --scan --oneshot --test
systemctl list-units --all | grep -i md

El paquete mdadm instala un daemon de monitorización que lee MAILADDR desde /etc/mdadm/mdadm.conf. El nombre de la unidad ha cambiado entre versiones, así que búsquelo con el último comando en lugar de adivinarlo. La ejecución de --test envía inmediatamente un mensaje por cada array. Si después aparece una bandeja de entrada vacía, la ruta de correo está rota. El mensaje que le interesa se habría perdido de la misma forma.

Cuando se reconstruye un reemplazo, aparece una línea de progreso debajo del array.

md0 : active raid10 nvme4n1p3[4] nvme3n1p3[3] nvme1n1p3[1] nvme0n1p3[0]
      3906764800 blocks super 1.2 512K chunks 2 near-copies [4/3] [UU_U]
      [==>..................]  recovery = 12.4% (242012928/1953382400) finish=63.1min speed=452000K/sec

recovery es una reconstrucción sobre una unidad de reemplazo. resync es la primera comprobación de coherencia de un array recién creado. check es el scrub que inició anteriormente. El par entre paréntesis muestra el progreso en bloques de 1 KiB respecto al total por dispositivo, y finish es la estimación del kernel a la velocidad actual. Esa velocidad está limitada por /proc/sys/dev/raid/speed_limit_min y speed_limit_max. Estos límites existen para que una reconstrucción no deje sin recursos a las operaciones de E/S de producción.

Un mdadm --detail completo durante una reconstrucción
/dev/md0:
           Version : 1.2
     Creation Time : Tue Mar 10 09:14:22 2026
        Raid Level : raid10
        Array Size : 3906764800 (3.64 TiB 4.00 TB)
     Used Dev Size : 1953382400 (1.82 TiB 2.00 TB)
      Raid Devices : 4
     Total Devices : 4
       Persistence : Superblock is persistent

       Update Time : Wed Aug  5 11:02:41 2026
             State : clean, degraded, recovering
    Active Devices : 3
   Working Devices : 4
    Failed Devices : 0
     Spare Devices : 1

            Layout : near=2
        Chunk Size : 512K

    Rebuild Status : 12% complete

              Name : storage:0
            Events : 4184

    Number   Major   Minor   RaidDevice State
       0     259        3        0      active sync set-A   /dev/nvme0n1p3
       1     259        7        1      active sync set-B   /dev/nvme1n1p3
       4     259       11        2      spare rebuilding    /dev/nvme4n1p3
       3     259       15        3      active sync set-B   /dev/nvme3n1p3

La columna Number es el índice de metadatos que aparece entre corchetes en /proc/mdstat. La columna RaidDevice es la ranura, es decir, la posición en la cadena [UU_U]. Aquí difieren porque el dispositivo 4 sustituyó la unidad que ocupaba la ranura 2. set-A y set-B identifican las dos mitades de cada espejo. Por tanto, no debe perder simultáneamente un miembro del conjunto A y otro del conjunto B del mismo par que contengan los mismos datos.

Sustituir una unidad en un array que administre usted requiere cuatro comandos. El último es la comprobación.

sudo mdadm --manage /dev/md0 --fail /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --remove /dev/nvme2n1p3
sudo mdadm --manage /dev/md0 --add /dev/nvme4n1p3
cat /proc/mdstat

La línea de recuperación debería aparecer en uno o dos segundos. La partición de reemplazo debe ser al menos tan grande como Used Dev Size de mdadm --detail. Una partición aunque sea ligeramente más pequeña se rechaza con un mensaje del tipo not large enough to join array. Particione la nueva unidad para que coincida con la anterior antes de añadirla.

Qué puede ver y qué no desde dentro de un VPS

La mayoría de los guests no pueden ver el RAID del host, y esto es intencionado. El hipervisor le proporciona un disco virtual. El hecho de que ese disco proceda de un pool RAID 10 de unidades NVMe o esté ubicado en una sola unidad es una propiedad del host y no aparece dentro del guest.

systemd-detect-virt
lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /proc/mdstat

systemd-detect-virt muestra kvm en un guest KVM, un tipo de contenedor como lxc en un contenedor y none en bare metal. En un guest KVM normalmente sólo se ve un único vda o sda en lsblk y ninguna matriz en /proc/mdstat, porque no hay ninguna dentro del guest.

En un VPS basado en contenedores, esta información no es fiable. Los contenedores comparten el kernel del host y algunas partes de /proc no están aisladas mediante namespaces, por lo que lo que se lee allí puede describir el host en lugar de su segmento. No considere ninguno de esos datos como una prueba sobre su propio almacenamiento. Pregunte al proveedor cuál es la disposición del almacenamiento y pida la respuesta por escrito si es importante para usted.

Desde dentro puede comprobar el comportamiento del disco que le han asignado. Comprobar si el disco de su VPS es realmente NVMe explica los comandos que proporcionan datos reales, y qué incluye realmente un VPS con SSD explica qué afirma la etiqueta de la página del plan.

¿Debe ejecutar RAID dentro de su VPS?

Por lo general, no. La razón son los dominios de fallo.

Si conecta dos volúmenes a un VPS y los replica con mdadm, ambos pueden estar en la misma matriz física, en el mismo nodo y detrás de la misma fuente de alimentación. Duplicaría el coste de cada escritura para obtener una redundancia que ya tenía. Además, seguiría perdiendo ambas copias ante el único fallo relevante.

Tiene sentido hacerlo cuando el proveedor documenta que los volúmenes están en dominios de fallo independientes o cuando utiliza un servidor dedicado con unidades que puede administrar directamente. De lo contrario, es más útil invertir el esfuerzo en copias que salgan de la máquina.

De qué no le protege RAID

RAID cubre un evento: una unidad que deja de funcionar correctamente. Todo lo que aparece a continuación es una escritura válida, por lo que el arreglo la aplica a todas las copias y mantiene el estado correcto.

  • Eliminación. rm -rf en el directorio equivocado, o un script de despliegue con una variable sin definir en una ruta. El arreglo ve una escritura válida y la ejecuta dos veces.
  • Ransomware. El cifrado es una escritura. Un arreglo en buen estado almacena la versión cifrada en ambas partes del espejo.
  • Una aplicación defectuosa. Un error que escribe datos basura en la base de datos escribe los mismos datos basura en la unidad redundante.
  • El nodo completo. Un host que falla o una cuenta suspendida por error. Un arreglo puede estar en perfecto estado y no estar accesible al mismo tiempo.
  • Usted mismo, una semana después. El archivo que eliminó el lunes desaparece de todas las unidades ese mismo lunes. Sólo una copia creada antes puede recuperarlo.

Las snapshots en el mismo almacenamiento tampoco son la solución. Ayudan contra las eliminaciones, pero desaparecen junto con el arreglo donde residen. Lo que convierte una copia de seguridad en una copia de seguridad es que esté en otro lugar. Copias de seguridad cifradas fuera del servidor con restic es la otra mitad de esta página: el arreglo permite mantener el servicio activo cuando muere una unidad, y restic recupera los datos cuando el daño fue una escritura que el arreglo aplicó correctamente.

FAQ

¿RAID 10 significa que no necesito copias de seguridad?

No. RAID 10 protege frente a un disco que deja de funcionar. Aplica cada escritura válida a las dos mitades de un espejo, por lo que una eliminación o una ejecución de ransomware llega al disco redundante en el mismo instante. Después, el array aparece como correcto, porque desde su punto de vista no ha fallado nada. Aun así, necesita copias que se almacenen fuera de la máquina y debe restaurar alguna de vez en cuando para comprobar que funcionan.

¿Por qué los proveedores de VPS eligen RAID 10 en lugar de RAID 5 o RAID 6?

Por dos motivos, ambos relacionados con las escrituras aleatorias pequeñas. Una escritura de paridad necesita volver a leer los datos antiguos y la paridad antigua antes de calcular la nueva paridad, por lo que una escritura pequeña cuesta 4 operaciones en RAID 5 y 6 en RAID 6, frente a 2 en un espejo. Una reconstrucción de paridad también lee todos los discos supervivientes de principio a fin, lo que ralentiza durante horas a todos los invitados del nodo, mientras que una reconstrucción de RAID 10 copia un disco en otro y deja intactos los demás pares. Los proveedores pagan esta ventaja con capacidad: la mitad de la capacidad bruta de NVMe.

¿Qué significa [U_] o [UU_U] en /proc/mdstat?

Cada carácter representa una ranura del array, en el orden de las ranuras, con un carácter por ranura. U significa que la ranura contiene un miembro activo y sincronizado. _ significa que no hay nada operativo en esa ranura. [U_] en un espejo de dos discos significa que la segunda ranura está caída y que ya no queda redundancia. Interprételo junto con el par que aparece delante, donde [4/3] indica que el array espera cuatro miembros y tiene tres. El orden de las ranuras coincide con la columna RaidDevice de mdadm --detail, no con el orden en que aparecen los nombres de dispositivo en la línea.

¿Cuántos discos puede perder un array RAID 10?

Uno, con cualquier distribución de fallos. A partir de ahí, depende de dónde se produzcan los fallos. Cada par de espejos puede perder uno de sus dos miembros, por lo que un array de ocho discos soporta hasta cuatro fallos si no hay dos en el mismo par, y deja de funcionar con dos fallos si ambos afectan al mismo par. Planifique según el número garantizado, que es uno, y considere cualquier cifra superior una cuestión de suerte, no de protección.

¿Debería crear un espejo entre dos volúmenes dentro de mi VPS con mdadm?

Normalmente no. Dos volúmenes conectados a un mismo VPS suelen residir en el mismo array físico del mismo host, por lo que crear un espejo duplica el coste de cada escritura y no protege frente a nada que el RAID propio del host no cubra ya. Sólo merece la pena cuando el proveedor documenta que los volúmenes se encuentran en dominios de fallo separados. En caso contrario, dedique ese esfuerzo a copias de seguridad que salgan de la máquina.