Ampliar un RAID: añadir discos sin perder datos

· Verificado por última vez en julio de 2026

¿Planeando la ampliación? Compara tu array actual con la versión ampliada — mismo pool, más discos — antes de lanzarte.

Abrir la calculadora RAID →

Tarde o temprano todo NAS choca contra el mismo muro: el pool que hace dos años parecía enorme está ahora al 90 por ciento, y la pregunta pasa a ser si puedes simplemente encajar otro disco o si te espera un ciclo completo de backup-borrado-restauración. La respuesta honesta era antes «depende, y a menudo no» — el RAID tradicional era célebremente rígido en esto, y ZFS en particular pasó dos décadas negándose a hacer crecer un vdev RAIDZ. En 2026 el panorama es mucho más amable: casi todas las plataformas tienen ya una vía de ampliación soportada, pero cada una llega con su propia mecánica, sus tiempos de espera y su letra pequeña. Esta guía recorre las opciones plataforma por plataforma, después cubre la vía de sustitución de discos que funciona en todas partes, y por último la gestión de riesgos que convierte una ampliación de apuesta en tarea rutinaria de mantenimiento.

Añadir un disco: lo que cada plataforma soporta realmente

Acoplar un disco nuevo a un array en marcha se llama reshape o expansión, y su soporte se ha vuelto silenciosamente mainstream. Lo que cambia es cuánto del trabajo ocurre en línea, cuánto tarda y en qué estado están tus datos por el camino.

La conclusión concreta: antes de dar nada por hecho, identifica qué capa gestiona realmente tu redundancia — las plataformas difieren tanto que «¿puedo añadir un disco?» tiene cinco respuestas correctas distintas según la caja que tengas.

Expansión RAIDZ de ZFS: lo que dice la letra pequeña

Como la expansión RAIDZ es la más nueva y consultada de estas funciones, merece sección propia. La función conecta un disco nuevo cada vez a un vdev RAIDZ1/2/3 existente y ejecuta después una redistribución en segundo plano que reparte los bloques existentes por el stripe más ancho, con el pool en línea y usable todo el tiempo. Solo eso ya acaba con la limitación más dolorosa que ZFS tenía para usuarios domésticos, que antes debían añadir un segundo vdev completo o destruir y reconstruir el pool.

Pero la letra pequeña importa. Los bloques escritos antes de la expansión conservan su proporción original de datos a paridad — un bloque escrito en un RAIDZ1 de 4 discos sigue ocupando espacio de stripe como si el vdev tuviera 4 discos, incluso después de crecer a 5. Los datos nuevos usan el layout más ancho y eficiente, y los antiguos solo se convierten si se reescriben (por el movimiento normal de datos o copiando datasets a propósito). En la práctica, la capacidad utilizable justo después de una expansión es algo menor que la cifra teórica que nuestra calculadora muestra para un RAIDZ1 nativo de 5 discos, y converge hacia ella conforme los datos rotan. La página de manual de zpool-attach detalla este comportamiento.

Para el público más técnico: la expansión tampoco cambia el nivel de paridad del vdev — un RAIDZ1 sigue siendo RAIDZ1 por muchos discos que conectes. Si tu verdadera motivación para ampliar es que el pool ha crecido más allá de lo que la paridad simple protege con comodidad, la expansión es la herramienta equivocada; esa es una conversación de reconstruir-como-RAIDZ2, y nuestra comparativa RAID 5 vs RAID 6 explica dónde está esa línea.

La conclusión concreta: la expansión RAIDZ es real, estable y está disponible — pero cuenta con menos espacio libre inmediato del que sugiere la cuenta ingenua, y no la uses como sustituto de pasar a paridad doble cuando el número y tamaño de discos lo exigen.

La vía universal: sustituir discos por otros más grandes

Cuando no queda bahía libre — la situación a la que todo dueño de un NAS de 2 o 4 bahías llega tarde o temprano — la vía clásica de ampliación es cambiar cada disco por uno mayor, de uno en uno. La secuencia es siempre la misma: extraer un disco, insertar el sustituto más grande, dejar que el array se reconstruya por completo sobre él, y repetir con el siguiente. La capacidad extra permanece bloqueada hasta que se cambia el último disco; entonces mdadm, ZFS (con autoexpand=on), SHR y DSM dejan crecer el pool en el espacio nuevo. Synology documenta este procedimiento disco a disco en la misma KB de ampliación, y SHR tiene el truco extra de desbloquear parte de la capacidad antes cuando los tamaños están mezclados — nuestra guía de discos de tamaños mezclados muestra cómo funciona esa cuenta.

El coste de esta vía es tiempo y riesgo multiplicados por el número de discos. Cada cambio es una reconstrucción completa — de horas a más de un día por disco con las capacidades actuales, como cuantifica nuestra guía de tiempos de rebuild — y durante cada una de esas reconstrucciones un array de paridad simple funciona con cero redundancia. Cuatro discos significan cuatro ventanas separadas en las que un fallo adicional o un sector ilegible acaba con el pool. Son probabilidades asumibles para RAID 6 o RAIDZ2, y una apuesta francamente incómoda para RAID 5 con discos grandes.

