A veces las mejores reflexiones técnicas aparecen en conversaciones del día a día. Tomando un café con un compañero de trabajo y charlando sobre almacenamiento, backups y alta disponibilidad surgió una pregunta: si tenemos RAID 5, ¿hasta qué punto podemos considerar que nuestros datos están protegidos ante un fallo? (Lo mismo con el RAID 1 pero el tema estaba con el 5).
La respuesta me llevó a una conclusión que he terminado teniendo muy presente en mi experiencia trabajando con sistemas: RAID 5 aporta redundancia, pero no es un backup y tampoco garantiza por sí solo alta disponibilidad. Entender esa diferencia entre mantener un disco operativo, mantener un servicio disponible y poder recuperar información cuando algo falla es una de esas lecciones que son pequeñas, pero que cambian bastante la forma de pensar el diseño de una infraestructura.
RAID 5 protege frente a un problema muy concreto
RAID 5 distribuye los datos y la información de paridad entre un mínimo de tres discos. Si una unidad falla, el conjunto puede seguir funcionando y reconstruir posteriormente la información cuando se sustituya el disco averiado.
Imaginemos un servidor con cuatro discos. Uno de ellos falla durante la madrugada y el servicio continúa operativo. A la mañana siguiente se sustituye la unidad y comienza la reconstrucción del array.
En ese escenario, RAID 5 ha hecho exactamente aquello para lo que fue diseñado: proporcionar redundancia y tolerancia frente al fallo de un disco.
El problema empieza cuando esperamos que también nos proteja frente a la pérdida de información.
RAID no sabe distinguir entre una modificación operativa y un fallo.
Si borras un archivo, RAID también lo borra
Supongamos que un administrador elimina accidentalmente una carpeta con documentación importante. El sistema operativo procesa el borrado y el RAID almacena correctamente ese nuevo estado. No existe una segunda versión escondida esperando por si cinco minutos después descubrimos que la operación fue un error. Lo mismo ocurre si una aplicación corrompe una base de datos o un usuario sobrescribe un documento. Y exactamente lo mismo sucede ante un ransomware.
Desde la perspectiva del sistema de almacenamiento, cifrar un archivo sigue siendo una operación de escritura. El RAID puede encontrarse perfectamente funcional mientras todos los datos que contiene dejan de ser utilizables.
Ese ejemplo permite entender la diferencia fundamental entre ambos conceptos.
RAID mantiene datos disponibles ante determinados fallos. Un backup permite recuperar datos que ya no están disponibles o que ya no queremos conservar en su estado actual.
RAID 1 tampoco es una copia de seguridad
La confusión resulta incluso más intuitiva con RAID 1.
RAID 1 mantiene los datos en espejo. A primera vista parece lógico pensar: “si tengo dos discos con los mismos archivos, tengo una copia de seguridad”.
Pero tener los datos duplicados físicamente no significa disponer de dos versiones independientes.
Si falla uno de los discos, el otro puede mantener el sistema funcionando. Ese es precisamente el objetivo del espejo. Pero si alguien elimina una carpeta, el borrado se refleja también en el otro disco. Si una aplicación modifica incorrectamente una base de datos, el cambio se replica. Y si un ransomware cifra la información, el estado cifrado acaba almacenado igualmente en el espejo.
Por eso RAID 1 y RAID 5 resuelven el mismo tipo general de problema mediante mecanismos diferentes: protegen el almacenamiento frente al fallo de determinadas unidades, pero no proporcionan por sí mismos un punto independiente de recuperación.
El número de discos puede aumentar. La tolerancia a fallos también. Pero añadir redundancia no crea un backup.
El ransomware lo deja claro
Imaginemos ahora un servidor de archivos sobre RAID 5 que almacena facturas, proyectos, contratos y documentación interna. Un atacante obtiene permisos suficientes y ejecuta ransomware. Los archivos comienzan a cifrarse. La controladora RAID recibe esas operaciones y las procesa normalmente. La paridad continúa calculándose, todos los discos pueden aparecer como saludables y el array puede seguir mostrando un estado correcto.
Técnicamente, el almacenamiento funciona.
El problema es que está funcionando perfectamente para almacenar datos cifrados por el atacante.
Por eso las recomendaciones frente a ransomware insisten en mantener copias separadas de los sistemas de producción, incluyendo backups offline, aislados o protegidos frente a modificación. Y algo obligatorio que por lo general se deja de lado, hay que comprobar periódicamente que esas copias realmente pueden restaurarse y funcionen. Aquí RAID cumple una función distinta. Si mientras se produce el incidente falla físicamente un disco, RAID puede ayudar a mantener el almacenamiento operativo. Pero no va a recuperar la versión anterior de los archivos.
Tampoco debemos confundir RAID con alta disponibilidad
RAID 5 sí mejora la disponibilidad del almacenamiento. Permite que el fallo de una unidad no implique necesariamente la interrupción inmediata del sistema.
Pero alta disponibilidad significa proteger el servicio frente a más cosas que el fallo de un disco.
Un servidor con RAID puede seguir dependiendo de una única placa base, una controladora, una fuente de alimentación, un hipervisor, un sistema operativo, una interfaz de red o un switch. Podemos tener cuatro discos perfectamente sanos y que una avería en la placa base deje fuera de servicio toda la máquina.
O que el sistema operativo se bloquee.
O que falle el único switch al que está conectado.
Por eso RAID puede ser una de las capas que formen parte de una arquitectura de alta disponibilidad, pero no constituye una arquitectura de alta disponibilidad por sí mismo.
Dependiendo de la criticidad del servicio, la solución puede requerir otros nodos, replicación, clustering, failover, alimentación redundante o conectividad alternativa. La diferencia es importante:
RAID protege principalmente el almacenamiento. La alta disponibilidad intenta mantener operativo el servicio. El backup intenta garantizar que la información pueda recuperarse.
La reconstrucción también tiene riesgo
Cuando falla una unidad en RAID 5, el array pasa a funcionar en modo degradado. A partir de ese momento ya se ha consumido su tolerancia a fallos. Hay que sustituir el disco y reconstruir la información utilizando las unidades restantes. Mientras dura ese proceso, otro fallo puede provocar la pérdida del conjunto. Esto cobra especial importancia cuando se utilizan discos de gran capacidad, porque reconstruir varios terabytes puede requerir muchas horas y someter a las unidades restantes a una carga elevada. Según el entorno, puede tener sentido utilizar RAID 6, RAID 10 u otras arquitecturas con mayor tolerancia a fallos. Pero conviene insistir mucho en:
RAID 6 no es un backup y RAID 10 tampoco es un backup.
Mejorar la resiliencia del almacenamiento no sustituye la necesidad de tener otra copia.
¿Y los snapshots?
Los snapshots añaden otra capa útil.
Si alguien elimina accidentalmente una carpeta, poder volver al estado del almacenamiento de unas horas antes soluciona rápidamente el problema. En virtualización y almacenamiento empresarial son una herramienta muy valiosa.
Pero también tienen una limitación: si los snapshots existen únicamente dentro del mismo sistema que contiene los datos originales, pueden compartir el mismo dominio de fallo.
Si desaparece completamente ese almacenamiento, pueden desaparecer también los snapshots. Por eso pueden complementar una estrategia de backup, pero no deberían sustituir por sí solos una copia realmente independiente.
Un backup solo sirve si puede restaurarse
También existe una última falsa sensación de seguridad:
“Los backups se hacen todas las noches”.
Eso está bien, pero la pregunta realmente importante es otra:
¿Cuándo fue la última vez que alguien intentó restaurarlos?
Una tarea puede aparecer como completada correctamente y, aun así, contener datos incompletos, una copia corrupta o información que no permite recuperar realmente la aplicación. También puede ocurrir que la restauración funcione, pero tarde dos días en levantar cuando el negocio necesita recuperar el servicio en cuatro horas. Por eso un sistema de backup no debería medirse únicamente por el número de copias realizadas, sino por la capacidad real de recuperar los datos dentro del tiempo necesario.
La copia de seguridad termina demostrando su valor cuando se restaura, no cuando aparece un mensaje de «Backup completed successfully.»
CIERRE – Redundancia no significa recuperación
RAID 5 sigue siendo una tecnología útil. RAID 1 también. Ambos pueden evitar que la avería de un disco termine inmediatamente en pérdida de servicio.
El problema aparece cuando confundimos el objetivo de cada tecnología.
RAID aporta redundancia. La alta disponibilidad busca mantener funcionando el servicio. El backup permite recuperar la información cuando esa información se ha perdido, corrompido o dejado de ser válida.
Son capas distintas y deberían complementarse.
Da igual que tengamos RAID 1, RAID 5, RAID 6 o RAID 10. Podemos aumentar el número de discos, mejorar el rendimiento o tolerar más averías, pero seguimos sin crear automáticamente una copia de seguridad o esta se aloja en el mismo RAID.
Porque si mañana se avería un disco, agradeceremos tener RAID.
Pero si mañana un usuario elimina toda una carpeta, un ransomware cifra el servidor o desaparece el almacenamiento completo, nos llevaremos las manos a la cabeza y la pregunta será:
¿Dónde está la copia que recuperar los datos?
Y depende de una buena planificación el responder con un «esta aislada en un sistema aparte, probada y podemos recuperar el servicio en 6 horas» o quedarte hasta la madrugada resolviendo el problema y no saber cuando lo vas a recuperar…
FUENTES
NIST – definición de backup:
https://csrc.nist.gov/glossary/term/backup
IBM – funcionamiento y recuperación de RAID 5:
https://www.ibm.com/docs/P9ESS/p9ebk/recover_five_single.htm
CISA – guía de protección y recuperación frente a ransomware:
https://www.cisa.gov/stopransomware/ransomware-guide
