RAID no es backup: cómo usarlo bien en entornos empresariales (sin falsas promesas)

En muchas empresas, el almacenamiento se diseña con un objetivo claro: que el servicio no se caiga cuando falle un disco. Ahí es donde el RAID cumple su papel con solvencia. El problema aparece cuando se le atribuye otra misión: proteger los datos ante cualquier incidente. Y eso, sencillamente, no es cierto.

Un RAID bien planteado mejora la disponibilidad y, en algunos casos, la continuidad operativa frente a fallos físicos de disco. Pero no evita borrados accidentales, corrupción lógica, errores humanos, cifrado por ransomware, pérdida del sitio, credenciales comprometidas o fallos de controladora. En otras palabras: RAID reduce el impacto de un tipo de fallo; el backup cubre muchos más.

Qué aporta realmente RAID en empresa

RAID es una técnica de redundancia y/o distribución que combina varios discos en un volumen lógico. Su aportación principal es:

  • Tolerancia a fallos de disco (según el nivel RAID).
  • Mejora de rendimiento (sobre todo en lectura y en algunos patrones de escritura).
  • Menor tiempo de indisponibilidad ante una avería física puntual.

Lo que no aporta:

  • Histórico de versiones (no hay “vuelta atrás” si se borra un fichero).
  • Aislamiento ante malware/ransomware (si cifra el volumen, cifra “el RAID”).
  • Protección ante corrupción silenciosa o errores de aplicación.
  • Recuperación ante desastres (incendio, inundación, robo, caída eléctrica grave, error masivo).

Niveles RAID más comunes y cuándo tienen sentido

RAID 0 (striping, sin redundancia)
Rendimiento puro. Un fallo implica pérdida total. Útil solo en cachés temporales, scratch de render, laboratorios o datos prescindibles.

RAID 1 (espejo)
Duplica los datos en dos discos. Suele usarse para volúmenes de sistema, controladoras, servicios pequeños o arranques donde se prioriza la recuperación simple. No protege de borrados, ransomware o corrupción.

RAID 5 (paridad distribuida, mínimo 3 discos)
Equilibrio entre capacidad y tolerancia a la caída de un disco. Muy extendido en NAS y ficheros, pero con un “pero” importante: en discos grandes, la reconstrucción puede ser larga y el riesgo durante el rebuild sube. En cargas intensivas de escritura, la penalización también se nota.

RAID 6 (doble paridad, mínimo 4 discos)
Tolera la caída de dos discos. Es habitual en entornos con volúmenes grandes, repositorios y cabinas donde se busca más margen durante reconstrucciones. Penaliza más la escritura que RAID 5, pero gana en resiliencia.

RAID 10 (1+0: espejo + striping)
Suele ser el “clásico” para bases de datos, virtualización y cargas de IOPS: buen rendimiento y redundancia robusta. A cambio, sacrifica capacidad (aprox. 50% útil) y exige más discos.

La capa que suele olvidarse: reconstrucción y “riesgo de ventana”

Cuando un disco cae, el RAID entra en modo degradado. A partir de ahí, el sistema vive una ventana de riesgo:

  • La reconstrucción puede durar horas o días según tamaño, carga y tipo de disco.
  • El rendimiento puede caer, justo cuando más se necesita estabilidad.
  • Un segundo fallo (o un sector irrecuperable) puede tumbar el volumen en RAID 5.

Por eso, en 2026, el debate real no es “qué RAID es mejor” sino qué RAID es coherente con el tamaño de disco, la criticidad y el RTO/RPO del servicio.

Controladora, caché y políticas: donde se ganan (o pierden) guerras

En entornos empresariales, RAID suele vivir en una de estas opciones:

  • Controladora RAID dedicada (PERC, Smart Array, MegaRAID): aporta caché, BBU/flash-backed cache y políticas de escritura más seguras.
  • HBA + software (mdadm, ZFS): más transparencia y control, con buen diseño puede ser excelente, pero requiere disciplina operativa.
  • Cabina/NAS/SAN: el RAID forma parte del sistema de almacenamiento y se expone por iSCSI/NFS/FC, con otras capas (snapshots, replicación, etc.).

Aquí hay una regla útil: si la controladora (o su caché) falla, el RAID puede convertirse en tu incidente. Por eso se habla tanto de firmware estable, repuestos, compatibilidades y planes de sustitución.

La frase que conviene tatuarse: RAID no sustituye una política de backup

La estrategia correcta suele mezclar piezas:

  • RAID para disponibilidad (mantener servicios online ante fallos de disco).
  • Snapshots (rápidos, útiles contra errores recientes, pero no infalibles si un atacante toma control).
  • Backups con retención y pruebas (la única garantía real de recuperación).
  • Inmutabilidad/air-gap/offsite para resistir ransomware y errores masivos.
  • DR si la continuidad del negocio no admite depender de un único CPD.

La forma más sencilla de explicarlo: RAID evita que “se pare el coche por un pinchazo”. El backup evita que “pierdas el coche” por accidente, robo o incendio.

Buenas prácticas mínimas

  • Aplicar la regla 3-2-1: 3 copias, 2 soportes distintos, 1 copia fuera o inmutable.
  • Mantener al menos una copia offline o inmutable (Object Lock, WORM, repositorios hardened).
  • Probar restauraciones con frecuencia (un backup sin restore probado es una apuesta).
  • Separar credenciales y limitar privilegios (lo que un admin puede borrar, un atacante con sus credenciales también).
  • Monitorizar estado de discos, SMART, latencias y errores de lectura: detectar antes de que sea tarde.
raid no es backup cloudnews.tech

encuentra artículos

newsletter

Recibe toda la actualidad del sector tech y cloud en tu email de la mano de RevistaCloud.com.

Suscripción boletín

LO ÚLTIMO

Las últimas novedades de tecnología y cloud

Suscríbete gratis al boletín de Revista Cloud. Cada semana la actualidad en tu buzón.

Suscripción boletín
×