La conclusión concreta: la vía de sustituir-y-reconstruir funciona en prácticamente cualquier plataforma y no necesita bahía libre, pero trátala como N periodos degradados consecutivos, no como una sola operación — y si esa idea te pone nervioso con paridad simple, esa inquietud te está diciendo algo.

¿Cuánto tardaría tu rebuild — y cuánto riesgo corres? La calculadora de rebuild estima duración y probabilidad de fallo por URE para tus discos exactos.

Abrir la calculadora de rebuild →

Gestión de riesgos: las ampliaciones fallan en el peor momento

Elijas el camino que elijas, una ampliación son muchas horas de actividad sostenida sobre toda la superficie de los discos — precisamente la carga que convierte un disco tocado en un disco muerto. No es superstición; es el mismo mecanismo que hace arriesgadas las reconstrucciones tras un fallo, como se cuenta en qué pasa cuando falla un RAID. Un reshape añade un giro extra: la operación mantiene su propio estado crítico en vuelo, y por eso la documentación de mdadm insiste en la opción de backup-file y un corte de luz a mitad de reshape sin SAI es una de las pocas maneras de destrozar un array de verdad.

La lista de comprobación previa es, por tanto, corta e innegociable. Primero, un backup actual y verificado — no porque las ampliaciones suelan fallar, sino porque cuando fallan, fallan del todo; RAID no es un backup aplica por partida doble en ventanas de mantenimiento. Segundo, revisa el SMART de todos los discos antes de empezar: un disco que ya registra sectores reasignados no va a disfrutar un reshape de 20 horas. Tercero, ejecuta la ampliación con SAI, y cuarto, haz antes un scrub para que el reshape no tropiece a mitad de camino con un sector ilegible latente. Ninguno de estos pasos cuesta dinero salvo el SAI, y todos son más baratos que la recuperación de datos.

La conclusión concreta: planifica una ampliación como un pequeño proyecto de mantenimiento — backup verificado, SMART limpio, scrub hecho, SAI conectado — y se volverá aburrida en el mejor sentido de la palabra.

Cuándo ampliar es la respuesta equivocada

A veces el consejo honesto es no hacer crecer el array actual en absoluto. Si tu NAS es de 2 bahías, la sustitución de discos es tu única opción in situ, y la economía suele favorecer pasar a un chasis de 4 o 6 bahías — los arrays más grandes reparten el coste de la paridad entre más discos y te dejan además una vía de ampliación para la próxima ronda, exactamente el intercambio que analiza nuestra guía de upgrade de 2 a 4 a 6 bahías. Del mismo modo, si el array es tan viejo que todos sus discos se acercan al mismo punto de desgaste, cargar el estrés de un reshape sobre cinco discos envejecidos para añadir un sexto es ir hacia atrás; un pool nuevo sobre discos nuevos con migración por copia es más tranquilo y te deja una copia completa de reserva hasta el momento de retirar el juego antiguo.

Y si la ampliación es en realidad una mejora de redundancia disfrazada — quieres pasar de RAID 5 a RAID 6, o de RAIDZ1 a RAIDZ2 — la mayoría de plataformas lo convierten en una reconstrucción, no en un reshape (mdadm es la excepción notable que puede convertir niveles in situ, lentamente). En ese caso, planéalo como migración desde el principio. La conclusión concreta: la expansión es la herramienta para «mismo diseño, más espacio» — cuando lo que quieres es un diseño distinto, migra en lugar de estirar el antiguo.

Recomendación según plataforma

En Unraid, añade el disco y punto — es el truco estrella de la plataforma, la capacidad está disponible al momento y la paridad no se toca. En Synology, usa el flujo de añadir disco del Administrador de almacenamiento para SHR y deja que DSM ejecute el resync por la noche; es la implementación más pulida de todas. En TrueNAS o cualquier sistema con OpenZFS 2.3+, la expansión RAIDZ vía zpool attach es ya la ruta oficial para añadir un solo disco, con la letra pequeña de capacidad de arriba. En una caja DIY con mdadm o Btrfs las herramientas funcionan bien, pero lee el procedimiento del wiki entero antes de empezar, porque las redes de seguridad (backup-file, filtros de balance) son manuales. Y sea cual sea tu plataforma, modela el antes y el después primero en la calculadora RAID para que la ganancia de capacidad sea un número y no una esperanza — y consulta luego la calculadora de rebuild para ver cómo será de verdad la ventana de mantenimiento.

Artículos relacionados

Upgrade NAS: 2 → 4 → 6 bahías bien hecho

Tiempo de RAID rebuild: cuánto tarda realmente?

¿Se pueden mezclar discos de diferente tamaño en RAID?

¿Qué pasa cuando falla un disco RAID? Recuperación paso a paso

SHR vs RAID tradicional – Diferencias y cuándo usar cada uno

Compartir:WhatsAppTelegramFacebookXReddit
📊 Calculadora